#69 Simpler shortcut for zooming to normal size.

[Ark]

Almost everything you need when viewing pictures with MComix can easily be accessed by simply hitting the right (as in "correct") key for it. However, if you want to reset the zoom factor to 100%, you have to hit at least two keys: Ctrl + 0. It would be cool if the 0 key (or some other key, how about O (as in: "original")?) alone would reset the zoom factor.

Maybe you can keep Ctrl + 0 to do this, too. But this does not seem to be that easy according to this: https://sourceforge.net/p/mcomix/feature-requests/40/#d0ac

Thank you in advance!

[Oddegamra]

CTRL+KeyPad0 also resets the zoom level (if numlock is enabled). How about making that KeyPad0 instead? I don't really mind the letter O either, though.

[Ark]

CTRL+KeyPad0 also resets the zoom level (if numlock is enabled).

Wow, this is new to me. Since both KeyPad+ and KeyPad- work regardless of the numlock state, it never occurred to me to enable numlock and try Ctrl+KeyPad0.

Well, in this case, it might be a good idea to use 0 (or KeyPad0) instead of O. (Those who are used to KeyPad0 would hate switching to the O key since it is way harder to reach.)

[Oddegamra]

Understandable, since hotkeys that are not accessible via some menu weren't documented until recently ([Keybindings]). I changed the default setting from CTRL+KP0 to KP0 now, but for existing installations (i.e. you), you will likely have to either manually edit ~/.config/mcomix/keybindings.conf or delete it to have it re-created with the new default values.

[Ark]

Thank you for your work. Well, unfortunately, there seems to be at least one bug:

1. Make sure that no MComix instance is running.
2. Delete keybindings-gtk.rc and keybindings.conf.
3. Start MComix.
4. Close MComix.
5. In the newly created keybindings-gtk.rc, "zoom_original" defaults to "<Primary>0". However, it should default to "0" instead.
6. The newly created keybindings.conf shows that "zoom original" defaults to both "<Primary>0" and "KP_0". However, it should default to "0" and "KP_0" instead (as proposed in this feature request).
7. Edit keybindings.conf so that "zoom original" is mapped to "0" and "KP_0".
8. Edit keybindings-gtk.rc so that "zoom_original" is mapped to "0".
9. Start MComix.
10. Now all these shortcuts reset zoom to 100% (numlock enabled): Ctrl+0, Ctrl+KP0, 0, KP0. However, only those should work: 0, KP0 (as proposed in this feature request).
11. keybindings.conf did not change. This is okay.
12. keybindings-gtk.rc did not change. This is okay.
13. Close MComix.
14. keybindings.conf did not change. This is okay.
15. In keybindings-gtk.rc, "zoom_original" is mapped to "<Primary>0" again. This is not okay.

[Oddegamra]

In the newly created keybindings-gtk.rc, "zoom_original" defaults to "<primary>0". However, it should default to "0" instead.</primary>

This is okay, so far. I only changed CTRL-KP0 to KP0 for now.

The newly created keybindings.conf shows that "zoom original" defaults to both "<primary>0" and "KP_0". However, it should default to "0" and "KP_0" instead (as proposed in this feature request).</primary>

I never noticed, but apparently, I duplicated the event handlers for CTRL-0. It should only appear in keybindings-gtk.rc, not in keybindings.conf (because it is already handled via GTK menu item).

Now all these shortcuts reset zoom to 100% (numlock enabled): Ctrl+0, Ctrl+KP0, 0, KP0. However, only those should work: 0, KP0 (as proposed in this feature request).

This is probably a bug related to modifier handling in keybindings.py. I thought I fixed this some time ago, though, but obviously not.

In keybindings-gtk.rc, "zoom_original" is mapped to "<primary>0" again. This is not okay.</primary>

Did I mention that I hate how hotkeys are handled in GTK+ yet?

[Oddegamra]

In keybindings-gtk.rc, "zoom_original" is mapped to "0" again. This is not okay.

Did I mention that I hate how hotkeys are handled in GTK+ yet?

My bad, this likely isn't a bug - make sure that in keybindings-gtk.rc, any line you change must be uncommented by removing the semicolon at the beginning of the line. In case you're editing UI shortcuts, it is simpler to hover the mouse over the menu item in question and then press the desired key. The binding should change afterwards.

[Oddegamra]

As for KP_0 being also triggered by CTRL+KP_0, this is a side effect of a hack that is meant to catch another case: For example, on my keyboard, to type $, I need to press SHIFT+4. Regardless, the key will be registered in keybindings.conf with simply "dollar". Thus, I do not really know whether the user needs to hold down SHIFT or not when I compare keys. As a result, keys that are registered without modifiers can sometimes be used even when modifier keys are held down as well.

Unfortunately, I don't know any other ways to do this.

[Ark]

I deleted the keybindings* files again, now (r836) these shortcuts work by default:

• Ctrl+0
• Ctrl+KP0
• KP0

So I miss that 0 key shortcut now.

There is an old revision where all four shortcuts work by default. Maybe we should choose this version? Besides, why there are two keybinding files anyway?

In case you're editing UI shortcuts, it is simpler to hover the mouse over the menu item in question and then press the desired key. The binding should change afterwards.

Thanks for pointing that out. I think that there should be an appropriate hint in the Help menu or something. Otherwise, no one would use this feature (or even call this a bug because of seemingly random key rebindings).

When I bind the 0 key to "Normal size" this way, Ctrl+0 gets disabled but 0 works from then on. But why does Ctrl+KP0 continue to work? It seems like this whole key binding thing is just broken (as you have mentioned in older posts). I think that using only one keybinding file instead of two is a necessity for fixing it. But I really don't know any better, so I'm sorry. :(

[Oddegamra]

I think that there should be an appropriate hint in the Help menu or something. Otherwise, no one would use this feature (or even call this a bug because of seemingly random key rebindings).

This isn't actually a MComix feature per se, but comes with GTK+ applications by default.

A short historical rundown on keybindings in Comix/MComix and how I ended up with this somewhat unfortunate "design":

Back in the days, all keybindings in Comix were hardcoded. Most came from the UI hotkeys, but some additional keys were handled in event.py (mostly for scrolling). I believe this path was taken because GTK+ only allows one hotkey per action, and requires a menu item for any action.

At one point, I fixed loading and saving keybindings from menu items as per request/bug report, and thus keybindings-gtk.rc was born. Before this point, UI hotkeys could be changed, but would revert back as soon the application was restarted.

Later, all hardcoded keybindings from event.py were removed and moved into a customizable configuration file, i.e. keybindings.conf. Again, this file only contains some additional keybindings that are not already handled by menu hotkeys. At this point, I considered removing all GTK+ bindings and using only this new keybinding handler for all keys. Unfortunately, this would also remove hotkey indicators from all menu items, greatly reducing usability of the program, as most people would have no way of finding out which key is bound to which action.

Originally, I planned to create a hotkey tabs in the preferences dialog that allows for easy modification of all keybindings in one place. Unfortunately, writing this particular piece of code turned out to be most difficult, as it somehow had to handle GTK+ accelerators, individual bindings, prevent duplicated bindings, update menu items, and so forth.

Thus, I am at a point where I have not the slightest clue on how to proceed. If possible at all, I want to get rid of any GTK+-related handling (because it sucks), but still somehow keep the UI hints.

[Ark]

This isn't actually a MComix feature per se, but comes with GTK+ applications by default.

Wow.

A short historical rundown on keybindings in Comix/MComix and how I ended up with this somewhat unfortunate "design"

Thank you a lot for this explanation. It really helps understand this issue.

I don't know how GTK+ works so I'm just guessing. Is it possible to use the GTK+ keybinding mechanism only for the first shortcut that can be used like this (for each action)?

Example (how to read keybindings.conf): You have an action ACTION and three shortcuts, A, B, and C (in that order, as defined in keybindings.conf), for this action. Both B and C can be used as GTK+ shortcuts while A cannot. Then B is bound to ACTION using the GTK+ keybinding mechanism, while A and C are bound to ACTION using the other keybinding mechanism.

Example (how to write keybindings.conf): You have an action ACTION and three shortcuts, A, B, and C, bound to this action. B is bound to ACTION using the GTK+ keybinding mechanism, while A and C are bound to ACTION using the other mechanism. Then B is written out first, followed by A and C, for this action.

This way, you won't need keybindings-gtk.rc.

[Oddegamra]

I thought about something like that in the past, too. AccelMap has a few methods that might allow changing hotkeys after the menu has been created, and even to listen on changes made by GTK+'s keybinding mechanism. It would turn out ugly, though. Very ugly. I might try one of these days, but will have to do a bit more testing before that.

[Ark]

After a lot of experimenting and a lot of thinking, it turns out that this whole zoom key issue is a very complicated thing.

For example, if you use at least one of "Best fit", "Fit width", "Fit height", "Fit size" or "Stretch small images", the actual "Normal size" is set to something that is not necessarily 100%. That is, if you view an image that is too large, and you use "Best fit", using View → Zoom → Normal size then may result in 20% but not 100%. In other words, if you do not use "Manual zoom mode" with "Stretch small images" turned off, there is currently no way to reliably zoom to identity (100%).

I don't know whether this is a bug or a feature, so let's turn this into a feature. That is,

1. scrap everything you already made for this feature request (I'm so sorry, really! The first change came with r826),
2. instead of replacing the old keybindings such as Ctrl+0, now add a menu entry View → Zoom → Zoom to 100% or something that, reliably and completely independently from the view mode(s) currently in use, zooms to 100%.
3. This newly created menu entry should have 0 as the default GTK+ keybinding and/or KP0 as an additional non-GTK+ keybinding.

If I recall it correctly, before this feature request, you could use both + and KP+ by default for zooming in, for example. Currently (r877), only KP+ and KP- work by default, respectively. If you change this back to something before r826, and add the menu entry for "Zoom to 100%", all these shortcuts should work as follows:

• + and KP+ for "Zoom In"
• - and KP- for "Zoom Out"
• 0 and KP0 for "Zoom to 100%"
• Ctrl+0 and Ctrl+KP0 for "Normal Size"

I don't know whether someone except for me would call the current "Normal Size" implementation buggy, but with the suggestion I just made, the "Normal Size" would have its own right to exist. Furthermore, the new default keybindings would be backward compatible with the defaults of older MComix versions.

[Oddegamra]

Thanks to Valentin Gologuzov's work on the shortcut GUI editor, this should be completely solved now.