GUI's and the Rouge, Part III (yes, finally) 1/2

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

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 :frowning: 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 :wink:

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:

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 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
Panoptic Computer Network web: 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)

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?

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

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
GPG key ID: BEEA7EFE

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 wrote:

On 2002.07.24, Benjamin Peterson 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)

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.

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
GPG key ID: BEEA7EFE

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 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)

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. :slight_smile:

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: