[GUI] RFC: CGA-Example 1.2 stuff

[David J. Sankel]

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. 

This will include a section for platform specific extensions via the module 
system.  There could be implementation (toolkit,back-end) specific 
extensions where the implementation is called IMPL.  Those would go under: 

CGA.extentions.IMPL 

Their might be general extensions that might intersect implementations.  
Lets say the extension is called OpenGL: 

CGA.extentions.OpenGL 

And for extensions that use a different constructor (with the extension 
named EXT, we would use: 

data T_EXT = A_EXT Int | B_EXT float . . . 

####
## 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:
 Allows for lists of widgets.
 Allows for compositional construction of new widgets. 

Negatives of toWidget style/Benefits of class Hierarchy:
 OO style of custom widget construction
 No lists of Widgets.
 How would children work?
 Class hierarchy probably will not match all backends. 

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


####
## 4.  Is a Window a Widget? 

a)  No Windows. 

A window is certainly different than an ordinary widget.  It doesn't make 
any sense to have a window as a child of another window.  However, we may, 
perhaps, be able to remove the window completely from CGA.  (this may be a 
bit too different). 

Lets say that an object without a parent can be displayed on the screen.  
So, if I say 

> a <- mkButton [ label := "okay", visible := True ]
> doOnActivate a (exitWith ExitSuccess)

I will get a button on the screen with the title bar stating "okay" with the 
label being "okay".  Or perhaps the title bar says nothing.  Simple 
applications don't require messing around with windows.  A window is simply 
the highest parent in the family.  This way everything can logically be a 
widget. 

What about specialized windows with titlebars, etc.  For some widgets, say 
VBox, we may want added attributes like title.  Eventually when we get to 
cross-platform application widgets (with menu's, etc . . .) we just make one 
of these the highest in the hierarchy.  If it is not the highest, it could 
still be useful . . . say in a gui builder. 

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. 

####
## 5.  Adding children to a parent. 

Certain widgets and windows can have children widgets.  How do we add them? 

If 4a) was implemented, we could talk about widgets independent of parents 
and it wouldn't be a problem on Mac. 

Otherwise, we need to assess the usefulness of creating a widget without a 
parent. 

##
Benefits of no-parent construction: 

 Code for certain container class would reflect the thinking of the 
programmer more and makes for easy change.  For example: 

> set container [ children := [name, address, phoneNumber] ]

could be quickly rearranged to 

> set container [ children := [name, phoneNumber, address] ]

 For certain containers, such as GridBox, the name of the child as well as 
other parameters must be set to make it a child.  This creates problems. 

##
Benefits of parent construction: 

 Writing backends for Mac platforms would be easier.
 It doesn't make any sense to create a widget without parent (unless 4a was 
implemented) 

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


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

 --------------------------
David J. Sankel
Head Consultant
Electron Consulting
www.electronconsulting.com
 --------------------------