Re: [OT] Best way to isolate a GUI?

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Jeffrey Carter wrote:
> Preben Randhol wrote:
>> How do you connect callbacks?
> 
> Callbacks are an excellent example of a tool's limitations affecting the 
> users' way of thinking (everything looking like a nail if you only have 
> a hammer).
> 
...
> If one were to design a windowing system with thinking expanded by the 
> use of a language with high-level concurrency features (like, maybe, 
> Ada?), I can't imagine anyone choosing this design. 

I find that the "callback idea" works ok if you design it in a
clean way (in Ada95 terms). I agree that the C method of hammering
things from void pointers into client data and widget data, is ghastly
at best.  A generic could deal with the client data aspect.

For input and output callback arguments, I use a discriminated record,
which then allows Ada95 checks on record members according to the event
type (ie. the record variation). This is something I wish GtkAda would
use.

> I would think you'd 
> want to associate a concurrent event queue for each window. A task in 
> the application would deal with the events for its window. It could 
> block on the queue to do nothing except respond to events, or it could 
> poll the queue periodically if it has other things to do as well.

This sounds conceptually nice, but it could prove to have practical
problems (I need to think about this more, myself). Thinking in terms
of an X11/MOTIF application, where there can be hundreds of windows within
windows to implement widgets on a form, this translates to hundreds
(if not more) of tasks. This smells a lot like overkill upon first
blush at least.

Additionally, where the application wants access to one event, it would
need to provide an entire task, and then have null handlers for all
the events it was not interested in (I think).  I think I'd need
to prototype this to get a better feel for this.

It might be easier to start with a tagged object, where methods can
be inherited and overriden instead. That way all events can just
do nothing, while you override the events you are interested in.
But this takes us back to a model similar to callbacks anyways, but
instead of registering a callback, you register a tagged record
to receive callbacks.

> While I like many things about GtkAda, one of the things I dislike about 
> it is that it hasn't abstracted away this C feature of the GUI. As a 
> result, it's harder to use tasking with GtkAda than it should be. CLAW 
> and JEWL, for example, have abstracted callbacks away to different 
> extents. JEWL effectively implements the concurrent event queue 
> abstraction on top of Windows.

I can't speak for CLAW, and the one shortcoming I see in JEWL is that
you cannot get "focus events". But the last time I played with GtkAda
I didn't like the callback structures either. They were too prone to
error, because of the data marshalling issues, IIRC.

I would much rather that callbacks used discriminated records that
matched the event type. Then everything compiles well, and is
thoroughly checked, admitedly, some of it at run time. Most of all,
the callback becomes a well documented interface, and is simple to
code for and understand.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg