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

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

Jeffrey Carter wrote:
> 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.

I see two problems developing with this:

1. deciding how to segregate the work between which widgets and tasks
    (ie. the infrastructure becomes more complicated because you now must
     decide which windows get their own tasks and which ones don't).

2. Each queue must contain a big case statement for all of the widget
    cases it must separate the code out for.  The callback approach only
    has to call all registered callbacks for _that_ widget, on its callback
    list. The callback is already specific to the widget, so no big case
    statement is required.

    This queue also suffers from the problem that you would need to code this
    ahead of time (you must plan a when clause for a particular widget in
    a queue's event processing section).  This makes it more difficult to
    handle dynamically created widgets (like popups), because you would then
    have to plan for it in the code. Whereas the callback is already there
    for any created widget.

Since GUIs often have widgets created and destroyed on the fly (like a message
box), I can't see this being very practical. The fact that I don't see any
GUI framework structured this way yet, suggests to me that there are reasons
why this is not practical. However, this is not to say that nobody should
try it ;-)

>> 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 is easier to call a callback list than to mainain a list of what
events to pay attention to or not, IMHO. It is certainly conceptually
cleaner.

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

Definitely a useful application of tagged records.

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

I was not being "critical" of JEWL, but merely pointing out that it does
have "limitations". This was one I noticed right away when looking to see
if I could make use of it.  Certainly for its intended use in teaching, it
does a wonderful job with its simple interface.

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

I don't think anyone was trashing these efforts. It is good to discuss
the strengths and weaknesses of the various tools from time to time.
Even mine ;-)  As software engineers, I think we can handle some
constructive remarks from time to time. 8-O

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