Separating GUI and code

[Gordon McMillan]

Andrew Cooke writes:

> I am designing an application which has a very close connection
> between the GUI and various objects in the code (there are also some
> aspects of the GUI which do not correspond so closely to the
> underlying objects).
> 
> I want to separate the GUI and the underlying functionality so that
> different toolkits could be used to provide different (but
> functionally similar) interfaces.

GUIs come in 2 broad categories - toolkits and frameworks. Since you 
plug into a framework, there's no chance of writing an app that can 
use alternate frameworks.

Toolkits, at first glance, seem more pluggable. But low-level API 
issues have a way of disrupting higher level logic. Try comparing the 
APIs of a couple tree controls. To write a wrapper that can handle 
that, you'll have to deal with the worst features of each, and 
probably won't be able to use the best features of any.

Event models also differ. Sometimes they are directed to the 
originating widget, sometimes to the containing widget. Now try 
porting to ncurses, which doesn't have one.

My experience is that the best you can do is to separate out all the
data-centered logic. That should be reusable, even between frameworks 
and toolkits.

The bad news is that GUI code is always verbose. If you're using a 
toolkit, you can expect around 80% of your code to be just GUI stuff. 
Frameworks require less code, but a good deal more learning.


- Gordon