[GUI] RFC: CGA-Example 1.2 stuff

Axel Simon A.Simon@ukc.ac.uk
Sat, 3 May 2003 16:59:49 +0100


On Fri, May 02, 2003 at 06:08:19PM +0100, Glynn Clements wrote:
> 
> Wolfgang Thaller wrote:
> 
> > > b)  Windows are not widgets.  This can be done easily enough.  It is 
> > > less elegant as a) IMHO opinion.
[..]
> > I'm for b), in the sense that Window should not be an instance of 
> > IsWidget.
[..]
> I'm dubious as to the implications of trying to declare that windows
> aren't widgets on backends where windows really are widgets.
> 
> Implementing the fiction is easy enough; you just end up with lots of
> pairs of functions with different names (e.g. getWidgetSize,
> getWindowSize) which happen to have identical implementations. The
> problems lie in keeping up the illusion; unless you trap every single
> place where widgets escape to Haskell-land, code will end up being
> passed widgets which turn out to be windows.

If I may poke around in the future of our discussion, I see different 
types of application setups: SDI, MDI, Control. These could be special 
toplevel windows. Thus I think making Windows and Panes distinct is the 
better solution (or: illusion).

> In case I haven't made this point enough already: I consider total
> portability to be a chimera. Sun put a lot of effort (more than we
> have the resources for) into it for Java, with the net result that
> even simple Java applications look decidedly non-native on all
> platforms, and they still didn't entirely get rid of portability
> issues.

I do believe we can make some functionality available that does look 
and feel totally native, provided that
a) the user codes careful (e.g. provides different resource files for 
different platforms)
b) we restrict the CGA appropriately


> My other point is that, when a trade-off has to be made between
> portability and native-ness, it should be up to the application
> programmer as to which aspect wins. If the CGA ends up forcing a
> particular set of compromises onto the application, the first time
> that a developer is unable to accept those compromises they will end
> up writing their own UI library (and, in the process, reducing the CGA
> to being just another UI library; it's only *the* UI library if we
> don't need any others).
Yes, we shouldn't stand in the way of using the native backend's 
functions. But we have to make a decision on the core functionality, or 
don't you think so?
Our aim is that an application written just with the CGA should work with 
all backends. If Windows and Panes have the same root on one platform but 
not on another, then you cannot write an application that runs with 
different backends!?

Axel.