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