# GUI's and the Rouge, Part III (yes, finally) 1/2 **URL:** \ **Category:** ruby-talk\ **Created:** [24 July 2002 10:04 UTC](https://rubytalk.org/t/guis-and-the-rouge-part-iii-yes-finally-1-2/829 "2002-07-24T10:04:28Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Benjamin\_Peterson1](https://avatars.discourse-cdn.com/v4/letter/b/fbc32d/32.png) [@Benjamin\_Peterson1](https://rubytalk.org/u/Benjamin_Peterson1)\ **Post date:** [24 July 2002 10:04 UTC](https://rubytalk.org/t/guis-and-the-rouge-part-iii-yes-finally-1-2/829/1 "2002-07-24T10:04:28Z")
> you have this super application you wrote --the > underbelly of an > factastic hoogy-me-whatsy-do-it-all app and now you > have to figure out > how to put a front-end on her. so you need a gui. > hmmm…you think, i > want a gui thats flexible and fast nad highly > functional, runs on just > about any platform, looks good, preferably just like > the native > interface, and is easy as pie to code so as not to > require much fussing > with the app you’ve alredy written. Are there people out there who really do this? Build GUI apps by first writing a non-GUI application, and only then start to think about what sort of GUI framework can be bolted on to it? Certainly I can imagine establishing sections of functionality, such as financial algorithms or encryption or whatever, without reference to the GUI. But the kind of GUI people expect these days is just not the kind you can attach as an afterthought–especially as the GUI is perhaps one of the most structured parts of the application (you may be able to write your core functionality in a very linear way, but your GUI will always involve asynchronous communication). I think that you are writing a tool aimed very much at one particular case – the case where you have a unix-style command-line application which you might want to bolt a simple GUI onto if you happen to get a user who doesn’t like typing. I think this case is already covered pretty well, and a toolkit capable of producing heavy duty GUIs (like CodeWarrior, PageMaker, VS .net, Elixir, maybe even Gimp) would be much more interesting. Clifford Heath commented: > …factor that makes it really work: rich > asynchronous message passing. > I’m still of the firm opinion that this is the single > integrating feature > which is needed to revolutionise GUI programming. I agree strongly that asynchronous, hierarchical message passing is a vital part of GUI infrastructure. I was under the impression that it revolutionized GUI programming quite a while back, though. Benjamin x ---
**Author:** ![Tom\_Sawyer](https://avatars.discourse-cdn.com/v4/letter/t/a587f6/32.png) [@Tom\_Sawyer](https://rubytalk.org/u/Tom_Sawyer)\ **Post date:** [24 July 2002 11:11 UTC](https://rubytalk.org/t/guis-and-the-rouge-part-iii-yes-finally-1-2/829/2 "2002-07-24T11:11:27Z")
> Are there people out there who really do this? Build > GUI apps by first writing a non-GUI application, and > only then start to think about what sort of GUI > framework can be bolted on to it? you should try it. i used to not write my apps this way. but i now realize how much more powerful it is to do so. its really just SOC on a another level. i know that most people probably don’t do things this way, just as i used to not, but i think that’s becasue no ones ever should them how. they simply don’t realize that they can; and that the gui tookits out there do not lend themselves to it ☹ you have to create you own integration/communications layer. but its well worth it. once done you can create a variety of intefeaces to your application, with different toolkits and different languages, if you so wish. its really a good design approach. “bolted on to it?” you say that like its a bad thing 😉 > Certainly I can imagine establishing sections of > functionality, such as financial algorithms or > encryption or whatever, without reference to the GUI. > But the kind of GUI people expect these days is just > not the kind you can attach as an > afterthought–especially as the GUI is perhaps one of > the most structured parts of the application (you may > be able to write your core functionality in a very > linear way, but your GUI will always involve > asynchronous communication). well, certainly it depends to what you writing, but i would guesstimate that 90%+ of all apps could be written this way. it not like you don’t have some idea about the gui from the get go, but the core functionality does not have to be, nay should not be dependent on that. > I think that you are writing a tool aimed very much at > one particular case – the case where you have a > unix-style command-line application which you might > want to bolt a simple GUI onto if you happen to get a > user who doesn’t like typing. I think this case is > already covered pretty well, and a toolkit capable of > producing heavy duty GUIs (like CodeWarrior, > PageMaker, VS .net, Elixir, maybe even Gimp) would be > much more interesting. well, your simply wrong here. right now i have a full blown accounting application that i have to “bolt on”, as you say, a gui to. its currently has NO interface, not even a command line. i don’t follow you references to CodeWarrior, PageMaker, etc. as builders of heavy duty GUIs. ? > Clifford Heath commented: > > > …factor that makes it really work: rich > > asynchronous message passing. > > I’m still of the firm opinion that this is the single > > integrating feature > > which is needed to revolutionise GUI programming. > > I agree strongly that asynchronous, hierarchical > message passing is a vital part of GUI infrastructure. > I was under the impression that it revolutionized GUI > programming quite a while back, though. well, how does X do it? how does VNC deal with it? in either case, i’m not seeing a big revolution around here. now, networked gaming, on the other hand, perhaps we can say there’s a small one going on in that relm. so that could be a source of design inspiration, i.e. why not bring those capabilities into normal every day gui interfaces as well? and i think, although indirectly, this may be what Clifford is suggesting. but even without this communications layer. a gui toolkit as i have described would be a very useful tool. personally i am wondering if i have simply not explained myself clearly. can you not see the utitlity of what i’ve described? perhaps you simply don’t code gui apps? ~transami > **···** > > On Wed, 2002-07-24 at 04:04, Benjamin Peterson wrote: ---
**Author:** ![Dossy](https://avatars.discourse-cdn.com/v4/letter/d/b9bd4f/32.png) [@Dossy](https://rubytalk.org/u/Dossy)\ **Post date:** [24 July 2002 13:20 UTC](https://rubytalk.org/t/guis-and-the-rouge-part-iii-yes-finally-1-2/829/3 "2002-07-24T13:20:18Z")
Yes. There’s a reason the Model-View-Controller (MVC) pattern is so well-known. Implement a simple non-graphical UI as your View, then replace it later once you have the “meaty bits” like the Model and Controller fleshed out. This works well enough that you can have a seperate team doing the Model and Controller bits from the team who is building the View bits. The Model-Controller team builds everything with a very simple non-graphical UI View, while the other team builds the graphical UI View using dummied out Model-Controller stuff. Typically, the team that builds the View portion builds what most people know as a “wireframe prototype” – it demonstrates the graphical UI front-end with none of the mechanisms behind to make the application actually “do” anything. – Dossy > **···** > > On 2002.07.24, Benjamin Peterson [bjsp123@yahoo.com](mailto:bjsp123@yahoo.com) wrote: > > > Are there people out there who really do this? Build > > GUI apps by first writing a non-GUI application, and > > only then start to think about what sort of GUI > > framework can be bolted on to it? > > – > Dossy Shiobara mail: [dossy@panoptic.com](mailto:dossy@panoptic.com) > Panoptic Computer Network web: [http://www.panoptic.com/](http://www.panoptic.com/) > “He realized the fastest way to change is to laugh at your own > folly – then you can let go and quickly move on.” (p. 70) ---
**Author:** ![Massimiliano\_Mirra4](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@Massimiliano\_Mirra4](https://rubytalk.org/u/Massimiliano_Mirra4)\ **Post date:** [24 July 2002 18:07 UTC](https://rubytalk.org/t/guis-and-the-rouge-part-iii-yes-finally-1-2/829/4 "2002-07-24T18:07:56Z")
Tom is not talking about bolting a GUI onto an _application_, he’s talking about bolting a GUI onto a _model_, i.e. a set of classes that describe program logic and are ignorant of user interfaces. Massimiliano > **···** > > On Wed, Jul 24, 2002 at 07:04:28PM +0900, Benjamin Peterson wrote: > > > Are there people out there who really do this? Build > > GUI apps by first writing a non-GUI application, and > > only then start to think about what sort of GUI > > framework can be bolted on to it? ---
**Author:** ![Clifford\_Heath1](https://avatars.discourse-cdn.com/v4/letter/c/dc4da7/32.png) [@Clifford\_Heath1](https://rubytalk.org/u/Clifford_Heath1)\ **Post date:** [26 July 2002 00:10 UTC](https://rubytalk.org/t/guis-and-the-rouge-part-iii-yes-finally-1-2/829/5 "2002-07-26T00:10:16Z")
Benjamin Peterson wrote: > I agree strongly that asynchronous, hierarchical > message passing is a vital part of GUI infrastructure. > I was under the impression that it revolutionized GUI > programming quite a while back, though. Nearly all existing GUI toolkits use some kind of asynchronous messaging within a hierarchy, but no others that I’m aware of (having been away from GUIs for a couple of years now) combine the characteristics of: - Rich messaging - you define strong message types with arbitrary content (in OpenUI that means potentially nested arrays of structures of…) - Hierarchical propagation against handlers having the appearance of dynamically-bound methods that receive the message parameters, - Message broadcast down towards the leaf nodes that’s transparent to the current delivery node. In other words, sufficient power in the messaging system that no widget needs to directly address any other. Most GUI toolkits make minimal or no use of the hierarchy for message propagation. Messages are normally of one of the limited standard types, and there are ad-hoc broadcast mechanisms if any. > **···** > > – > Clifford Heath ---
**Author:** ![Ned\_Konz](https://avatars.discourse-cdn.com/v4/letter/n/ad7895/32.png) [@Ned\_Konz](https://rubytalk.org/u/Ned_Konz)\ **Post date:** [24 July 2002 15:19 UTC](https://rubytalk.org/t/guis-and-the-rouge-part-iii-yes-finally-1-2/829/6 "2002-07-24T15:19:46Z")
I disagree. Unless you’re willing to make a horribly modal or limited UI, or are aware from the start that events will be triggering behavior asynchronously, you will probably find that sequencing and ordering assumptions made in the underlying code will cause problems in the UI. Some simple single-view dialogs may work OK, but multiple views with concurrent updates probably won’t. One of the notable hard parts is connecting exception handling with user notification and intervention. > **···** > > On Wednesday 24 July 2002 04:11 am, Tom Sawyer wrote: > > > > functionality, such as financial algorithms or > > > encryption or whatever, without reference to the GUI. > > > But the kind of GUI people expect these days is just > > > not the kind you can attach as an > > > afterthought–especially as the GUI is perhaps one of > > > the most structured parts of the application (you may > > > be able to write your core functionality in a very > > > linear way, but your GUI will always involve > > > asynchronous communication). > > > > well, certainly it depends to what you writing, but i would > > guesstimate that 90%+ of all apps could be written this way. it not > > like you don’t have some idea about the gui from the get go, but > > the core functionality does not have to be, nay should not be > > dependent on that. > > – > Ned Konz > [http://bike-nomad.com](http://bike-nomad.com) > GPG key ID: BEEA7EFE ---
**Author:** ![Chris\_Gehlker1](https://avatars.discourse-cdn.com/v4/letter/c/c37758/32.png) [@Chris\_Gehlker1](https://rubytalk.org/u/Chris_Gehlker1)\ **Post date:** [24 July 2002 15:40 UTC](https://rubytalk.org/t/guis-and-the-rouge-part-iii-yes-finally-1-2/829/7 "2002-07-24T15:40:04Z")
Dossy is absolutely right here. I would add that if you are building a program with mutiple interfaces, say a GUI and a scripting/recording interface for AppleScript/VBA or a GUI and a CORBA interface, you _have to_ use this pattern. But Benjamin talked about “you may be able to write your core functionality in a very linear way” and, if I understand him, this is something that one must avoid. The Model itself can’t make any assumptions about the order of messages that it will receive other than that it will get some kind of initialize message first and some kind of finalize message last. It can never initialize communication with a user but must rather passively wait for messages. If it is written this way, one can indeed “bolt on” sereral Uis. > **···** > > On 7/24/02 6:20 AM, “Dossy” [dossy@panoptic.com](mailto:dossy@panoptic.com) wrote: > > > On 2002.07.24, Benjamin Peterson [bjsp123@yahoo.com](mailto:bjsp123@yahoo.com) wrote: > > > > > Are there people out there who really do this? Build > > > GUI apps by first writing a non-GUI application, and > > > only then start to think about what sort of GUI > > > framework can be bolted on to it? > > > > Yes. There’s a reason the Model-View-Controller (MVC) > > pattern is so well-known. > > > > Implement a simple non-graphical UI as your View, then > > replace it later once you have the “meaty bits” like > > the Model and Controller fleshed out. > > > > This works well enough that you can have a seperate > > team doing the Model and Controller bits from the > > team who is building the View bits. > > – > There is, nevertheless, a certain respect and a general duty of humanity > that ties us, not only to beasts that have life and sense, but even to > trees and plants. -Michel de Montaigne, essayist (1533-1592) ---
**Author:** ![Tom\_Sawyer](https://avatars.discourse-cdn.com/v4/letter/t/a587f6/32.png) [@Tom\_Sawyer](https://rubytalk.org/u/Tom_Sawyer)\ **Post date:** [24 July 2002 20:26 UTC](https://rubytalk.org/t/guis-and-the-rouge-part-iii-yes-finally-1-2/829/8 "2002-07-24T20:26:38Z")
hi Massimiliano, i’ve just finished reading up on MVC. but i’m little puzzeled about how the paradigm i have created maps to this pattern. let me explain. i take the Model to be the back-end application. In my example case that would the Fruity Fun App. It is the application, indifferent to any user interface. then the Viewer is the GUI engine? --that which renders the GUI? In my example that dosen’t really yet exist, and at best could be said to be STDOUT. am i right about this? but then the Controller, it would seem, is the same entity as the GUI engine which also handles the user interaction. i’m a bit confused on that point. what i am calling a model in my GUtopia API is the code to generate the UI, perhaps then it is really a View? but my model/View is also fully absatracted and knows nothing about the Model/application for which it will describe the UI. the two only relate via an intermidiary description called the binding. so how does that fit into the MVC picture? i hanker this guess: the underlying engine is irrelevent, the Model is my application, the View is what i am calling a model (its a model of the UI) and the bindings are the Controller. would that be correct? by the way, thanks for the support. ~transami ~transami > **···** > > On Wed, 2002-07-24 at 12:07, Massimiliano Mirra wrote: > > > Tom is not talking about bolting a GUI onto an _application_, he’s > > talking about bolting a GUI onto a _model_, i.e. a set of classes that > > describe program logic and are ignorant of user interfaces. ---
**Author:** ![Ned\_Konz](https://avatars.discourse-cdn.com/v4/letter/n/ad7895/32.png) [@Ned\_Konz](https://rubytalk.org/u/Ned_Konz)\ **Post date:** [26 July 2002 00:34 UTC](https://rubytalk.org/t/guis-and-the-rouge-part-iii-yes-finally-1-2/829/9 "2002-07-26T00:34:45Z")
A couple of examples come to mind that have the characteristics you describe (I think) (both, interestingly, are from the world of prototype-based OO languages): - NewtonScript and its built-in inheritance of message handling code down through the containment hierarchy: events are delivered to the innermost widget, but the code that handles the event may in fact be “inherited” from some parent, up to the main view itself. - Squeak’s Morphic and its built-in event handling that usually routes the events down through the containment hierarchy and gives priority to the innermost components (though this can be overridden as desired by a parent). You can make new event types if you want, though I haven’t seen any. Most of the “conventional” UIs in Squeak use MVC for notification because they have to work in either Morphic or the older MVC graphics system. (I don’t know enough about event routing in Self’s Morphic to say if this is the same). > **···** > > On Thursday 25 July 2002 05:10 pm, Clifford Heath wrote: > > > Most GUI toolkits make minimal or no use of the hierarchy for > > message propagation. Messages are normally of one of the limited > > standard types, and there are ad-hoc broadcast mechanisms if any. > > – > Ned Konz > [http://bike-nomad.com](http://bike-nomad.com) > GPG key ID: BEEA7EFE ---
**Author:** ![Chris\_Gehlker1](https://avatars.discourse-cdn.com/v4/letter/c/c37758/32.png) [@Chris\_Gehlker1](https://rubytalk.org/u/Chris_Gehlker1)\ **Post date:** [25 July 2002 02:42 UTC](https://rubytalk.org/t/guis-and-the-rouge-part-iii-yes-finally-1-2/829/10 "2002-07-25T02:42:02Z")
Try thinking of it this way: The Model is as you understand it, It’s an object hierarchy that just sits there and responds to messages. It only gets messages from the controller. The View also talks only to the controller but it’s a two way street. The view sends messages when the user types or clicks a widget and it updates it’s display when the controller sends it new data. The controller is there specifically to isolate the Model from the View(s). The notion is that the Model is portable and the View is easy because you can make it with some kind of “draw a GUI” program. All the hard interface logic is in the controllers. I keep talking about ‘the view’ and ‘the controller’ but an app with multiple windows with multiple panes might have several views and controllers. The spatial containment hierarchy on screen is mirrored by the message hierarchy of the controllers. > **···** > > On 7/24/02 1:26 PM, “Tom Sawyer” [transami@transami.net](mailto:transami@transami.net) wrote: > > > On Wed, 2002-07-24 at 12:07, Massimiliano Mirra wrote: > > > > > Tom is not talking about bolting a GUI onto an _application_, he’s > > > talking about bolting a GUI onto a _model_, i.e. a set of classes that > > > describe program logic and are ignorant of user interfaces. > > > > hi Massimiliano, > > > > i’ve just finished reading up on MVC. but i’m little puzzeled about how > > the paradigm i have created maps to this pattern. let me explain. i take > > the Model to be the back-end application. In my example case that would > > the Fruity Fun App. It is the application, indifferent to any user > > interface. then the Viewer is the GUI engine? --that which renders the > > GUI? In my example that dosen’t really yet exist, and at best could be > > said to be STDOUT. am i right about this? but then the Controller, it > > would seem, is the same entity as the GUI engine which also handles the > > user interaction. i’m a bit confused on that point. what i am calling a > > model in my GUtopia API is the code to generate the UI, perhaps then it > > is really a View? but my model/View is also fully absatracted and knows > > nothing about the Model/application for which it will describe the UI. > > the two only relate via an intermidiary description called the binding. > > so how does that fit into the MVC picture? i hanker this guess: the > > underlying engine is irrelevent, the Model is my application, the View > > is what i am calling a model (its a model of the UI) and the bindings > > are the Controller. would that be correct? > > – > I have suffered from being misunderstood, but I would have suffered a hell > of a lot more if I had been understood. -Clarence Darrow, lawyer and author > (1857-1938) ---
**Author:** ![Massimiliano\_Mirra4](https://avatars.discourse-cdn.com/v4/letter/m/43a26b/32.png) [@Massimiliano\_Mirra4](https://rubytalk.org/u/Massimiliano_Mirra4)\ **Post date:** [25 July 2002 08:05 UTC](https://rubytalk.org/t/guis-and-the-rouge-part-iii-yes-finally-1-2/829/11 "2002-07-25T08:05:41Z")
> i’ve just finished reading up on MVC. but i’m little puzzeled about > how the paradigm i have created maps to this pattern. let me > explain. i take the Model to be the back-end application. Well, not exactly. Consider: class SpreadSheet def (row, column) … end def =(row, column, value) … end def calc … end end This is a model, yet not an application. An application presupposes user interaction, while you can only interact with your SpreadSheet model from code. > In my example case that would the Fruity Fun App. It is the > application, indifferent to any user interface. I’ve lost track of examples, but yes, replace the above word `application' with `model’ and you have it. > then the Viewer is the GUI engine? --that which renders the GUI? If you say Viewer, I’d guess so. I’ve always read MVC as Model, View (not Viewer), Controller. So the View is whatever shows the model status to the user. It is not implicit in the name, but it is usually accepted that it also sends user input to the model or to the Controller (in simpler designs the Controller is sometimes integrated in the View). > In my example that dosen’t really yet exist, and at best could be > said to be STDOUT. am i right about this? As I said I’ve lost track of examples, but if you have something sent to STDOUT you’ve already got some kind of presentation beside the model, whether this fits in a MVC pattern or not. > but then the Controller, it would seem, is the same entity as the > GUI engine which also handles the user interaction. i’m a bit > confused on that point. what i am calling a model in my GUtopia API > is the code to generate the UI, perhaps then it is really a View? > but my model/View is also fully absatracted and knows nothing about > the Model/application for which it will describe the UI. the two > only relate via an intermidiary description called the binding. so > how does that fit into the MVC picture? i hanker this guess: the > underlying engine is irrelevent, the Model is my application, the > View is what i am calling a model (its a model of the UI) and the > bindings are the Controller. would that be correct? Except for the model/application bit (the application is the whole), I’d say yes. Also see if this point of view (no pun) can be useful to you: the View thinks in terms of appearance: `button', `menu’ and `checkbox'; the Model thinks in terms of meaning: `surname’, `telephone', `address’; the Controller translates action on appearance (`click button') into action on meaning (`edit surname’), and, conversely, change of state in meaning (`surname changed') into change of state in appearance (`edit field updated’). By the way, I’m an artisan, not a computer scientist. Take what I tell you with a grain of salt, and the way I tell it with, well, a whole bag of it. 🙂 Massimiliano p.s.: Did you receive my mail with the URL for the instant messenger built around GUI abstraction? > **···** > > On Thu, Jul 25, 2002 at 05:26:38AM +0900, Tom Sawyer wrote: