Re: Event handling

[Pierre Phaneuf <pp@ludusdesign.com>]

Christian Reiniger wrote:

> >I overgeneralized a bit what Carmack said. He was speaking strictly
> >about *input* events. Given that you do include the correct things as
> >"input events" (like he said, time is very useful when considered as
> >input, just like network, mouse or keyboard), you do not need to journal
> >other events.
> 
> Right. I missed that. But it fits neatly in my model ;)

Yes, since it is just about *not* journaling useless stuff... :-)

> >A queue class, with a "subscribe" method that let "event sink" objects
> >register with them and receive their events. That's enough abstract
> >objects to do most everything.
> 
> For that abstract class stuff you should really have a look at the Gtk--
> Signal mechanism. It's the nicest design of such a thing I've seen up to
> now. It's very versatile (just about everything can be a sink) and
> actually quite slim (e.g. no need for abstract classes).

I didn't look *much* at the Gtk-- mechanism. I do abstract classes
rather shamelessly, since my XPCOM-like system uses a lot of multiple
inheritance for "interfaces" (pure virtual classes, does the same as
Java's "interface"s).

Do you have a link to something that describe the Gtk-- signals?

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
.