Hal Fulton wrote:

>> I would also like to reinforce this theme: A core "engine" with no 
>> gui. The
>> gui can then be developed independently or, if you wish, separate (but
>> similar) gui applications can be written that all use this same core 
>> engine.
>
>
> In practice, I find this difficult.
>
> To get back to basics: I think the GUI serves as an I/O mechanism.
>
> Sometimes the engine drives (calls) the GUI, to fill a window with data
> or throw up a window or whatever.
>
> Sometime the GUI drives the engine: The user pushes a button, and an 
> engine method gets called.
>
> Hmm, can we separate these logically? Make two modules or classes,
> perhaps?

the engine doesn't need to know the user entered the data, or whether 
it's from a preference file etc. no need for the engine to open up a 
window. the engine justs gets parameters with the input values and spits 
out output values. if the engine wants to display warnings or whatever, 
it should send "events" or exceptions for the GUI to pick up. the GUI 
can display a dialog box, something in the system tray etc. the engine 
doesn't know and doesn't care. this exists and is quite spread. consider 
mp3 playing libraries and mp3 players, libavcodec and xine and mplayer 
etc, or even cdrecord and CD burning apps under linux (although then the 
connection engine/GUI is more loose because the engine is a full-blown 
text app).

emmanuel