Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#69 Simpler shortcut for zooming to normal size.

SVN
closed
nobody
None
5
2013-05-08
2013-01-10
Ark
No

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!

Discussion

1 2 > >> (Page 1 of 2)
  • Oddegamra
    Oddegamra
    2013-01-11

    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
    Ark
    2013-01-13

    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
    Oddegamra
    2013-01-13

    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.

     

    Related

    Wiki: Keybindings

  • Ark
    Ark
    2013-01-14

    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
    Oddegamra
    2013-01-14

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

    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).

    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.

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

     
  • Oddegamra
    Oddegamra
    2013-01-16

    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
    Oddegamra
    2013-01-16

    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
    Ark
    2013-01-17

    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
    Oddegamra
    2013-01-17

    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
    Ark
    2013-01-17

    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.

     
1 2 > >> (Page 1 of 2)