[GUI] RFC: CGA-Example 1.2 stuff

[Glynn Clements]

Wolfgang Thaller wrote:

> > b)  Windows are not widgets.  This can be done easily enough.  It is 
> > less elegant as a) IMHO opinion.
> > c)  Windows are widgets.  We must think about and handle the cases 
> > when a window is not a parent.
> 
> I'm for b), in the sense that Window should not be an instance of 
> IsWidget. Implementing a common generic type for Windows and 
> Controls/Panes is tedious/artificial on MacOS.
> I see no problem with Window being an instance of classes like HasSize, 
> HasTitle etc. and providing many features that other widgets have.

So, if you take an arbitrary widget, and find all of its ancestors
by repeated application of getParent (or whatever it's called), where
do you end up?

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.

> > Benefits of parent construction:
> > Writing backends for Mac platforms would be easier.
> 
> In fact, if parents are not mandatory arguments to the widget 
> constructor, writing backends for Carbon (Mac OS) and Xt (Motif) would 
> become perhaps about twice as much work.

On Xt, it would become almost impossible, given that most of the
attribute values get initialised at the point that the actual widget
gets created.

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.

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).

-- 
Glynn Clements <glynn.clements@virgin.net>