--- Glynn Clements
Axel Simon wrote:
- Callbacks get separate functions which called on<WidgetName><ActionName>
Just on<ActionName> would be better. The "activate" callback is the same callback whether it's a push-button, toggle-button, etc.
I agree with this.
I would like propose the following basic setup, together with the questions how read only attribute can fit in. Write only attributes could be easily added by just supplying "pushButtonNow :: Setter Button", albeit breaking the := syntax - you'd have to say set b ["Hello" =: label, pushButtonNow]
Read-only or write-only attributes could be implemented by throwing an error for prohibited operations. Read-only attributes could be implemented by simply ignoring write operations.
Although I haven't discovered a use for write-only attributes for a gui toolkit, it seems that it would fit clearly in the constructor. newSomething requiredArgument [attribute := list] For read-only attributes, you would most always want to read the value and nothing else. h <- getHeight myButton And for read and write attributes, the attribute mechanism works fine.
Here it is:
-- An attribute is a property of a widget. It knows how to set the -- and how to read the value of this property. data WidgetClass w => Attr a w = <abstract>
Using "WidgetClass" will confuse anyone who is used to Xt. With Xt, a "WidgetClass" is a (pointer to a) record which describes the class itself; the individual widgets have type "Widget". In traditional OO terminology, "WidgetClass" is the metaclass of the "Widget" class.
I don't know anyone who has used Xt; I've only been in the programming business for 8 years. Consequently, I don't think we should make sure the names don't conflict with the naming scheme of some old libraries.
-- An example for a Button widget: The constructor has one -- mandatory argument. newButton :: Container -> [Setter Button] -> IO Button
1. This omits widget name, which should be mandatory.
This has been discussed thoroughly earlier. There didn't seem to be a consensus to do this. I suggest that this be an CGA implementation specific extension. myButton <- newButton [ title := "Okay", i_name := "RightButton" ]
-- The Button has at least this attribute. label :: Attr String Button
So do labels, toggle buttons. Is a label's label really different from a button's label?
I agree that things like this should use classes: class HasLabelAttribute a where -- ...
"Clicked" is likely to be an inappropriate name. E.g. several Motif widget classes have an "activate" callback. For a push-button, this may occur either as a result of clicking on a button, or using the keyboard accelerator (Alt + underlined character), or moving the keyboard focus to the button then pressing space. Either way, it's the same callback.
I agree, activated is a much better name than Clicked for the button example.
More importantly, most callbacks will need to take one or more parameters which provide further information about the event. E.g. for Motif's XmPushButton, the information passed to the activate callback allows the callback to distinguish between single/double clicks. For more complex widgets (e.g. text fields), substantially more information may be passed.
We would need a CallbackData class in order to provide a generic function for adding callback handling, e.g.
I do not think a class is necessary. But for signals that do have arguments, I suggest we put the arguments in a tuple. There will be several times where the library user would wish to ignore arguments and this would make it simpler. onCurserPositionChange (paragraph, position) = -- ... onCurserPositionChange _ = -- ... David J. Sankel