[GUI] Another RFC on setting and getting.

Glynn Clements glynn.clements@virgin.net
Mon, 7 Apr 2003 07:48:21 +0100


David Sankel wrote:

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

While it may not be used much in the free software ghetto (Athena is
primitive, and Motif wasn't commonly available on free Unices until
recently), Motif is still widely used in commercial Unix/X11 software,
and is likely to remain so.

BTW, I'm curious as to what you were using 8 years ago; neither GTK
nor Qt were around then.

> > > -- 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" ]

This would mean that a missing name would be a run-time error, when it
should be caught at compile time.

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

1. Records (with named fields) would be preferable to tuples; Some
callbacks get passed a significant amount of data.

2. This approach requires a different function for each type of
callback. I would prefer a single polymorphic addCallback function.

-- 
Glynn Clements <glynn.clements@virgin.net>