>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