Re: [OT] Best way to isolate a GUI?

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

Well, for the sender, there needs to be only one queue. For the receiver,
you're ultimately going to end up with case statements - either one big
giant one explicitly created or a bunch of smaller ones inside various
handling tasks or ones that are built for you via dispatching. I have not
given the idea hundreds of hours of thought yet, but I'm sure a workable
solution does exist. I've just never liked callbacks and thought that
receiving messages in some manner is a much better answer.

I've worked on systems (mostly LockMart stuff, but I know other companies
did it) where there is an underlying messaging system where applications
"register" for the messages they want to receive & create "mailboxes" to
receive them. You basically end up with one process per computer that acts
as the "mailman". It makes for a reasonably simple & elegant design of an
app where a given task need only hear about the things it wants to do
something about. It solves a lot of other problems along the way like socket
overhead and needing to know about what else is out there attempting to
communicate. It has its problems too, but in general its a good way to build
loosely coupled distributed applications. I could imagine something similar
working in a client/server mode to build an independent GUI without
callbacks or excessively big case statements. You create a task for each
window and it registers for events relating to that window. Its still got to
have a case statement - or some kind of dispatching - but its localized.

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

Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> wrote in message
news:3E527506.6070209@cogeco.ca...
>
> But this still suffers from one problem: Each queue in your task
> would then have a monster case statement to split out the work
> according to the widget that is receiving the event. Compare this
> to the registered callback where only the interested widget for
> the event gets the callback. No big case statement required for
> event, or widget.
>
> Don't get me wrong.. I like the idea of queues and tasks. But this seems
> a clumsy thing beside a callback.
>