GNOME Bugzilla – Bug 770377
Add API for GtkShortcutsWindow, GtkShortcutsSection, GtkShortcutsGroup, GtkShortcutsShortcut
Last modified: 2018-05-02 17:26:34 UTC
Company deemed this "really really wrong" when he heard about it on IRC, and he and mclasen expressed being open to adding API, so a ticket seems worth a shot. So. The GtkShortcuts* widgets - while extremely cool and useful - don't have any 'normal' GTK+ API: no *_new() methods (unless using a binding that wraps these) and only 'raw' properties [ no get_/set_*() ]. This causes various problems: * Users like me reading the documentation have no idea how to use these widgets programmatically. Sure, the "recommended" way is to create them through a .ui file, but that's not marked as mandatory. * Sometimes using a .ui is simply not possible, as we have dynamic shortcuts. See Pitivi for an illustrative example of this, where they allow customisation of shortcuts on the fly and correspondingly update their Shortcuts* widgets. I'd consider something similar. Even now, I'm constructing various Buttons in-code from sets of traits, and I'd prefer to handle specifying/creating the corresponding shortcuts there, rather than duplicating the work in a .ui file. Most of my UI absolutely must be programmatic, so I'd prefer the rest to be too. * The confused user wanting this must be sufficiently persistent to dig in and figure out they can use raw GObject init methods and properties. How many devs might give up here, assuming they can't create such widgets programmatically, or it's too difficult, or there's another way - or toolkit - that does it nicer? * Even if the user's determination/procrastination pays off, and they learn enough GObject to make these widgets usable, the code just looks wrong. Not having usual GTK+ API makes it look out of place... * ...and makes the user (or maybe just me) wonder whether they are really 'meant' to use them at all - or might everything be changed later and people told just to update their .ui files... which would be fine, if I had any! TL;DR: Creating GtkShortcuts* only from a .ui file is not always appropriate, doing so programmatically is a valid use case, and it should use typical API and be documented so as not to scare away prospective users or lead to hybrid GTK+/GObject code. I would offer to help, but as mentioned, I don't know enough GObject yet to do much useful - although by the time I've finished writing this bit of code, that might have changed, by necessity. ;-) Thanks!
Created attachment 334131 [details] working example of how to create GtkShortcutsWindow et al in code Here's the final magic recipe to create GtkShortcutsWindow et al programmatically, including a major gotcha with show()ing the GtkShortcutsSection, as reported here: https://bugzilla.gnome.org/show_bug.cgi?id=770385 In lieu of GTK+ API, perhaps this could be adapted for the current documentation as a stopgap, so other users wouldn't have to spend a day figuring it out like I did. HTH and thanks.
Created attachment 334138 [details] [now GNU C-ified] working example of how to create GtkShortcutsWindow et al in code example re-written in (my understanding of) idiomatic GNU C style
Created attachment 334139 [details] [now GNU C-ified] working example of how to create GtkShortcutsWindow et al in code let's try that again...
Created attachment 334155 [details] [now GNU C-ified] working example of how to create GtkShortcutsWindow et al in code add 2nd Section, 2nd Shortcut in it, more meaningful descriptions, nuke the camelCase variable names, etc.
> we have dynamic shortcuts. See Pitivi for an illustrative example of this, where they allow customisation of shortcuts on the fly and correspondingly update their Shortcuts* widgets Anyone considering this - there's a feature in 3.22, that you might find more convenient: https://developer.gnome.org/gtk3/stable/GtkShortcutsShortcut.html#GtkShortcutsShortcut--action-name “action-name” gchar * A detailed action name. If this is set for a shortcut of type GTK_SHORTCUT_ACCELERATOR, then GTK+ will use the accelerators that are associated with the action via gtk_application_set_accels_for_action(), and setting “accelerator” is not necessary.
Pitivi might already take advantage of that. Either way, it doesn't change the fact that they must dynamically (re)generate GtkShortcuts* widgets on the fly and pack them using code, not a .ui file and GtkBuilder. Which currently they must do using raw GObject properties, not normal GTK+ API.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
-- 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/issues/661.