GNOME Bugzilla – Bug 742068
Support some multimedia XF86 keys: ZoomIn ZoomOut…
Last modified: 2018-05-24 14:58:16 UTC
Created attachment 293406 [details] [review] Support for ZoomIn and ZoomOut keys. There are several XF86 keys which would be worth supporting in GIMP. I'm thinking in particular about XF86XK_ZoomIn and XF86XK_ZoomOut. If the canvas receives such keysyms, we should zoom in/out (respectively). Attached a patch adding the support.
Created attachment 293451 [details] [review] Support Forward/Backward keys While I was at it, I thought we could as well support other meaningful keys. Attached a patch for support of the forward/backward keys. In a browser for instance, these keys would switch to the next/previous tabs. Let's do the same here.
Created attachment 293452 [details] [review] Support scroll keysyms. And same for scroll up/down keys.
Can't these keys (at least zoom and fw/bw) be expressed as accelerators (for zoom) or widget key bindings (for the image notebook)? For scroll, shouldn't that be handled in the input controller just like the mouse scroll "buttons"?
Accelerator, do you mean a GtkAction accelerator? Because these keys have a meaning by themselves. If you give a key the meaning "zoom in", you want it to "zoom in" in any software (whatever meaning it has depending on the kind of software). They are not alphabet or generic F1-F12 keys. Accelerators, hence actions, on the other hand can be overridden and are customizable. They are rather made for non-semantic keysyms for you to give them meaning. Or maybe I misunderstood what you were asking.
We still want the users to be able to change what those buttons do - after all, it is some generic button somewhere, regardless of what label someone has slapped on them.
The physical button may be generic but the keysym is certainly not. If a software receives XF86XK_ZoomIn, it should zoom in (if there is a concept of "zoom" in the software, otherwise nothing obviously). If a software receives 'a', it means 'a', not 'b'. If you wanted this physical button to send 'b', you change the keyboard mapping, you don't setup the software to print 'b' when it receives 'a'. That's the same here. If GIMP receives XF86XK_ZoomIn, it means "zoom in". And if the user wants another meaning for the physical key, one should change the device mapping, not customize GIMP to do something else when it is asked to zoom.
We also allow the cursor keys, and whatever keys to be configurable. I don't see how this should be different for those keys, just because they by default send a keycode that says "Zoom". The same is true for the scroll keys. Why clutter the code with special code for special keys if we have an input controller that can have a default configuration which does just that.
I see Jehan's point, but I agree with Schumaml and Mitch here: it is really a pit that upstream someone decided the keys would send a signal of what action the application should take. That is the big issue which takes control away of the user - and we can make nothing on GIMP side to have different signals to get to the application. However, taking only my Lenovo notebook for example: the "F" keys are tied to the multimedia keys by default. That is: fortunately I could change that in a BIOS setting - otherwise pressing the key labeled "f4" would always close the current application - (as if "alt + f4" is pressed) because the default binding of the key is to a "close application" signal. All the other f-keys have default actions as well, and I'd have to hold the "Fn" modifier to have an actual F-keypress. This is definitely an unfortunate choice, and there maybe even more unfortunate computers around where bringing the default F-key behavior is not an option. (Or one might not have the expertise do fix this behavior). GIMP being allowed to re-purpose what these keys do might just free up several keys for shortcuts that would otherwise be unusable. So, while from a semantically purist point of view, Jehan's arguments are valid, this is a rather important (and within reach) case where free software can help people to be in control of their computers.
Lenovo has gotten loads of complaints about the behavior you're describing, btw - they admit this in their blog. They added this as a BIOS setting for (at least some of) their systems.
All keys can be configured by the user and that's good. There is no denying this point. But nowadays keyboards come up with all sort of keys with purposes. Sometimes they may be unfortunate choices (replacing generic keys, and making the change back non straightforward — through the BIOS! — like Joao's Lenovo example), and sometimes not. For instance on my own Lenovo laptop, I have some additional Back and Forward keys (not the multimedia back/forward, more like tab related, and they don't replace F keys or anything). I would expect these to do something about going back or forward (in Firefox for instance, they go back and forward in browsing history, but I could accept going from a tab to another for instance as I proposed, though going back and forth in the editing history could be nice too now that I think of it). Of course, I don't expect an image manipulation software to do much with some of the keys, but others, I would expect acceptable default. It does not prevent the user from reconfiguring keys, and that's awesome, as Joao points out. But I really think that GIMP could have better out of the box defaults. Note that my proposition of implementation may be wrong. I actually was unsure myself of it. I am not defending this specific implementation but the idea of having good defaults for semantic keys which make sense within GIMP. The other reason why I think semantic keys are not too bad is about configuring device buttons with a purpose. This is actually how I started to think about this topic and why I proposed these patches. Right now, if I want to set up a button to zoom (on my graphics tablet for instance), I would likely set it to '+' and another to '-'. On my browser (Firefox) on the other hand, I zoom with ctrl+/- (so I'd have to hold on ctrl), on some other software, it could even be completely different keys, and it would just output unwanted '+' and '-'. So basically I can't easily make a one-click button for a purpose which spread accross any application. Of course you can configure various software to use the same shortcut, and in this specific case, you can also use a scroll action (which associated with ctrl is also a common secondary zooming key). But that's my point. You have to configure everything, and it's rarely perfect. Semantic keys are good on that aspect: they are simple and straightforward. Once again, I repeat though: I don't want to remove any configuration aspects of GIMP. It's good that you can configure everything. And if someone wants to be able to explicitly have GIMP do something else on receiving a "Zoom in" key, why not! But sane defaults could still be there to process semantic keys.
Note that having more accelerators for an action would be totally acceptable to me. But right now, doing this implies creating new actions for the same thing (the famous "-accel" actions) and I think that kind of sucks. Isn't there a way to have several accelerators/shortcuts for the same action? If I understand correctly, this is a limitation of GTK+?..
Apparently this is possible with gtk_application_set_accels_for_action () but only available since GTK+ 3.12. All other solutions found to have several accelerations for a given action are more like custom application-specific systems built over the GTK+ accelerators (unless I missed something).
There are actions for zoom and scroll, you just need to add support for the zoom and scroll keys to gimpcontrollerkeyboard.c, and add the default bindings to the config file (controllerrc).
Comment on attachment 293406 [details] [review] Support for ZoomIn and ZoomOut keys. Per comments.
Comment on attachment 293451 [details] [review] Support Forward/Backward keys Per comments.
Comment on attachment 293452 [details] [review] Support scroll keysyms. Per comments.
-- 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/gimp/issues/637.