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