[GUI] Another RFC on setting and getting.

[David Sankel]

--- Glynn Clements <glynn.clements@virgin.net> wrote:
> 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