This PR changes the default zoom-in keybinding to <Primary>equal. This potentially resolves #596 and #1712.
* Should work on all platforms. Effect for some is that <Shift> will no longer have to be pressed. * Matches keybinding used by other apps (Firefox, Chromium, other web browsers, some image viewers) You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2956
-- Commit Summary --
* <a href="https://github.com/geany/geany/pull/2956/commits/3690f7c26dc2c31a025d046a8a003508f0c7d955">Change default zoom-in keybinding to <Primary>equal</a>
-- File Changes --
M src/keybindings.c (2)
-- Patch Links --
https://github.com/geany/geany/pull/2956.patch https://github.com/geany/geany/pull/2956.diff
I would normally whinge about screwing with peoples muscle memory if changing default keybindings, but the only two apps I have found that still use `<ctrl><shift>equals` (aka `<ctrl>plus`) are Geany and Eclipse, so those are the ones screwing the muscle memory.
Also personally I don't use zoom so I don't care either way.
I don't use zoom either, but have a few other PRs that affect zoom behavior. I also figure 4-6 years should be long enough to wait to fix an issue that has affected more than one person (#596 and #1712).
No because <Primary>-<Equal> would be very uncomfortable on my German keyboard layout!
Seriously, I understand the point and that the equal sign is easier to type than the plus on a US keyboard layout. Interestingly, on a German layout it's vice versa.
Regardless, what I'm wondering about and what I don't understand is that the Gnome HIGs suggest <Primary>-<Plus> (https://developer.gnome.org/hig/reference/keyboard.html?highlight=zoom#view-...). And I guess this is also where the current default value in Geany has its source.
Until this PR I wasn't aware of <Primary>-<Equal> for zoom in. But just noticed Firefox (at least in my configuration) accepts <Primary>-<Equal> *and* <Primary>-<Plus> for zoom in.
@eht16 Maybe Geany could accept both as well? Is there a way to have two keybindings for the same action, or would another action need to be added?
That is what I was thinking about, to have both shortcuts by default and (probably) only one can be edited.
I guess this is not possible right now but a second hard-coded keybinding can be added easily probably. The more relevant question is - do we want this or is switching to `<Primary>-<Equal>` just the way to go?
If German keyboards won't work with this, it's just trading one problem for another. (We'd be changing it to something else in six years.)
I don't know how to program this, but maybe... if either `<primary>plus` or `<primary>equal` is set, the other is also accepted (are = and + on the same key on the German keyboard?). But if neither is set (the user explicitly set a different keybinding), then neither are accepted.
I guess nobody else (chrome, firefox etc) read the Gnome HIG.
Probably best not to add a hard coded action for any keybinding, some user is guaranteed to have a problem with it on an Elbonian keyboard [Dilbert reference].
Instead add a second keybinding action defaulting to `<ctrl>equals` so that it can be unset, modified etc if some user has a problem with it. I think it just needs duplicating [this](https://github.com/geany/geany/blob/04566236d3f9811d55d6c7bcc492b3a60369fd20...) (plus the manual explaining why there are two zooms) :smile:
Okay, I'll add a second zoom action (but not in the menu) and update this PR.
@xiota pushed 2 commits.
718a867514ef9968b8d451a3eaf49724cbc3d39d Change default zoom-in keybinding to <Primary>equal 24c9852df0fe871e2ba7d51a66c2c4843e0789fd Add secondary actions for cut, copy, paste, zoom in/out
@xiota pushed 1 commit.
a5093d7027f933e4abf64f69bb0bc03e43e1233d Replace NULL with 0 in add_kb
@xiota pushed 1 commit.
0198ae0669ac8303c20d657c42bd01688ed5a059 Fix parameters to add_kb
Why cut copy paste? All discussion has been about zoom.
Why cut copy paste? All discussion has been about zoom.
So I can assign both ctrl+c/v and ctrl+shift+c/v to copy/paste.
Okay, three for paste would be too much... I'll remove cut/copy/paste and put them in a plugin...
Should zoom out also have a second action or just zoom in?
@xiota pushed 1 commit.
8177bb7278e8d3f54d4e8a92353eb0f0d3be2899 remove secondary cut/copy/paste actions
@xiota pushed 1 commit.
62d810788fb29004f2c29026f3a1a51f70598031 remove remnants of second cut/copy/paste actions
Keybindings are a linear search through the list, whilst adding each additional one is immaterial, if each one isn't actively challenged then they keep adding until keyboard operation becomes slow.
Since nobody has complained about zoom out lets leave it out for now.
because nano...
Geany isn't Nano, if a nanoist wants to change their keybinding thats fine, but its not up to Geany to provide equivalences for every editor out there, thats plugin territory, [see](https://plugins.geany.org/vimode.html)
Since nobody has complained about zoom out lets leave it out for now.
Okay. Will remove it.
thats plugin territory
Yes. I already talked myself into putting it into a plugin.
@xiota pushed 1 commit.
497b171a7a6c063128cad2f5374dba4b49d8a0bb remove second zoom out action
Keybindings are a linear search through the list, whilst adding each additional one is immaterial, if each one isn't actively challenged then they keep adding until keyboard operation becomes slow.
Just a note, _every_ key goes through the search, and its actually keys that are not keybindings that take the longest since they search the whole list exhaustively.
every key goes through the search
So each key pressed to type a sentence in the editor has to go through the keybinding search?
So each key pressed to type a sentence in the editor has to go through the keybinding search?
AFAICT yes.
Couldn't it be implemented as a jump table? So it would take constant time to locate the correct response?
There are 2^21 Unicode code points multiplied by 2^(the number of modifiers), so no.
A hash table might possibly be a solution, just "somebody" has to do it and make sure all the special cases in [this](https://github.com/geany/geany/blob/04566236d3f9811d55d6c7bcc492b3a60369fd20...) are covered.
Unicode code points
Keyboards don't create unicode code points. That's what the IME is for. Only keycodes that can actually be generated need to be checked. Most keyboards have fewer than 128 keys. The modifier keys could be checked separately. So you'd have have a jump plus a few comparisons to find the right response.
`gdkkeysyms.h` has some strange "keys" defined. A lot of them look like "synthetic" keys. (GDK_KEY_Red?)
Keyboards don't create unicode code points.
You are right, keyval is not always a code point, although often coincidentally the value happens to be the same :smile:. But keyval does use at least 25 bits (see cyrillic or armenian in `gdkkeysyms.h`) so its worse than I thought. Also on some keyboards with "dead" keys GDK maps a multiple key sequences into one key event without IME. And IME still generates a keyevent IIUC with Unicode keyvals.
Most keyboards have fewer than 128 keys.
Not true, some non-asian keyboards have up to 4 values per keycap, see [French](https://en.wikipedia.org/wiki/File:Azerty_NFZ71-300.png) or probably @eht16's German keyboard. And also _which_ values? As you can see in `gdkkeysyms.h` keyval can cover a wide range of values. A simple table of all possible keyvalues from keyval to function address is far too big even if state is handled separately.
Thats why I suggest a hash table (or binary tree), key is combined `keyval` and `state` from the event and value is the function to call, the number of entries is related to the number of active keybindings, not the number of possible key values and the performance is constant for hash and O(ln(entries)) for tree (say 7 compares of a 64 bit value if 128 keybindings are set). Because keyvals from any one keyboard are likely to be close to sequential the combination and hash of `keyval` and `state` needs to ensure that performance does not approach linear worst case if hash is used, probably tree is safer because it doesn't have the bad worst case performance. Don't know which is easier to use/maintain.
Keyboards are a real pain, see also #1368 for another saga.
... Keyboards are a real pain...
Looks like it. Glad someone else is willing to manage it.
@elextr commented on this pull request.
@@ -277,6 +277,7 @@ enum GeanyKeyBindingID
* @since 1.34 (API 238) */ GEANY_KEYS_FILE_RELOAD_ALL, /**< Keybinding. * @since 1.38 (API 240) */ + GEANY_KEYS_VIEW_ZOOMIN_2, /**< Keybinding. */
Needs a since like the one above.
Not tested, but looks good.
@xiota pushed 1 commit.
fb454d0ebd4da06351274332d6273dd4e1a5e4f1 update doxygen comment
@xiota commented on this pull request.
@@ -277,6 +277,7 @@ enum GeanyKeyBindingID
* @since 1.34 (API 238) */ GEANY_KEYS_FILE_RELOAD_ALL, /**< Keybinding. * @since 1.38 (API 240) */ + GEANY_KEYS_VIEW_ZOOMIN_2, /**< Keybinding. */
Thanks. Updated.
@xiota pushed 1 commit.
28605870c6f2649291be7af92e5551b833fa7abe Update doxygen comment
@xiota pushed 0 commits.
Force push because confused branches/changes.
@xiota pushed 1 commit.
8b6aa87a600a1283238f4212e173dde55ccd125a update doxygen comment
github-comments@lists.geany.org