[GUI] GUIs and events/callbacks.

[Glynn Clements]

Wolfgang Thaller wrote:

> Am I overlooking some subtle semantic differences? To me, it looks like 
> (non-composable) events can easily be implemented on top of callbacks 
> using Control.Concurrent.Chan.

I hope so (see my recent worried-sounding reply to Vincenzo); I
suspect the key point is whether the application programmer can
control (directly or indirectly) whether or not a callback is
registered. Basically: registering a callback which does nothing and
not registering a callback aren't necessarily the same thing.

> And it shouldn't be too difficult to implement callbacks on top of 
> events...

But composing the two conversions needs to be the identity function,
or at least a very close approximation to it.

The kind of events that you would get from XtAppNextEvent() and from
registering callbacks that manufacture events are very different. The
raw X events from XtAppNextEvent() are mostly meaningless to an Xt
program. The complexity of XtDispatchEvent() (plus all of the
widget-class-specific handlers which it may invoke) is such that you
can't realistically comprehend the connection between the raw event
stream and the behaviour at the callback level.

Most Xt programs just call XtAppMainLoop(), which is basically just:

    do {
    	XtAppNextEvent(app, &event);
	XtDispatchEvent(&event);
    } while(app->exit_flag == FALSE);

The only plausible reason why you might wish to implement your own
main loop is if you need to do something else as well (without
actually interfering with the event stream in any way). Ultimately,
you still have to pass all events to XtDispatchEvent() in the order in
which they arrived, unless you actually want to spend all of your time
trying to figure out why the program no longer works.

> If the above is true, then I'd say we implement callbacks first, we can 
> easily add events later. Events look like a higher-level concept to me, 
> as they seem to require concurrency to be meaningful. They could be 
> added as an add-on-library, but IMHO we probably don't need them in the 
> spec right now.

That sounds reassuring; I was starting to worry that the "event"
concept was talking about raw events at the window-system level.

> Which leads us to another big question: Concurrency.
> The CGA should probably be safe to use from many threads at once 
> (although many backends aren't, so the library would have to do a lot 
> of synchronizing). Should callbacks for multiple clicks on one button 
> really run concurrently, or should it behave like most toolkits for 
> other languages? I know of no "conventional" toolkits where event 
> handlers for one event source are run concurrently. It sounds 
> dangerous, but it might have advantages.

My gut instinct would be to allow concurrency only if the backend is
threadsafe, or if only one thread uses the GUI directly. Given the
complexity (and variability) of the control-flow in typical toolkits,
trying to manufacture thread-safety by imposing serialisation smells
like a recipe for deadlock.

-- 
Glynn Clements <glynn.clements@virgin.net>