- Menu item hotkeys can now be changed by hovering over a menu item with
the mouse and pressing the desired key, or key combination.
(by Juha Sahakangas and Alan Horkan)
- All other hotkeys (such as keys for scrolling or zooming) can now be
customized by editing keybindings.conf in MComix' configuration
directory, i.e. ~/.config/mcomix on Linux or %HOMEPATH%/MComix on
Windows. MComix must not be running while editing the file, or changes
will be overwritten once the program exits.
Does this cover your requirements?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't know about this but don't you think that it would be better and simpler if appropriate section in preferences would be created? I am sure many users don't know about method you mentioned and editing manually keybindings.conf can be troublesome because of unfamiliar names of some keys (KP_0, XF86AudioNext, etc.).
Also Hovering over menu and pressing shortcut doesn't always work. For example, when I change lens from "l" to "k" then returning to "l" is impossible without editing keybindings-gtk.rc
In my opinion adding shortcuts section in preferences with possibility of changing/adding/deleting shortcuts to every meaningful action would be the best option.
Overall I think, in current state, shortcuts solution is too messy and not intuitive also there is no information in program about possibility of changing shortcuts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had originally planned to add a keybinding tab to the preferences, but pushed it back to low priority due to the work involved with programming it out. In any case, I'm not too happy with having two different keybinding mechanisms in place, but GTK appears to support only one binding per action. Will probably have to come up with a better solution eventually.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've decided to remove an option to "changed by hovering over a menu item with
the mouse and pressing the desired key", since two ways to assign shortcut are really confusing.
What should we do with shortcuts defined in mcomix.ui? It's not possible to change them, but user see them in menu items.
Also some action are missing from BINDING_INFO and aren't registered in mcomix.event.register_key_events but present in mcomix.ui .
Last edit: Valentin Gologuzov 2013-05-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pretty impressive. This is almost exactly how I originally imagined the configuration should look and work.
The rationale behind BINDING_INFO is to provide hotkeys for actions that either a) cannot be triggered from the UI or b) have multiple keys (such as next page/previous page) which cannot be done with GTK's accelerator scheme. So, many actions do not have a corresponding entry, because there was no need at the time, since the menu items were sufficient.
If we are going this way, it may be sensible to remove all default accelerators from ui.py and register them in event.py instead. That will prevent accidentally re-binding a key that is already used in the menu. Unfortunately, that will also remove all hotkey descriptions from the UI, which isn't all that nice.
Another possibility is to add the accelerator paths from the UI (e.g. <actions>/mcomix-main/open for "File->Open") to BINDING_INFO, and then read the associated hotkey from that accelerator path. This key could then be added to the hotkey array for that particular action and edited in a similar fashion. It's quite an ugly hack, however, seeing as editing this key must trigger another event that signals to GTK that an accelerator has changed.</actions>
I'm not sure how other GTK applications handle this problem, but there seems to be no "elegant" solution to what appears to be a pretty common problem (having more than one hotkey for a particular action).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also we can update menu items shortcut label in runtime with accep_map_change_entry, if shortcuts are changed in preferences.
We only have one last problem, that actions name for the same action aren't equally defined in ui.py and event.py\BINDING_INFO. Can I safely rename action names in event.py to ones in ui.py (e.g.: "previous page" -> "previous_page" )?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That should be possible. Changes to keybindings from earlier versions will probably be invalidated if the action name is changed, but that shouldn't be a problem, seeing how most people probably didn't even know the file could be edited.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Awesome. I fixed some minor issues that were likely copy/paste errors, but overall the new systems seems to work flawlessly.
Some additions:
Moved the treeview for editing shortcuts into its own class/file (keybindings_editor.py)
Added some migration code in order for users to start from a "clean" state. Old keybindings files are simply removed, so that everyone starts from default values.
So, thanks a lot, this problem has been on my mind for a long time. Merged with master branch and updated SVN and Github.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Quoting the changelog for 0.97:
- Menu item hotkeys can now be changed by hovering over a menu item with
the mouse and pressing the desired key, or key combination.
(by Juha Sahakangas and Alan Horkan)
- All other hotkeys (such as keys for scrolling or zooming) can now be
customized by editing keybindings.conf in MComix' configuration
directory, i.e. ~/.config/mcomix on Linux or %HOMEPATH%/MComix on
Windows. MComix must not be running while editing the file, or changes
will be overwritten once the program exits.
Does this cover your requirements?
I didn't know about this but don't you think that it would be better and simpler if appropriate section in preferences would be created? I am sure many users don't know about method you mentioned and editing manually keybindings.conf can be troublesome because of unfamiliar names of some keys (KP_0, XF86AudioNext, etc.).
Also Hovering over menu and pressing shortcut doesn't always work. For example, when I change lens from "l" to "k" then returning to "l" is impossible without editing keybindings-gtk.rc
In my opinion adding shortcuts section in preferences with possibility of changing/adding/deleting shortcuts to every meaningful action would be the best option.
Overall I think, in current state, shortcuts solution is too messy and not intuitive also there is no information in program about possibility of changing shortcuts.
I had originally planned to add a keybinding tab to the preferences, but pushed it back to low priority due to the work involved with programming it out. In any case, I'm not too happy with having two different keybinding mechanisms in place, but GTK appears to support only one binding per action. Will probably have to come up with a better solution eventually.
Hello I've tried to fix this problem.
Please look at branch https://github.com/evilkost/mcomix/tree/shortcuts .
I've decided to remove an option to "changed by hovering over a menu item with
the mouse and pressing the desired key", since two ways to assign shortcut are really confusing.
What should we do with shortcuts defined in mcomix.ui? It's not possible to change them, but user see them in menu items.
Also some action are missing from BINDING_INFO and aren't registered in mcomix.event.register_key_events but present in mcomix.ui .
Last edit: Valentin Gologuzov 2013-05-04
Pretty impressive. This is almost exactly how I originally imagined the configuration should look and work.
The rationale behind BINDING_INFO is to provide hotkeys for actions that either a) cannot be triggered from the UI or b) have multiple keys (such as next page/previous page) which cannot be done with GTK's accelerator scheme. So, many actions do not have a corresponding entry, because there was no need at the time, since the menu items were sufficient.
If we are going this way, it may be sensible to remove all default accelerators from ui.py and register them in event.py instead. That will prevent accidentally re-binding a key that is already used in the menu. Unfortunately, that will also remove all hotkey descriptions from the UI, which isn't all that nice.
Another possibility is to add the accelerator paths from the UI (e.g. <actions>/mcomix-main/open for "File->Open") to BINDING_INFO, and then read the associated hotkey from that accelerator path. This key could then be added to the hotkey array for that particular action and edited in a similar fashion. It's quite an ugly hack, however, seeing as editing this key must trigger another event that signals to GTK that an accelerator has changed.</actions>
I'm not sure how other GTK applications handle this problem, but there seems to be no "elegant" solution to what appears to be a pretty common problem (having more than one hotkey for a particular action).
In fact we can remove accelerators from ui.py and dynamicaly add them from register.py(keybindings.conf) with
Also we can update menu items shortcut label in runtime with accep_map_change_entry, if shortcuts are changed in preferences.
We only have one last problem, that actions name for the same action aren't equally defined in ui.py and event.py\BINDING_INFO. Can I safely rename action names in event.py to ones in ui.py (e.g.: "previous page" -> "previous_page" )?
That should be possible. Changes to keybindings from earlier versions will probably be invalidated if the action name is changed, but that shouldn't be a problem, seeing how most people probably didn't even know the file could be edited.
|'ve sent a pull request on github, hope it's good enough.
Last edit: Valentin Gologuzov 2013-05-07
Awesome. I fixed some minor issues that were likely copy/paste errors, but overall the new systems seems to work flawlessly.
Some additions:
So, thanks a lot, this problem has been on my mind for a long time. Merged with master branch and updated SVN and Github.