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

["Robert C. Leif" <rleif@rleif.com>]

Marin Condic wrote, "Give it some thought. I think that one might be able to
evolve some kind of low-level wrapper/post-office/client-server thingie that
could decouple the app from the GUI in a way that might allow multiple GUIs
and GUI builders to be working at the other end."
I suspect that this "thingie" could be an extensible protected type. It
would be a combination of a tagged and a protected type. It was suggested at
SIGAda 02 that this construct would be very useful for real-time code.
I hope that one of the Ada language experts who attended SIGAda might
comment on this.
Bob Leif

-----Original Message-----
From: Marin David Condic [mailto:mcondic.auntie.spam@acm.org] 
Sent: Saturday, February 22, 2003 6:50 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: [OT] Best way to isolate a GUI? (The final concensous?)

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
news:3E5669C8.30305@cogeco.ca...
>
> 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".
>
I kind of expressed that in another post. It means that the GUI has intimate
knowledge of my code - much like a computed goto or passing path-flags into
a procedure. It dictates to me what my app must look like (Thou shalt have a
procedure that looks like this and has these parameters and will react in
this way to this event. What if I want to deal with that event in a task?
What if I want one big procedure dealing with 50 different events? What if I
want to run around the office stark naked with a rubber glove on my head
yelling "I'm A Squid! I'm A Squid!" :-) It's none of the GUI's business what
I do or how I choose to do it. It needs to provide me with some sort of
"event" and I need to figure out what to do with it from there.) Callbacks
also start dictating to you that you do things with a particular language -
or at least calling convention. You can write Ada callbacks for C-ish GUIs -
its just painful. I'd prefer something language agnostic and messages are
much more in that realm. I think apps are beter designed when the only thing
they see is the *data* rather than the mechanism by which the data gets
there. Messages/Events are going to be closer to simply reading a data file
than callbacks are going to look like. For those reasons and more, if I were
to invent a GUI from bottom dead center, it wouldn't have a single callback
in it.



>    2) What other suitable models are there (with pros/cons)?
>
Since you're dealing with an "event" of some sort - you've got a kind of
"command/response" protocol - albeit, possibly very asynchronous and loosely
coupled. I've seen a couple of ways of handling that with messages. You
build one big hose and send all the data up and down that hose (a single
queue) or you create some kind of mailbox/post-office kind of thingie where
various threads of an app (or processes in a computer) register for events
they are interested in and  they start receiving them in their mailbox. If
they want to communicate with some other part of the system, they post a
letter via the post office. Both are going to consume a bit more time than a
callback will, but I think thats negligible for most apps. Both require some
level of message management underneath the GUI skin. Both are going to
require that you have some rather large catalog of messages - but no worse
than having a large catalog of callbacks.

Its been done before, so it isn't really radical. I've seen OS's that have
"Events" that an app registers for. I've seen big military systems that have
very complex "postal systems" - sometimes they get unwieldy because the
message traffic is ill defined and the communications are so asynchronous &
uncertain - but for a simple client/server kind of thing its not likely to
be that big a deal.


> 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).
>
See above. An interrupt can be an "event" that results in a message to the
app. You can tie a procedure to an interrupt. You can tie a task entry to an
interrupt. You can have a universal interrupt handler that creates "events"
for the app. All of them work, but "events" are much more like reading a
simple file.


> 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).
>
I wouldn't try to hook tasks to the events generated by a widget. That's
just a callback wearing a different suit. I'd create a protocol of messages.
The app starts up and sends to the GUI whatever initialization is required
to get the windows defined & displayed. (A big XML file like what GtkAda
uses to define windows?) The windows and widgets and what have you all have
some kind of identifier associated with them - a unique ID. One or more
tasks want to make something happen, they build a message targeted to the
unique ID of interest and send it to the GUI. The user cliks buttons or
types text or whatever, the widget concerned packages up a message and sends
it (with its ID) to the app. The app just has to figure out what to do with
the messages it gets.

Like I said, the messages to/from the app/GUI might want to be handled by a
"post office" so that individual tasks can decide what events they want to
see, but that's just another layer of abstraction on top of the message
system, so it depends on how complex you want to go.


> 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.
>
Don't do that and it will stop hurting. :-) Use messages and decide on what
to do if you start getting duplicate messages or floods of them. Start
dropping them on the floor? The user clicks the button 37 times you react to
it 37 times even if it takes you a while? Handle each widget with its own
task and buy a really massive multiprocessing computer to handle the
thousands of tasks it will have? I think as long as you have a message
protocol, you're free to figure out numerous ways of handling the traffic.


> 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.
>
The task starts, it registers for the events it is interested in (opening
files, if you will) and then hangs on some kind of "Receive the next
message" procedure. It quits when it gets the "Shut yourself down" message.
Everything else is some form of case statement or dispatch based on the
message received.


> I am intrigued by this idea.. just trying to picture a practical
> implementation of it.
>
Give it some thought. I think that one might be able to evolve some kind of
low-level wrapper/post-office/client-server thingie that could decouple the
app from the GUI in a way that might allow multiple GUIs and GUI builders to
be working at the other end. It might be worth making some kind of attempt
at a limited prototype to see how it might work in practice.....hmmmmmm

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================