Re: Custom model in gtkada?

["Randy Brukardt" <randy@rrsoftware.com>]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> wrote in message
news:6bfpg.12754$FQ1.8736@attbi_s71...
...
> I'm talking about the use of the system, not the details of how it's
> implemented. In the event-queue model, the client code obtains events
> from an event queue and responds to them; in the callback model the
> client associates events with subprograms it provides to the windowing
> system, yields control to the windowing system, and the windowing system
> calls the provided subprograms when it decides such calls are appropriate.
>
> Say, even the description of the event-queue model is simpler than the
> description of the callback model.

That's surely true, but the problem with event-queues (at least in
real-world implementations like Windows and Mac) is that all of the possible
events come to one place. Windows has more than 800 events in its core, and
many more in the subsidiary packages. The whole reason for using tagged type
dispatching is to manage the complexity that comes from that: only sending
relevant events to the objects that care about them.

You could write such an infastructure yourself, but you will end up with
giant case statements handling and distributing events -- and the net effect
is pretty much the same as with a GUI framework, except now you have more
code to maintain.

I could imagine a hybrid framework that gave each window object its own
event queue, but then you'd need a thread of control for each object in
order that it be responsive (for instance, to a click that's intended to
bring a lower window to the top). [Or a very complex control structure.]

The truth is that GUIs are very complex beasts, and nothing is going to make
programming them simple (unless you needs are very basic [This is where JEWL
aims]). The tagged type/action handler works as well as any (it's even
better in Ada 2005 with the nesting limitations removed).

                               Randy Brukardt.