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

["Marin David Condic" <mcondic.auntie.spam@acm.org>]

So here's a thing: Ada might potentially be able to evolve some sort of
standard interface to the GUI world by saying "wrap up the GUI in something
that will send and receive this set of messages". I'm curious what sort of
mechanism might provide for a single thread or multiple threads (as you
suggest, a task per window). Either you have the wrapper send things to a
single queue, or you've got to have tasks defining queues and registering
for events. I'm not sure that registering for events is such a bad thing -
I've seen a number of OS-like things that have used this exact scheme and it
works reasonably well. Certainly, if you go to a single queue, one could
evolve yet another layer of abstraction on top of that which would allow for
registration & multiple queues.

Here's a problem though: You could use events/messages/etc or you could use
procedure calls, callbacks, etc., but in either case you've got to have a
lot of things carefully defined and you've got to limit yourself to the
things that could be readily supported by most of the popular GUIs & GUI
builders.Would you see this as a problem? I still like the message/event
format because once you're hiding behind that skin the GUI could be in the
next county and your app doesn't need to know, but I could see it involving
quite a big message catalog & it doesn't get you around
least-common-denominator problems.

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

Jeffrey Carter <jrcarter@acm.org> wrote in message
news:3E5661F0.2060200@acm.org...
>
> This is about what I was trying to say. I mentioned the idea of having a
> task per window to emphasize the inherent concurrency of multiple
> windows, and some posters seem to have fixated on tasks rather than on
> the message (event) queue that was really what I was talking about.
>
> You can see an example of this, built on top of Windows, in JEWL.
> Because it's intended for beginners, it's rather too simple for a
> complete windowing system, but it does show how a GUI can be designed
> using events ("commands" in JEWL parlance) rather than callbacks. It
> doesn't prevent you from having dynamic windows or dialogs, nor does it
> force you to use tasks. It does let you structure your system the way
> you want, and control what it does, rather than structuring it for the
> convenience of the windowing system, and giving control to that system.
> This alone makes the software much easier to read and understand.
>