Re: [OT] Best way to isolate a GUI? (The final concensous?)

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

Marin David Condic wrote:
> Well, if you use an existing GUI such as Windows or Motif, you are *going*
> to have callbacks. I'd prefer to isolate them in some kind of wrapper layer
> and have the "real" app receive messages of some sort. If you were building
> a GUI from bottom dead center, you could build that sort of thing right in.
> I'm just saying I think that callbacks are an ugly kludge that I'd prefer
> were done a different way. You might be able to get there with existing GUIs
> & glue or wrappers or skins or whatever you like to call it. Just expressing
> a desire to see an interface to a GUI that doesn't have to know anything
> about the code *I* write. :-)
> 
> MDC

If we were to belabour this discussion a bit further, it seems to me
there are two points worth discussing here:

   1) What is it about callbacks specifically that you don't like?
      I think this needs to be defined beyond "ugly kludge".

   2) What other suitable models are there (with pros/cons)?

The problem that we're dealing with here is an event driven system.
Callbacks are similar to interrupt programming as you've stated.
Outside of the callback (in most GUI apps), you have a main loop
that basically receives events and dispatches them (invoking ultimately
in some cases, callbacks).

The things I dislike about callbacks include:

   1) restricted access to application data (normally just "user data").
   2) each event code is a separate procedure (some may see this as a
      feature).
   3) code restrictions: ie. you must not tarry too long there, or you'll
      hang the main loop (making it not respond to more GUI events).
   4) more code restrictions: sometimes there are some GUI related
      operations that are restricted within a callback (much like malloc()
      is unsafe in a UNIX signal handler).

If we were to move to a task centric model, how would the application
register (link) a task entry (queue) to a specific widget?  It has
been a while since I have played with tasking, so is it possible
(for example) to gain the address of an entry (queue)?  (This is
similar to the idea matching Qt's signals with slots, except we've
introduced a tasking model). Assuming you can't take the address of
a task entry, the only way I can see this working is via a procedure
(callback) that then calls the task entry (a layer proc).

One should note however, that "main loop" hangs are still possible
if you don't plan your task model correctly. For example if one
event takes too long and another comes along before it finishes
(because the user is clicking the button again), the rendezvous
will block until the task is able to accept another request.
To avoid this of course, you could pass off the request to a
separate task, but then you'd have to manage the backlog that an
impatient user might create by hammering a button repeatedly.

I am having a little trouble picturing how this tasking model
can be done, with my limited experience with tasks in Ada.
Would you be able to use a entry "family" number to link
these together dynamically by use of the number? I'll have
to dig out my tasking book tonight.

I am intrigued by this idea.. just trying to picture a practical
implementation of it.

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