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

[Jeffrey Carter <jrcarter@acm.org>]

Warren W. Gay VE3WWG wrote:
> 
> 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.

I wouldn't think you'd want a queue for every widget. I'd think one per 
top-level window would be about right. The events in the queue would 
have to identify the widget that generated them. In some cases you'd 
have a task for every window, while in others one task might handle the 
events from several windows. It's a question of what the problem's 
concurrency needs are, not what the windowing system forces on you. You 
wouldn't be forced to declare any tasks, if tasking's not appropriate to 
the problem.

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

There can be an awful lot of different events from a window. I would 
think you could tell the system what events to report and which to 
ignore, with a default set that is frequently useful. Then, if you're 
only interested in the close event from a window, it won't send you 
anything else.

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

This is the approach taken by CLAW. A widget is represented by a tagged 
type, with primitive operations that are called automatically when 
certain events occur. There are default versions of these operations. To 
create a widget with specific behavior, you have to extend the type and 
override the appropriate operations. This can be useful when you want to 
have data associated with a widget, as you can define the data as part 
of the extension, give the widget values when you create it, and check 
the values in the operations. But when all you want is to define the 
application's behavior when the user clicks a button, it seems like 
overkill. Consider a window with lots of buttons, different behavior 
when each button is clicked, and little or nothing else in the way of 
user input. This calls for many extensions and many overridings of the 
appropriate operation. It differs from callbacks in not requiring 
operations to be registered with the windowing system, but similar in 
that the windowing system controls your application.

> I can't speak for CLAW, and the one shortcoming I see in JEWL is that
> you cannot get "focus events".

JEWL is deliberately a simple system, and the lack of some features is 
the price of that simplicity. The concept of the application actively 
requesting events from the windowing system is one that could be applied 
to a more complex windowing system.

Nothing's perfect, and GtkAda and CLAW represent a lot of good work. 
JEWL is very good, too, for its application area of providing a simple 
windowing system for beginners.

-- 
Jeff Carter
"My name is Jim, but most people call me ... Jim."
Blazing Saddles