-
Notifications
You must be signed in to change notification settings - Fork 900
Unify key binding implementations #6140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
In order to get the right implementation, I've been giving some thoughts to shortcuts customization. I need some opinions as to what key binding should be configurable (Note that not all keybindings are "shortcuts" like Ctrl+Z. Some are just "when the user presses Ctrl" or things like that). Now, I think we want everything defined in mainmenubar.xml to be configurable - or possibly even every action in Action.enum.h should be able to be triggered by a configurable shortcut. IMO, the shortcut customization dialog should be aware of almost all key bindings accross the app: it should be able to detect conflicts. The other thing to consider is: if a key binding is customizable, then it improves its discoverability (just because it has to be written down in the customization dialog). I don't think a lot of users know about the non-trivial key bindings of the geometry tools/spline handler/shape handlers/vertical tool. My feeling is that:
So, @xournalpp/core do you have any opinion, insights or comments about those questions? List of current keybindings: Key bindings in BaseShapeHandler
Key bindings in SplineHandler
Key bindings in VerticalToolHandler
Key bindings in EditSelection
Key bindings in TextEditor
Key bindings in GeometryToolInputHandler
Key bindings in SearchBar
Key bindings in XournalView
|
I haven't made up my mind yet, about which shortcuts/keypresses should be configurable yet. But about discoverability let me add that there is another way to help with that: the GtkShortcutsWindow (which is present both in Gtk3 and Gtk4). It's just used for presenting shortcuts/keypresses, not for modifying them. |
That's a good point, but I am not quite sure how usable it is with configurable shortcuts (even just for displaying them). It seems that GtkShortcutsShortcut/GtkShortcutsSection/GtkShortcutsWindow have no public constructor. The only way to build them is via a GtkBuilder and a UI file. It makes it complicated to generate a GtkShortcutsWindow dynamically. |
About what should be configurable or not: we will probably want to have some immutable shortcuts that the user cannot override, while allowing the user to add another shortcut for the same action. I have in mind navigation key bindings for instance. |
Apparently that changed in Gtk 4.14 though with new API It's unclear to me however how to construct a |
I see how this is supposed to be done now (in Python). This works in the Libadwaita redesign mockup: shortcut_window = win.get_help_overlay()
section = Gtk.ShortcutsSection()
section.props.title = "My new section"
shortcut_window.add_section(section)
group = Gtk.ShortcutsGroup()
group.props.title = "My new group"
section.add_group(group)
shortcut = Gtk.ShortcutsShortcut()
shortcut.props.accelerator = "<Ctrl><Shift>j"
shortcut.props.title = "My new shortcut"
group.add_shortcut(shortcut) |
The C/C++ version of that is probably along the lines
In any case, this isn't for now as we need GTK 4.14. |
40399cc
to
0b4d1af
Compare
This reverts commit b089023.
f5eb964
to
e8c92ad
Compare
\action create-installers debian ubuntu-22 |
Started 2 build(s) (see details) |
CI successful! |
The long term goal (for a follow up PR) is to implement configurable shortcuts.
This PR simply uses the KeyBinding architecture used in TextEditor for key bindings various locations in the code.
It does not mean all of those key bindings should be open to configuration, but it gives us a common base to work with.