
On Sat, Mar 29, 2003 at 08:34:00AM -0800, David Sankel wrote:
--- Axel Simon
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.