After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 770377 - Add API for GtkShortcutsWindow, GtkShortcutsSection, GtkShortcutsGroup, GtkShortcutsShortcut
Add API for GtkShortcutsWindow, GtkShortcutsSection, GtkShortcutsGroup, GtkSh...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
3.22.x
Other All
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-08-25 10:50 UTC by Daniel Boles
Modified: 2018-05-02 17:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
working example of how to create GtkShortcutsWindow et al in code (1.42 KB, text/plain)
2016-08-25 12:16 UTC, Daniel Boles
Details
[now GNU C-ified] working example of how to create GtkShortcutsWindow et al in code (1.80 KB, text/plain)
2016-08-25 12:45 UTC, Daniel Boles
Details
[now GNU C-ified] working example of how to create GtkShortcutsWindow et al in code (1.87 KB, text/plain)
2016-08-25 12:48 UTC, Daniel Boles
Details
[now GNU C-ified] working example of how to create GtkShortcutsWindow et al in code (3.64 KB, text/plain)
2016-08-25 15:32 UTC, Daniel Boles
Details

Description Daniel Boles 2016-08-25 10:50:42 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!
Comment 1 Daniel Boles 2016-08-25 12:16:10 UTC
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.
Comment 2 Daniel Boles 2016-08-25 12:45:23 UTC
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
Comment 3 Daniel Boles 2016-08-25 12:48:19 UTC
Created attachment 334139 [details]
[now GNU C-ified] working example of how to create GtkShortcutsWindow et al in code

let's try that again...
Comment 4 Daniel Boles 2016-08-25 15:32:42 UTC
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.
Comment 5 Alan Jenkins 2016-10-14 10:47:08 UTC
> 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.
Comment 6 Daniel Boles 2016-10-14 10:52:31 UTC
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.
Comment 7 Matthias Clasen 2018-02-10 05:20:08 UTC
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.
Comment 8 GNOME Infrastructure Team 2018-05-02 17:26:34 UTC
-- 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.