GNOME Bugzilla – Bug 129846
libglade: GtkMenuItem accelerators lost during reparenting
Last modified: 2011-07-20 18:19:28 UTC
If you create a menubar by hand or with libglade, everything works OK. The problem arises when you reparent with Gnome::Glade::Xml::reparent_widget(). This "loses" the accelerators. I've tried various things: adding an accel group to the main window, and then calling Gtk::MenuShell::accelerate(Gtk::Window&), but this doesn't have an effect. I'm sure this is caused by reparenting. I'm not sure if it's possible to attach files to a bug report. The testcase is archived on the gtkmm-list, Subject is "Re: [gtkmm] Menus and libglademm", Message-ID is "<87brq8nz1x.fsf@wrynose.whinlatter.uklinux.net>".
Created attachment 22644 [details] testcase -- code
Created attachment 22645 [details] testcase -- glade interface
I tried this with the menus example, in libglademm/examples, and I don't see any accelerators, and that doesn't even use the reparent method. I can't even get it to work in C with libglade. Do you have an example that does work, without reparenting, for comparison?
Created attachment 22839 [details] accelerator-example.glade
I've attached a new Glade file, which adds a C+Q accelerator to the menu_file_quit MenuItem. This does work as expected, in that now C+Q now causes the program to terminate. This works with the normal gnomemm/libglademm/examples/menus/example program. Regards, Roger
So, the problem seems to be only with _stock_ accelerators. I still have not found any example of this in C, however.
> So, the problem seems to be only with _stock_ accelerators. > I still have not found any example of this in C, however. I'm not sure what you mean by a "stock accelerator". The stock MenuItem's don't have any accelerators?? I'll write an example in C, but I don't expect this to be a problem: it works fine with a normal libglademm-loaded interface in C++. The problem only arises after the widgets have been reparented. I have a copy of the gnomemm CVS now, so I'll have a look at it.
> The stock MenuItem's don't have any accelerators?? Yes, they should. For instance, File/Save _should_ have a Ctrl-Save accelerator without you specifying it explicitly.
> I'll write an example in C Roger?
OK, I now have two examples in C, one using libglade and one plain libgtk. It looks like it's actually a Glade or libglade issue: the libglade example doesn't work either, but the gtk one does. If the GtkAccelGroup for the created menu is added to the (now non-existent) main window of the Glade interface, it won't get owned by the window it's been reparented into without some magic. The same applies to loading an interface from some point other than the root (as in these new examples). There are also some warnings printed at program termination in the libglademm-noreparent example. So I think it's basically down to the handling of the GtkAccelGroup holding the menu accelerators. I'm afraid I'm not enough of a GTK+ internals expert to debug that much further. Regards, Roger
Created attachment 32672 [details] New testcases with libglademm libglade and libgtk New testcases.
What type of file is that? It doesn't seem to be a .tar.gz. Please put the filename in the description in future.
The file is a .tar.bz2. BTW, file(1) can tell you this: $ file testfile testfile: bzip2 compressed data, block size = 900k Regards, Roger
I think this is a general issue with libglade AccelGroup handling rather than a libglademm bug, and can probably be reassigned to libglade if you agree with the testcase. Regards, Roger
The basic problem lies with libglade, not libglademm, so I'm transferring it to the "libglade" component. Regards, Roger
Is there any progress being made on this bug? Is there anything I can do to help? Regards, Roger
The GNOME Release team has officially deprecated libglade in favor of GtkBuilder[1]. So it's unlikely to get further development. I am closing bugs as WONTFIX. Please feel free to reopen the bugs in future if anyone takes the responsibility for active development. [1] http://permalink.gmane.org/gmane.comp.gnome.devel.announce/28
Did you check if the bug was still present in GtkBuilder? Last time I checked, it still had numerous issues.