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

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

Unfortunately I have to be a bit brief in this reply (shortened
lunch today ;-)

Marin David Condic wrote:
> Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
> news:3E5669C8.30305@cogeco.ca...
> 
...
>>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.

Having given it some thought over the weekend, and after review that
fine book "Concurrency in Ada" (or something like that), I'll just
quickly summarize some of the issues that occurred to me:

1. Event queues don't work well, unless you've defined some way of
    "returning event data".  By this, consider a "verify" widget event,
    where you want to provide a callback to perform a user verification
    on some text input widget. The verify event must return a VALID
    or NOT_VALID response.

    Callbacks perform this easily, because by appropriate use of in/out
    arguments, you can plan for returned data.

    For event queue's, the data is "one way". This is not to say that it
    is unsolvable, just perhaps "inconvenient".

2. A bi-directional "pipe" introduces other problems like latency,
    and sequencing (like two pieces of code returning different values).

3. If more than one task once notice of an event, then you need to allow
    for "multicasting" the event (simple with callback lists).

    If you use a protected object, for "multicasting" as is done in
    the "Concurrency in Ada" book, then like the message queue, you still
    have the "return data" problem. The added problem here is that now
    you have a certain amount of new "indeterminism" added to the mix,
    because the multicasting may multicast in a different sequence,
    according to timing.

    Of course this is fixable, because it can be serialized, but it does
    add some complexity, and perhaps some inefficiency as well.

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

Of course, but apply a young kid to a mouse, and let him click
away, and it is amazing how many GUI systems/applications come
crashing to its knees!  Yes, I know.. keep kids away from the mouse!

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

Of course, these are all solvable problems. But some of these
problems are easier to solve in some frameworks, rather than
others (at least it must be considered).

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

OK, but this act of "registering for events" is either going to
return a handle to a queue or protected object acting as such.

But your model considers events as a one way message flow, which is
clean and simple. But it doesn't address the verify callback
scenario, which is but one example of where data needs to be
returned (consider that once a verify has failed, there is no
need to call other verify callbacks for example).

This is not unsolvable, but it seems rather inconvenient and
open to other problems.

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

I think it is a worthy goal, but present musings don't seem
all that practical when I consider some of the problems that
come up.  Maybe we just need a better model ;-)

My lunch time is over... I'll have to ponder this more later.

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