# Separation of gui from "real work" **URL:** \ **Category:** Ruby\ **Created:** [April 7, 2006, 2:06pm UTC](https://www.ruby-forum.com/t/separation-of-gui-from-real-work/57139 "2006-04-07T14:06:02Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![tashirosgt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c2a13f/32.png) [@tashirosgt](https://www.ruby-forum.com/u/tashirosgt)\ **Post date:** [April 7, 2006, 2:06pm UTC](https://www.ruby-forum.com/t/separation-of-gui-from-real-work/57139/1 "2006-04-07T14:06:02Z")
This is not a ruby specific topic but since there were some definite opinions expressed about systems of writing GUIs in a recent thread, let me ask it here. Is there a practical program architecture for separating the gui portion of a program from the part that does the “real work”? Or is this just a high flown idea that is rarely practical? Conceptually, one could write “the real work” part of the program as a kind of state engine that is driven by an “interface” which provides inputs and receives outputs. Various “interfaces” could be written. For example, one might use console I/O, another might use WxWidgets, etc. Perhaps if the “real work” part of the program is not that hard, this is overkill. But, for example, when I want to try to write some fairly hard numerical problem (and when I am unsure of whether my ideas about it are sound!) the last thing I want to do is start thinking about how to design a gui interface for it. It goes faster to read the inputs from a file and print the outputs on the console. But, on the other hand, I don’t look forward to separating the “real work” from a gui-to-be-written-in-the -future-in-some-as-yet-to-be-determined-system by writing the file-and-console interface. Perhaps this seems tedious because I haven’t had enough practice writing interfaces of either kind. There are approaches that pride themselves in binding the gui tightly together with the application without any intermediate interface. For example, Fox lets you bind a “real work” variable to something represented in a gui. I think in this point of view, you treat the “real work” as a collection of services (not as any kind of state engine). Then you use the gui as the glue that puts them together into a useful machine. ---
**Author:** ![tashirosgt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c2a13f/32.png) [@tashirosgt](https://www.ruby-forum.com/u/tashirosgt)\ **Post date:** [April 7, 2006, 2:22pm UTC](https://www.ruby-forum.com/t/separation-of-gui-from-real-work/57139/2 "2006-04-07T14:22:57Z")
A couple of links that may help: > **[Model–view–controller](https://en.wikipedia.org/wiki/Model_view_controller)** > > Model–view–controller (MVC) is a software design pattern commonly used for developing user interfaces that divides the related program logic into three interconnected elements. This is done to separate internal representations of information from the ways information is presented to and accepted from the user. > Traditionally used for desktop graphical user interfaces (GUIs), this pattern became popular for designing web applications. Popular programming languages have MVC frameworks that facilita... > **[(ootips) Model-View-Controller](https://ootips.org/mvc-pattern.html)** > > The Model-View-Controller (MVC) is a commonly used and powerful architecture for GUIs. How does it work? ---
**Author:** ![tashirosgt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c2a13f/32.png) [@tashirosgt](https://www.ruby-forum.com/u/tashirosgt)\ **Post date:** [April 7, 2006, 2:20pm UTC](https://www.ruby-forum.com/t/separation-of-gui-from-real-work/57139/3 "2006-04-07T14:20:53Z")
Stephen T. wrote: > This is not a ruby specific topic but since there were some definite > opinions expressed about systems of writing GUIs in a recent thread, let > me ask it here. > > Is there a practical program architecture for separating the gui portion > of a program from the part that does the “real work”? Or is this just a > high flown idea that is rarely practical? You need to look into a concept called MVC - it stands for Model/View/Controller. The specifics vary from language to language but essentially, this technique carves your app into three sections: The MODEL defines your data structure. This could be the way it’s stored in a database, or the file format if you’re writing to a file. Ideally, you should be able to have as little as possible of the implementation-specific nature of whatever you use to be exposed. For example, if it’s a music management app, don’t have a method called “executeSql” exposed outside of the Model, because maybe you also want to store it in a file where SQL is not appropriate. Instead, implement methods for all the different tasks you might want to perform - adding songs, getting lists of songs by a particular artist, and so on. The VIEW is the user interface and all the associated logic for that. If you want to show the info in a tree view, like Windows Media Player (say, Artist\>Album\>Song), then you’d build the tree here. Finally, the CONTROLLER is the bit that handles all the complicated logic. Building a random playlist might happen in the CONTROLLER, for example. There is always some overlap, and there is necessarily some links between the different modules, but these should be kept limited and tightly controlled so that you know where to go if you want to swap, say, from an SQL database to a proprietary file format. A good example in Ruby is Rails, which also adds a HELPER section. This technique (as evidenced by Rails’s HELPERs) is not set in stone, but it’s a basis for you to build your apps on. Hope that helps ---
**Author:** ![tashirosgt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c2a13f/32.png) [@tashirosgt](https://www.ruby-forum.com/u/tashirosgt)\ **Post date:** [April 7, 2006, 5:04pm UTC](https://www.ruby-forum.com/t/separation-of-gui-from-real-work/57139/4 "2006-04-07T17:04:24Z")
> The original post was a pretty general question. MVC is certainly > one approach > but it still embeds the ‘real work’ in the GUI application albeit via > a nice > internal structure. Yeah, my post was intended to suggest a way he could seperate the > Another thought is that the ‘real work’ is done via some sort of a > server > application with an API that is accessed from clients via inter-process > communication of some sort. Think of the separation of functionality > between a mail reader application and the back end mailbox server via > IMAP or POP. I disagree - a client may do some ‘real work’, and a server may have a certain level of GUI (such as config and administration stuff). And even if it’s not like that, client-server is not appropriate in every situation - often I want an app that just runs locally. Take my music manager example - do I really need a server application to store my song data? When I want to add a song, should I really need to start the server and then the client just to do that? I don’t think so. So a lot of apps (the majority, IMHO) could just be simple little things that run on my PC whenever I need them. In that case, how do I seperate the GUI from the server? Well, you need an internal structure that does that. Stephen, do you want to seperate your GUI into a completely seperate application, or just a different module in the same application? ---
**Author:** ![tashirosgt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c2a13f/32.png) [@tashirosgt](https://www.ruby-forum.com/u/tashirosgt)\ **Post date:** [April 7, 2006, 3:32pm UTC](https://www.ruby-forum.com/t/separation-of-gui-from-real-work/57139/5 "2006-04-07T15:32:02Z")
On Apr 7, 2006, at 8:21 AM, John wrote: > > high flown idea that is rarely practical? > > You need to look into a concept called MVC - it stands for > Model/View/Controller. The original post was a pretty general question. MVC is certainly one approach but it still embeds the ‘real work’ in the GUI application albeit via a nice internal structure. Another thought is that the ‘real work’ is done via some sort of a server application with an API that is accessed from clients via inter-process communication of some sort. Think of the separation of functionality between a mail reader application and the back end mailbox server via IMAP or POP. It might be worth exploring the [c2.com](http://c2.com) website which has lots of discussion on software patterns. You might start at [http://c2.com/cgi-bin/wiki](http://c2.com/cgi-bin/wiki)? ModelViewController Gary W. ---
**Author:** ![tashirosgt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c2a13f/32.png) [@tashirosgt](https://www.ruby-forum.com/u/tashirosgt)\ **Post date:** [April 7, 2006, 6:14pm UTC](https://www.ruby-forum.com/t/separation-of-gui-from-real-work/57139/6 "2006-04-07T18:14:44Z")
On Apr 7, 2006, at 11:04 AM, John wrote: > certain level of GUI (such as config and administration stuff). And > even if it’s not like that, client-server is not appropriate in every > situation - often I want an app that just runs locally. Huh? I simply suggested that not all problems need/should be solved with MVC and provided an example as well as a pointer to a repository of software patterns. I wasn’t trying to say that MVC wasn’t useful at all. It can even be part of the GUI client app talking to the non-gui server app that is doing the ‘real work’. There is nothing to agree or disagree with unless you think that every peg should be shoved into the MVC-shaped hole. In that case, I disagree. Gary W. ---
**Author:** ![tashirosgt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c2a13f/32.png) [@tashirosgt](https://www.ruby-forum.com/u/tashirosgt)\ **Post date:** [April 7, 2006, 6:34pm UTC](https://www.ruby-forum.com/t/separation-of-gui-from-real-work/57139/7 "2006-04-07T18:34:59Z")
unknown wrote: > On Apr 7, 2006, at 11:04 AM, John wrote: > > > certain level of GUI (such as config and administration stuff). And > > even if it’s not like that, client-server is not appropriate in every > > situation - often I want an app that just runs locally. > > Huh? I simply suggested that not all problems need/should be solved > with MVC Ah, no argument from me there. Sorry I just misunderstood your post as saying “don’t use MVC - use a client/server topology instead”. If that’s not what you were sayingm then we’re all good. ---
**Author:** ![tashirosgt](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c2a13f/32.png) [@tashirosgt](https://www.ruby-forum.com/u/tashirosgt)\ **Post date:** [April 8, 2006, 1:33am UTC](https://www.ruby-forum.com/t/separation-of-gui-from-real-work/57139/8 "2006-04-08T01:33:41Z")
John wrote: > You need to look into a concept called MVC - it stands for > Model/View/Controller. I’ve looked at that in the sense of reading about it. But general concept isn’t so specific about separating the “view” from the other parts. As an example of a specific issue, suppose the “view” has a window with fields X,Y, Z. When the user changes Z, we want X and Y to be updated. I suppose the idealistic approach would be for the view to tell the controller to update Z and inform the view about the new X and Y. The server-client or “communicating processes” implementation of this would make it clear that the “view” is, in some sense an independent entity. But one could take the single-process approach and made the “view” a gui which treated the model and controller as a set of functions to be called at appropriate times. The “communicating processes” way seems to carry a lot of overhead with it. On the other hand, I’ve thought of schemes with even crazier amounts of overhead. When I think about a system of gui’s abstractly it seems to consist of “windows” and in these windows are various visible things. Some are passive and merely display information. Some take inputs. Others can be activated and cause further windows to appear. So I think of the abstract architecture of a gui as something like the typical display of a tree (like the Windows registry keys). The folders are abstract windows. I ignore anything about their position, size etc. I merely think of them as an abstract data structure. Each is either “active” or “inactive”. The things on them are not specified by any appearance (like “button” or “radio dial” ) or any geometrical location in the window. They are merely described by the type of data they display or input. So the idea would be to create the abstract architecture of a gui. Then one could interface various real gui’s with this to implement something useful. For example, in one interface the field that displays X and Y might be a text field, in another interface it might be a two thermometers, etc. This is such a nice concept but it also seems like so much trouble that I doubt anyone will every bother to do it. It also does not solve what I find most irritating about the coding of guis. Namely that it is laborious to make changes in what component is a child of what other component. One thought for a gui designer is simply to build into the gui writing system the feature that when a certain global variable, say, “DESIGN\_STAGE” is 1, then each component can be selected (perhaps by the awkward ALT-TAB way of moving focus) and caused to pop down a little menu that says “Edit Me” and offers the user options to modify it. It should be easy to change things that are parametric. For example to change the size or color. But it would be harder to change the type of the component (say from button to check box). It would be very hard to implement moving a component from one parent object to another parent object. As far as I can see, in the current systems for writing GUIs, this would amount to a recode and compile on-the-fly. I suppose this is what GUI design programs must do, but a self-designable gui system would be doing this to itself. I don’t know what computer science it would take to make moving child objects from parent to parent possible, but I would like to see a system of writing GUIs where this was easy (thus making the dream of the built-in gui designer possible).