On Dienstag, Mär 18, 2003, at 12:33 Europe/Vienna, Daan Leijen wrote:
Hi all,
2) For every callback, there should be a register function. The register function should return an IO action that can be used to unregister the callback.
I disagree with this design. It is very awkward to install callbacks this way as we have to maintain the "unregister" function. We can no longer use "nice" syntax like:
button [on click := messageBox "hi there"]
Yes, that looks nicer, but it now we can have only one callback for one event; I believe the people who first brought this design up (I was only copying what I had read on this list) were thinking of allowing multiple callbacks to be installed for a single event, as can be done using GTK's signal/slot mechanism. So what about... 2) Installing Callbacks 2a) For every callback, there should be a register function. The register function should return an IO action that can be used to unregister the callback. There can be multiple callbacks for one event. 2b) Callbacks are set using a general attribute get/set mechanism that we will probably design soon. There can be only one callback for one event. Please note that it is very easy to emulate one option using the other, so the features of the backend libraries are probably not an issue here. 2a can, of course, be useful in many situations. I'm not sure if I want the nice syntax or the nice functionality, so I withdraw my vote on 2) and abstain for now. Everyone please keep discussing :-) I'd like to provide an example of where I'd prefer to have 2a: Suppose we have a document window. In order to support a "Save Changes?" dialog, I'd perhaps add a callback for the "window about to close" event. No problems here. Suppose that we also have a utility window that shows information about some item in the document. When the document window closes, the utility window closes, too (we'd like to have a second "close" callback on the document window), but the utility window can also be closed by the user before the document closes (we'd like to uninstall our "close" callback in that case). In most other situations, I would probably prefer the single-callback approach because of the opportunities for nicer syntax.
This mechanism is enough to build a nice framework around. For example, you could add a callback to the existing ones.
buttonAddOnClick io button = do prev <-buttonGetOnClick button buttonSetOnClick (do{ io; prev }) button
Which is fine as long as you don't want to uninstall a callback. And we might want to use a threadsafe buttonModifyOnClick :: Button -> (IO () -> IO ()) -> IO () instead.
The only think lacking is indeed the "unregister" call but I think it is a highly unusual thing to deinstall a callback without replacement on an existing widget. Normally, the callbacks are deinstalled when the widget dies. But for completeness, we might want to have:
buttonIgnoreOnClick :: Button -> IO ()
Definitely. For button clicks, it is a non-issue, but some X folk have said that mouse moved events are really bad for remote connections, and I wouldn't bet it's so unusual to track mouse movements only for a short period of time and then uninstall the callback. Cheers, Wolfgang