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

"Waldek Maleska" wrote:

Is there an (official) way in GTK+ 2.2 to get a pointer to a
GtkWidget by the name of the widget, like Glade imposes it by its
lookup_widget()-function and GLADE_HOOK_OBJECT ()-lists?

I don't really see any reason to look up children by name if you
aren't using Glade or libglade. Just keep pointers to the children
you need to reference. [...]

Actually you COULD lookup children by name ONLY if you were using Glade.
Without Glade apparently there wasn't a way to do that. That's what my
question was about. You know, you can create and modify widgets at
runtime without libglade, just by GTK+ itself, don't you? And keeping
pointers for dynamically (at runtime) created widgets is both
non-trivial and ugly. You'd probably store them as global variables and
that's not what I want.

I suppose what Gus wants is just having all widgets kept some
kind-of-together. Perhaps he should create a global
GHashTable and keep pointers to all created widgets
in there by yourself (BTW, isnt't it what Glade does?),
maybe providing some functions for accesing the table
and adding/removing widgets.

My point is that I don't like to use another list to keep track of
something which is already kept track by Glade's hookup object list and
GTK+ itself of course. So not another own hashtable, please!

As far as I understand even Glade's GLADE_HOOKUP_OBJECT ()-lists are
unnecessary overhead. lookup_widget () could do without them, just as my
own function (see below) does pretty well. It's independent from Glade,
doesn't use any non-local resources and always examines all contents of
a window, even the "forgotten" ones.

If you dynamically modify contents of a windows from somewhere else you
can't rely on Glade's hookup lists any more anyway. Like for custom
hastables it's easy for it to get out of sync with actual windows
contents if you change something.

Besides, why are there Name-properties for widgets at all if not for
referencing purposes (as for gtkrc-files)? But then I was just wondering
whether / why there isn't a (public) function inside GTK+ to actually
reference them at runtime for your own purposes as well?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]