[GUI] Setting properties of a widget

[Krasimir Angelov]

On Sat, Mar 29, 2003 at 08:34:00AM -0800, David Sankel
wrote:
> > c) write-only arguments
> 
> I can't think of any widgets that could utilize this
> in an elegant way.  Perhaps the callback list?

I don't like write-only attributes. Usually I think
about attributes as special kind of variables. For
read/write attributes the get function will always
returns the value which was set from the last set
function call. The only exception is when the property
value was changed from some kind of external action
(example: the "text" attribute for "edit" control
changes when the user types in the box). In such case
there needs to have an event which to fire when the
ąction occurs. The readonly attributes are also
acceptable, but the writeonly is a litle bit strange
for me. Setting of some writeonly attribute looks just
like execution of some operation. In the Vincenzo
example:

On Sat, 29 Mar 2003 21:18:10 +0100, Vincenzo Ciancia
wrote:
> 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.

I prefer to use the function:
incrProgress progress d = 
    set progress [pos ~: \x -> x*(1+d)]

instead of writeonly attribute.

On Mon, 31 Mar 2003 15:13:00 +0100, Axel Simon wrote:
> 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".

The "on" function in the GIO doesn't mean write-only
attribute. The "on" function converts Event to Attr

on :: Event w a -> Attr w a

The returned attribute is read/write. The following
example explains this:

oldhanlder <- get button (on click)
set button [on click =: f >> oldhandler]

or

set button [on click ~: \oldhandler -> f >>
oldhandler]

This property allows to attach more than one handler
to single event. The disadvantage is that the attached
handlers cannot be removed independently. To remove
the "f" handler in the above example we need:

oldhanlder <- get button (on click)
set button [on click =: f >> oldhandler]
... some code ...
set button [on click =: oldhandler]

The disadvantage here is that if the internal code
attaches additional handlers to "click" they will be
removed along with "f", but I think that the case
doesn't exists very often.

On Mon, 31 Mar 2003 16:43:49 +0200 Vincenzo Ciancia
wrote:

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

In my opinions setting multiple values to single
attribute is not reasonable. But there is one thing
which I propose. The ~: operator should be thread safe
for that reason the current implementation for Attr in
the GIO should be changed:

current:
data Attr w a = Attr (w -> IO a) (w -> a -> IO ())

new:
data Attr w a = Attr (w -> IO a) (w -> a -> IO ()) (w
-> a -> IO a)

Where the last function is "update" function. This
will allow treadsafe ~: operator and also will
increase performance in some cases. Maybe we need to
have functions to synchronize on widgets instead of on
attributes. In such case we have:

lock    :: Widget w => w -> IO ()
release :: Widget w => w -> IO ()

All the best
Krasimir

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://platinum.yahoo.com