Re: [gtk-list] :gtk design question (events vs signals)
- From: Havoc Pennington <rhp zirx pair com>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] :gtk design question (events vs signals)
- Date: Mon, 26 Apr 1999 00:04:25 -0400 (EDT)
On Mon, 26 Apr 1999, Jason Stokes wrote:
> I was hoping someone could settle a nagging question I have about the design
> of GTK+, specifically, the distinction between signals and events, which I
> find unclean. Now, apparently, GTK+ inherits its event model from GDK which
> in turn inherits it from low level X toolkits like Xt Intrinsics via Xlib, but
> my question is: is there any technical reason for retaining this separation,
> including separate handling models and structs, apart from historical reasons
> and implementation convenience? If GTK could have had the the benefit of a
> "clean" redesign from the ground up, would everything be a signal, or am I
> missing some reason why the two models are separate? For example, should I
> think of events as "lower level" signals?
I think you're thoroughly confused on this point. :-)
Events are a stream of messages received from the X server. They drive the
Gtk main loop; which more or less amounts to "wait for events, process
them" (not exactly, it is really more general than that and can wait on
many different input streams at once). Events are a Gdk/Xlib concept; Xt
does not come into play at all.
Signals are a feature of GtkObject and its subclasses. They have nothing
to do with any input stream; really a signal is just a way to keep a list
of callbacks around and invoke them ("emit" the signal). There are lots of
details and extra features of course. Signals are emitted by object
instances, and are entirely unrelated to the Gtk main loop.
Conventionally, signals are emitted "when something changes" about the
object emitting the signal.
Signals and events only come together because GtkWidget happens to emit
signals when it gets events. This is purely a convenience, so you can
connect callbacks to be invoked when a particular widget receives a
particular event. There is nothing about this that makes signals and
events inherently related concepts, any more than emitting a signal when
you click a button makes button clicking and signals related concepts.
In light of this, I don't see how your question really makes sense; I
don't see how events could be considered a "lower level signal" or how you
could merge events with signals.
] [Thread Prev