--- Vincenzo Ciancia wrote:

also:

e) ability to watch and filter the changes made to attributes (implementing this as a derived feature would allow bypassing the filters)

I'm not sure what you mean by filter? Something like an onTitleChange callback?

f) atomical modification of attributes (like modifyMVar)

I think GIO handles this pretty well with the :~ operator. set button [ title :~ (\a -> "Prefix: " ++ title) ]

g) default values for unspecified attributes

I think GIO attributes handels this elegantly as well. David J. Sankel

On Fri, 28 Mar 2003 19:02:04 +0100 Vincenzo Ciancia wrote:

g) default values for unspecified attributes

Another thing that comes to my mind is that sometimes one could need to atomically give a sequence of values to an attribute. This could be done with a function to lock an attribute: lock :: Attribute a -> IO (Attribute a) release :: Attribute a -> IO () where the result of a lock operation is an attribute wich is a representation of the original one, and the only one allowed to make modifications until release, or perhaps in a simpler way with putList :: Attribute a -> [a] -> IO () Someone wants to comment on this? V.

On Mon, 31 Mar 2003 16:16:12 +0100 Axel Simon wrote:

I can think of an example for filter, but where would this be useful?

There are plenty of possibilities, depending on the model we use. For example, one could disallow writing more than one line in a statusbar, since the statusbar has only one line, and allowing more lines would need other specifications, such as a "delay time", but if one wants to write two delayed consecutive lines he needs the possibility to atomically do so. Many other examples, that I can think of now, are connected to some form of animation, but I guess that there are other possibilities. Vincenzo

On Sat, 29 Mar 2003 08:34:00 -0800 (PST) David Sankel wrote:

I can't think of any widgets that could utilize this in an elegant way.

When you modify a state of type a by setting a property of type b, or by changing something that it's not the "whole" state, you get an example of a write-only property. This is not the only way to model the... thing. Consider a progress bar or a volume control, where you can increment the value by a relative amount. This is a write-only property, but only if you want to model the interface of a relative increase by a property. There might be better ways. Vincenzo

On Mon, 31 Mar 2003 04:33:10 -0800 John Meacham wrote:

mandatory arguments could be modeled by arguments to whatever the widget creation function is. since said arguments are not mutable, exposing them via the get/set interface doesn't seem to make as much sense.

But are we sure that there aren't mandatory arguments that can be subsequently changed? These seems two orthogonal concepts to me. V.

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.

On Tue, Apr 01, 2003 at 01:22:45AM +0100, Glynn Clements wrote:

Axel Simon wrote:

...

...

...

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.

I don't think that it makes sense to treat callbacks as attributes. The underlying UI toolkits don't generally take this approach.

Gtk treats them as attributes. But I take your point. Callbacks would otherwise be the only "attributes" which return something when they are set. So I'd vote for this. Axel.