Re: Locating child-widgets (by name) without Glade-code

[Gus Koppel <gtk spamkiller bytechase cx>]

Owen Taylor wrote:

> If you want to keep all your widgets in a big hash table, nobody 
> is stopping you.

That's exactly what I want to avoid.

> Implementing this, including such niceties as removing widgets
> from the hash when they go away, is probably no more code than
> hunting the widget hierarchy for gtk_widget_set_name().

Please have a look at
http://www.spamkiller.bytechase.cx/democode/widget_find_by_name.c.  I
doubt a hashtable-based maintain-and-locate solution could be smaller
than my single 40-lines function. It actually achieves what I want,
without any extra resources or protocols to track / abide.

> It seems a strange way to organize a program, however. Why not
> let the compiler let you catch using the wrong name?

For two reasons:

a) I like to avoid global variables and extra resources like hashtables,
especially in cases like this when there's absolutely no need for them.

b) the compiler doesn't know about it. Again, it's about dynamic code.
That means, there isn't given a (complete) list of widgets to build at
compile-time, like Glade produces them. Imagine building arbitrary
widget trees according to the user's input at runtime. Let the user say
"I want a new button" then he gets a new button. (Just an example, I'm
not going to program a competitor to Glade.) Don't know about you, but
my C-compiler catches nothing during runtime of my applications.

Along with setting other attributes I basically just call widget_new ()
and container_add () for dynamic widgets, not something like another
hashtable_add_widget () or such. I don't have to / want to care about
any extra resources or protocols to track / abide. I would have to if I
used Glade's lookup_widget (), for instance. In my opinion lookup_widget
() is a good idea but an unecessarily overheaded implementation.

Again, my problem is solved in a satisfactory way. Now I'm just
wondering whether / why such a simple and handy utility function isn't
part of the GTK+? To me this looks a bit like providing a key_set- but
no key_get-function for hashtables.