[GUI] Setting properties of a widget.

[Axel Simon]

On Sat, Mar 29, 2003 at 08:34:00AM -0800, David Sankel wrote:
> --- Axel Simon <A.Simon@ukc.ac.uk> wrote:
> > I assume everybody is on holiday,
> > 
> > just a mail to keep the discussion on the core
> > functionality going. So far
> > it seems that we would like the following features:
> > 
> > a) mandatory arguments
> 
> Can someone give me an example where mandatory
> arguments are required for a GUI toolkit?  Right now,
> I can't think of any attributes that couldn't have
> reasonable defaults.
 I am fine with supplying mandatory parameters as arguments to the 
constructor.

> > b) read-only arguments
> 
> I'm assuming that these are things like getting a
> button's pixel width and height, which are a function
> of its contents.
 Yes, I think that would be an example.

> > c) write-only arguments
> 
> I can't think of any widgets that could utilize this
> in an elegant way.  Perhaps the callback list?
 You mean adding a callback? Yes. I guess the need of write-only is 
reflected in GIO by the special "on" function which takes the name of the 
callback. So if we have write-only parameters, we might have simple 
attributes like onClicked instead of "on clicked".

> > d) setting a property and getting a result
> 
> This would be most useful for setting callbacks and
> returning the removeHandler.  Is there any other place
> where this would be useful?  Perhaps this is a special
> case?
 Might be. But callbacks are very important and there will be plenty of 
them. So it would be nice to have the same infrastructure for them as for 
the other attributes.

> > Regarding the unregister callback issue, I thought
> > of the following: Maybe
> > we can have the set function just taking one
> > argument:
> > 
> >  set button $ on click =: messageBox "hi there" 
> 
> since there is no character savings between the above
> and
> 
> set button [on click =: messageBox "hi there"]
> 
> I would vote against it.  I would rather make onClickH
> a seperate function that returns the unregister
> function.
 For symmetry, we should then use a "setTitle" function to set the title
of a window. But then we're back to a set of IO functions and programs are
very elaborate (and imperative). I'd rather have one medium-level syntax.
Having two names for the same callback is just wrong IMHO because it makes
the interface twice as big and the user needs to learn two syntaxes.

If we keep "set" taking a list of instructions, could we have a special 
setSingle which sets a single attribute and returns whatever setting that 
attribute returns (e.g. a remove function for a callback). That makes a 
special case of registering a callback with remove function but doesn't 
double the number of functions needed by each callback.

> On another note, I want to point out the difference
> between using onClick and "on click".  What are the
> benefits of using the second, more verbose, form?  It
> is, IMHO, more confusing that the other version.
 Dunno, maybe Daan can justify this.

Axel.