Add API for GtkShortcutsWindow, GtkShortcutsSection, GtkShortcutsGroup, GtkShortcutsShortcut
Submitted by Daniel Boles
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. ;-)