Re: [gtk-list] Re: $64k questons

[Tim Janik <timj gtk org>]

On Sat, 1 May 1999, Havoc Pennington wrote:

> 
> On Fri, 30 Apr 1999, pavel wrote:
> > 
> > I think I've figured out the answer to the first one: 
> > 	event->button.state & GDK_SHIFT_MASK
> > Right?....
> >
> 
> Yep.
> 
> > > Just curious, how come Gtk relies on passing strings like "destroy"
> > > instead of macros like GTK_DESTROY?
> > > 
> 
> Strings are easier to type and less headache for GtkObject authors to
> maintain. Also they don't clutter the C namespace. Typing a string
> incorrectly will trigger a runtime error so macros don't get you any
> better error checking. Strings are internally converted to a numeric ID so
> there is no loss in efficiency.

for those who are interested, in order to lookup a signal, gtk first
looks up a GQuark (i.e. an unsigned int id) through the global GLib
GQuark hash table for the string (the same is done for GtkObject's
named data lists), and then performs multiple hash lookups on the class
and its parent types through quick uint+uint hashes. that's significantly
faster than multiple string+uint lookups to find the class that's actually
introducing a certain signal.

besides, by using strings we get the advantage that we can feature the
same signal name for different signals across different class branches,
e.g. a GtkEditable can introduce "changed" as well as a GtkAdjustment,
without interference because they are on different heirarchy branches.
source maintenance and user signals are further reasons, e.g. if we used
enums, say

typedef enum {
  GTK_DESTROY  = 1,
} GtkObjectSignals;

typedef enum {
  GTK_SHOW = 2,
} GtkWidgetSignals;

typedef enum {
  GTK_CLICKED = 3,
} GtkButtonSignals;

and then introduce a new GtkWidget::hide signal, we'd have to adapt
all enum values of derived widgets, in this case GTK_CLICKED.

upon introduction of user defined signals (one without a class member)
with gtk_object_class_user_signal_new(), you wouldn't even know what
value your enum needs to have so you don't pick a value that's already
used somewhere else.


this issue has been hashed out on gtk-list before, i wish we had
a good searchable list archive for gtk-list.

> 
> Havoc
> 

---
ciaoTJ