GNOME Bugzilla – Bug 744596
[PATCH] Resync menu after activating GtkRadioMenuItem
Last modified: 2021-05-25 10:05:05 UTC
Created attachment 296943 [details] [review] Proposed patch At the moment selecting a GtkRadioMenuItem doesn't update the selection in the menu. Of course, OS X doesn't "know" radio items so it cannot update the selection by itself. However, it is possible to detect the radio menu item activation once it reaches the underlying GtkMenu and when it gets activated here, resync the OS X menu so it corresponds to the GtkMenu. See the patch in the attachment. I think it's better to perform this directly in the library rather than leaving the resync on applications. I ran into this problem when creating OS X port of the Geany editor and in more complex applications it's quite tricky to find all the code paths that need to be updated and osx specific code gets unnecessarily all around the code, see here: https://github.com/techee/geany/commit/a122953c7b202b6feb59d6ec4f102edf46a16391
We can do much better. As suggested by Colomban Wendling (Geany maintainer), we can use the "toggled" signal for this - it's emitted both for the item which receives the checkmark and the item which loses it so we can update both without the need to resync the whole menu. Patch attached.
Created attachment 297061 [details] [review] Doing it the right way
(In reply to Jiri Techet from comment #0) > Created attachment 296943 [details] [review] [review] > Proposed patch > > At the moment selecting a GtkRadioMenuItem doesn't update the selection in > the menu. Of course, OS X doesn't "know" radio items so it cannot update the > selection by itself. However, it is possible to detect the radio menu item > activation once it reaches the underlying GtkMenu and when it gets activated > here, resync the OS X menu so it corresponds to the GtkMenu. See the patch > in the attachment. GtkRadioMenuItem works fine and doesn't require that you litter your code or gtkosxapplication's with resyncs. This is demonstrated in src/test-integration. Start it and click the View Menu button; that adds a View menu containing two radio buttons, Horizontal and Vertical. Click the unchecked one and you'll get a message on the terminal and when you re-open the menu you'll see that the check has switched to the one you clicked.
Of course what you described works, but that's not the issue I'm having. The problem is when the radio button state has to be set from the code using e.g. gtk_check_menu_item_set_active() - in this case the menu isn't updated.
Spoke too fast, it actually doesn't work when clicked in Geany either - I will try to investigate what the difference between your code and Geany might be (Geany uses Glade for UI definition, not sure if the problem might be there).
First, ignore my first post from today, it was a nonsense. I'm attaching a test demonstrating this problem using the whole Geany Document menu (see the comment in the patch for more info). It seems Glade swallows the "active" signal and the checkmarks don't get updated. Notice that after applying either of the patches I attached previously it starts working again. Not sure if swallowing the "active" signal is Glade bug/feature or if something can be done about that (tried various options in Glade without success). I'm afraid that even if this is a bug in libglade, there should be some workaround for it in gtk-mac-integration because even if it gets fixed now, it will take years before the updated version gets to all users. Creation of user interfaces is pretty common for GTK applications and gtk-mac-integration should work with it.
Created attachment 297681 [details] [review] Ugly test demonstrating the problem
Of course it doesn't work, there's no GtkRadioActionEntry for any of the GtkRadioGroups. Since you're not linking libglade, you can't blame that. How is Geany reading the values of the Radio buttons?
Each of the items has something like <signal name="activate" handler="on_cr_activate" swapped="no"/> which calls the corresponding callback in Geany. In the other direction the menu item can be looked up by id so Geany gets GtkWidget on which it can perform whatever action it wants. I think this is a perfectly legal way of doing things (and if I'm not mistaken, there's no way in Glade to add GtkRadioActionEntry, is there?).
My understanding (I don't use Glade, I write the XML by hand when I need to; in general the GUI design work on the projects I contribute to is done by others) is that Glade is a Graphical tool for making GtkBuilder UI files, it doesn't generate the accompanying C code. GtkBuilder certainly provides for attaching action groups, see https://developer.gnome.org/gtk2/2.24/GtkActionGroup.html#GtkActionGroup-BUILDER-UI, so I don't see why Glade wouldn't support that. You mentioned libglade in comment #6. That was last released in 2009 and is thoroughly obsolete. See bug 172535 and https://wiki.gnome.org/Attic/ProjectRidley. If that's what you're using in Geany it's past time to redo your code to support GtkBuilder. You can replace a lot of your signal handling with GtkActions at the same time, which will make your code clearer and easier to maintain. That said, I finally understand your use-case and I'll consider adding support for it.
Yes, I forgot libglade isn't used any more (I meant the GtkBuilder). Apart from being stupid, I'm apparently completely blind too - I was on the GtkActionGroup page before and didn't see it... Thanks for considering some fix for the issue - when searching for possible solutions, I found https://inkscape.org/pt/gallery/item/4058/ where they also mention not updating radio items as one of the problems they have so the problem is probably more common.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk-mac-integration/-/issues/13.