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 742068 - Support some multimedia XF86 keys: ZoomIn ZoomOut…
Support some multimedia XF86 keys: ZoomIn ZoomOut…
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: General
git master
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2014-12-28 17:18 UTC by Jehan
Modified: 2018-05-24 14:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Support for ZoomIn and ZoomOut keys. (1.20 KB, patch)
2014-12-28 17:18 UTC, Jehan
needs-work Details | Review
Support Forward/Backward keys (3.77 KB, patch)
2014-12-29 19:04 UTC, Jehan
needs-work Details | Review
Support scroll keysyms. (1.63 KB, patch)
2014-12-29 19:05 UTC, Jehan
needs-work Details | Review

Description Jehan 2014-12-28 17:18:14 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.
Comment 1 Jehan 2014-12-29 19:04:40 UTC
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.
Comment 2 Jehan 2014-12-29 19:05:11 UTC
Created attachment 293452 [details] [review]
Support scroll keysyms.

And same for scroll up/down keys.
Comment 3 Michael Natterer 2015-01-03 18:49:00 UTC
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"?
Comment 4 Jehan 2015-01-03 19:52:44 UTC
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.
Comment 5 Michael Schumacher 2015-01-03 19:58:07 UTC
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.
Comment 6 Jehan 2015-01-03 20:19:36 UTC
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.
Comment 7 Michael Natterer 2015-02-05 18:56:59 UTC
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.
Comment 8 Joao S. O. Bueno 2015-02-05 19:15:32 UTC
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.
Comment 9 Michael Schumacher 2015-02-06 13:28:33 UTC
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.
Comment 10 Jehan 2015-02-06 14:29:33 UTC
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.
Comment 11 Jehan 2015-02-06 14:41:49 UTC
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+?..
Comment 12 Jehan 2015-02-06 16:10:37 UTC
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).
Comment 13 Michael Natterer 2015-02-06 16:46:20 UTC
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 14 Michael Schumacher 2017-02-02 15:57:39 UTC
Comment on attachment 293406 [details] [review]
Support for ZoomIn and ZoomOut keys.

Per comments.
Comment 15 Michael Schumacher 2017-02-02 15:57:52 UTC
Comment on attachment 293451 [details] [review]
Support Forward/Backward keys

Per comments.
Comment 16 Michael Schumacher 2017-02-02 15:58:14 UTC
Comment on attachment 293452 [details] [review]
Support scroll keysyms.

Per comments.
Comment 17 GNOME Infrastructure Team 2018-05-24 14:58:16 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/gimp/issues/637.