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

On Wed, 2002-07-24 at 04:04, 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?

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