Re: A community Windows binding

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

Nick Roberts wrote:
> Jeffrey Carter wrote:
>> Between callbacks and the single queue of events for all windows of 
>> JEWL is an approach more suited to concurrent languages: multiple 
>> queues, one per top-level window, with the assumption of one task per 
>> queue/window. There should be the ability to select what events will 
>> be put in the queue, and the possibility to combine queues when a 
>> window doesn't merit its own task. Such an approach should scale 
>> better than JEWL's single queue, and be more readable than callbacks.
> 
> I have long felt that the approach most suited to a concurrent language 
> (such as Ada) is for the 'window manager' to be a separate task, or 
> possibly many tasks.

At the end of the day, a task begins to look like a callback,
with the exception that the delivery mechanism is different.

I can only see 4 ways to deal with GUI events :

1. The JEWL big main loop approach
2. The callback approach (Windows)
3. The "pipeline" event approach (X Window)
4. The "method" calls in an OO structure for
    certain events (Java/C#), and the use of
    inheritance to gain control during certain
    events. This is very similar to #2, except
    that inheritance allows installed callbacks
    through overrides.

Ada tasks IMHO, are a variation of #2. In fairness,
#4 is very similar to #2 as well.

I don't believe #1 is practicle for a large application:
   - the main loop is too large code-wise
   - many cases (harder to modularize)
   - unwanted coupling between cases is possible through
     shared objects/code in the module containing
     the main loop(though this can be avoided).

People dislike #2 for various reasons:
   - perhaps complexity
   - distributed code (too little coupling?)
   - difficulties with "user data" parameter/type

The X Window approach has its own problems:
   - performance: latency between request and
     event response (in synchronous mode), but
     this makes error handling easy and neat.
   - error handling: (asynchronous mode) it is
     very messy tracking requests vs returned
     responses (often X Window programs ignore
     returned errors because they were n events
     ago). This leads too poor quality of app.

My biggest beef for callbacks and similar techniques
is the need for the "user data" parameter. I don't
have a problem with the callback mechanism itself,
but for Ada the "user data" type and parameter is
usually a problem.

If however, some main object for an application
was used and made available in every callback,
then the application can extend that and gain
access to custom application values. I seem
to recall that some GUIs do it this way, which
seems about right to me.

...
> All that a simple program (with no separate tasks of its own) needs to 
> do is to set up the components, and register them with the window 
> manager. 

But the process is much the same. Registering a callback or
an object, is a very similar process (or burden ;-)

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