[GUI] RFC: CGA-Example 1.2 stuff

[Wolfgang Thaller]

> Before I finish CGA-Example 1.2 we ought to reach a sort of concensus 
> on certain issues.  Here is what I think will be in 1.2.  This is a 
> RFC:
> ####
> ## 1.  A matching LaTeX specification.

Sounds good.

> ####
> ## 2.  toWidget out of IO Monad.

> That is if we want to continue with this route.  The other route being 
> the class hierarchy.
> Benefits of toWidget style:

I'm not sure if I got the terminology straight...
Does "toWidget style" mean there will be more pairs of functions like 
toWidget/fromWidget, or does it just mean "keep fromWidget and toWidget 
in there"? If it's the second: I vote YES, as long as it doesn't 
include Windows, if it's the first, I vote "no, for now".

> Allows for lists of widgets.

Yes. That's why I think we need it (or at least something like it) for 
implementing dynamic layout.

> ####
> ## 3.  Multiple Callback Support with unregister support.
> This is fine and dandy minus the implementation details.  If this is 
> implemented in Haskell, we have two possible ways to do this.  These 
> refer to each callback list instance.
> a) We maintain a list of IO callback methods.  Each callback is 
> identified by it's index in this list.  When a callback is 
> unregistered, it's index is changed to the (return ()) callback.
> b) Each callback is given a unique identifier by some generator.  When 
> a callback is unregistered, it will filter the list and remove the 
> invalid callback.

a) is good enough for a sample implementation, but in the end, I'd 
recommend b) (for platforms where multiple callbacks aren't implemented 
in the foreign toolkit library).


> ####
> ## 4.  Is a Window a Widget?
> a)  No Windows.

Sounds like a nice idea, but no. It's too "strange" (in the sense of 
"new"), we don't know yet if it can work properly, and it adds 
complexity to implementations.

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

> ####
> ## 5.  Adding children to a parent.
> If 4a) was implemented, we could talk about widgets independent of 
> parents and it wouldn't be a problem on Mac.

The problem would still be there; but part of the complexity would 
already be necessary due to 4a.

> 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. The backend would have to keep 
a Haskell data structure with the values for all attributes that have 
been set; the native widget could only be created when the container 
(or, in the case of Mac OS, at least the window) became known.
If someone moves a widget from one window to another, the Mac backend 
would have to automatically destroy the widget and create a new one. I 
think we can live without that functionality for now.

> ####

> ## 6. certain Has* functions need to be made for every widget
> The fltk implementation is more verbose than it needs to be.  I could 
> have made these redundant functions transform the item into a 
> Fl.Widget for a default.

Yes.
Most importantly, we will need CGA.Widget to be an instance of certain 
Has* functions, too, in order to implement dynamic layout managers like 
GridBox. The GridBox would have a list of widgets to lay out along with 
the corresponding layout attributes, and then it would have to query 
the widgets for things like minimum size, preferred size and so on, and 
then modify the layout of the widgets. So we do need access to that 
default.

> ####
> ## 7. Heiarchy
> Should there be an object hierarchy?  Since this is a simple thing to 
> add after it has been implemented with the Has* functions, I suggest 
> we push this back.  Since toWidget is simple enough for now, I think 
> we should stick too it. (I'm interested in counter-opinions though)

I agree.

Please also have a short look at my last posting in the "Re: [GUI] Are 
windows just ordinary widgets?" thread. It contains a snapshot of my 
thoughts as of yesterday evening...


Thanks for your work on the CGA Example; I think the example 1.1 has 
already brought the discussion a great deal forward.

Cheers,

Wolfgang