[Glade-users] Unique widget names

[Jeffrey Barish]

Fernando J. Leal wrote:

> Greetings!
> 
> I have a rather odd problem, and hope to find some help in these lists:
> I'm maintaining a Python application that uses PyGTK and a GTK UI
> created with Glade. Until a few months ago (the last time I changed it),
> Glade was happy with my practise of using identical names for widgets
> inside different containers - as an example, 2 GtkWindow widgets
> ("window_1" and "window_2") could each have a button called "bt_close".
> Since for each window a different class would be instantiated and load
> the corresponding widgets using Win=gtk.glade.XML(<glade_file>,
> 'window_<x>') and bt=Win.glade.get_widget('bt_close'), there was no
> possible confusion. I can confirm this to work on Glade up to (and
> including) v3.3.3.
> 
> Now, after some time without changing the application, I opened it using
> Glade 3.4.5 and I found out that when saving the XML file, Glade renamed
> all the widgets to "bt_close1", "bt_close2", "bt_close3" and so on,
> regardless of the fact that they were in different containers. This has
> caused me a lot of trouble, since either I have to use a previous Glade
> version (until 3.3.3, at least) or I have to change all my code, class
> by class, to match the new widget names. The new Glade (3.4.5) doesn't
> allow me to rename a widget and use the same name I already used for
> another one, even if they lie inside completely different containers.
> 
> I'd like to ask if this behaviour is "by design", or is there a way to
> configure it?
> 
> Thank you.

I don't have an answer to your question, but I thought that it might help
for you to know that I also use 3.4.5 and I also practice the technique
that you described of using the name in multiple glade files, but I have
not observed the problem that you described.  Oh, wait.  I think the
difference is that I put one thing -- what you are calling a container, I
think -- inside each Glade file.  Perhaps you could solve your problem by
splitting your glade files.
-- 
Jeffrey Barish