There are at least three different ways out of this:
(1) Leave it as-is but *document* that ctrl/= triggers "zoom in" as a "special feature" in FLTK - and additionally all the other special behavior caused by "French" (and US/UK) keyboard "adjustments" for user conveniency.
(2) Remove the special treatment altogether which would result in "correct" behavior but less comfortable zoom key handling for some keyboards.
(3) Make a combination of (1) and (2) and give users an option (Fl::option(...)) to decide. This would be per user or per system and would not have to be set per program but could be done once with `fltk-options`.
My minimal request would be (1), i.e. document the behavior clearly so users are not surprised. However, I would more likely opt for (3) to make the behavior optional, with the "special" treatment of ctrl/= and other combinations being opt-in and not the default
The optimal solution would probably be to make these keyboard/zoom key adjustments only if we "knew" that one of the affected keyboards (US/UK/FR) is in use but I don't know how this would be doable (cross-platform, independent of the desktop environment, etc.).
I was also afraid that the zoom handling of ctrl/= could take precedence, i.e. override a menu shortcut defined by the user program but this seems not to be the case since the zoom key interpretation is done after menu shortcuts - unless users define their own shortcut handlers etc. etc. (which is another can of worms because it must be done in the correct order).
Ideally we would even have options to define own shortcuts for all zoom/scale actions to avoid conflicts with user program shortcuts, but that's a different topic. And did I mention it? An easy way to disable FLTK's zoom/scale handling would be useful just in case a user program implemented its own "zoom" handling.
Le mardi 27 février 2024 à 15:09:58 UTC+1, Albrecht Schlosser a écrit :
There are at least three different ways out of this:
(1) Leave it as-is but *document* that ctrl/= triggers "zoom in" as a "special feature" in FLTK - and additionally all the other special behavior caused by "French" (and US/UK) keyboard "adjustments" for user conveniency.
I will document that.
(2) Remove the special treatment altogether which would result in "correct" behavior but less comfortable zoom key handling for some keyboards.
I believe it's impossible to program that in a keyboard-independent layout without the program knowing the valueof the layout, which I don't know how to do, and must be avoided at all cost.
That's because + is in shifted or unshifted position on the layout.
(3) Make a combination of (1) and (2) and give users an option (Fl::option(...)) to decide. This would be per user or per system and would not have to be set per program but could be done once with `fltk-options`.
My minimal request would be (1), i.e. document the behavior clearly so users are not surprised. However, I would more likely opt for (3) to make the behavior optional, with the "special" treatment of ctrl/= and other combinations being opt-in and not the default
The optimal solution would probably be to make these keyboard/zoom key adjustments only if we "knew" that one of the affected keyboards (US/UK/FR) is in use but I don't know how this would be doable (cross-platform, independent of the desktop environment, etc.).
I was also afraid that the zoom handling of ctrl/= could take precedence, i.e. override a menu shortcut defined by the user program but this seems not to be the case since the zoom key interpretation is done after menu shortcuts - unless users define their own shortcut handlers etc. etc. (which is another can of worms because it must be done in the correct order).
Ideally we would even have options to define own shortcuts for all zoom/scale actions to avoid conflicts with user program shortcuts, but that's a different topic. And did I mention it? An easy way to disable FLTK's zoom/scale handling would be useful just in case a user program implemented its own "zoom" handling.
Isn't the fact that menu shortcuts have priority over scaling shortcuts enough for that?
- This prevents an FLTK app from giving another meaning to shortcut Ctrl = whilekeeping Ctrl + for scaling.……
I understand, as Albrecht pointed out, that accepting it prevents FLTK from usingshortcut FL_COMMAND+'=' for another purpose.
The source code to identify Ctrl/+/-/0/ shortcuts has been much simplified (f4fb973).This has removed the need for special processing of key '6' .Now, the code uses Fl::test_shortcut(FL_COMMAND+'+') (or '0' or '-') to detect scaling shortcuts.
The only special processing remaining is at the end of function Fl::test_shortcut(),to recognize the FL_COMMAND+'+' shortcut even without pressing the shift key.
If we'd decide not to retain this special processing, it would be enough to remove3 lines at the end of this function.
Here is where we stand now- There's a public API to deactivate scaling shortcuts altogether.- Scaling shortcuts are given low priority so that any other callback attached to themby the app prevails.- For convenience, the Ctrl + shortcut is accepted without pressing the shift key even ifcharacter '+' is in a shifted position on the keyboard (e.g., US/UK/FR/IT).- This prevents an FLTK app from giving another meaning to shortcut Ctrl = whilekeeping Ctrl + for scaling.
I am very embarassed about this special treatment of the FL_COMMAND+'+' shortcut.I understand, as Albrecht pointed out, that accepting it prevents FLTK from usingshortcut FL_COMMAND+'=' for another purpose.But I see that under macOS these applications have a menu item with the ⌘ + shortcutthat is activated without pressing the shift key: Firefox, Safari, Xcode, Terminal,
Dictionary, Messages, Preview, …So, this behavior is very much expected. It's also more convenient.
On 2/28/24 09:49 Manolo wrote:
The only special processing remaining is at the end of function Fl::test_shortcut(), to recognize the FL_COMMAND+'+' shortcut even without pressing the shift key.I'm not that happy with *this* part though. Fl::test_shortcut() is a global function and this would affect shortcut testing in other scenarios (menus etc.) as well. This should be avoided.
I suggest to make this additional check local to Fl_Screen_Driver::scale_handler() so it only affects the scale handler rather than all other shortcut tests. Manolo, can you do this, or am I missing anything?
If done this way it would be a conveniency improvement for scaling but would not affect anything else. Other ctrl/+ shortcuts in menus would still require the shift key but that would be backwards compatible with 1.3 and thus positive.
Albrecht Schlosser schrieb am Mittwoch, 28. Februar 2024 um 17:04:42 UTC+1:On 2/28/24 09:49 Manolo wrote:
The only special processing remaining is at the end of function Fl::test_shortcut(), to recognize the FL_COMMAND+'+' shortcut even without pressing the shift key.I'm not that happy with *this* part though. Fl::test_shortcut() is a global function and this would affect shortcut testing in other scenarios (menus etc.) as well. This should be avoided.
I suggest to make this additional check local to Fl_Screen_Driver::scale_handler() so it only affects the scale handler rather than all other shortcut tests. Manolo, can you do this, or am I missing anything?
If done this way it would be a conveniency improvement for scaling but would not affect anything else. Other ctrl/+ shortcuts in menus would still require the shift key but that would be backwards compatible with 1.3 and thus positive.I am quite unhappy with allowing unshifted keys as shortcuts when the actual value is shifted (To allow CMD-'=' instead of CMD-'+' on the U.S. keyboard). Imagine your app has a menu item with CMD-'=' as a shortcut to split a text editor horizontally. This would override the CMD='+' functionality. But if the CMD-'=' is disabled (grayed out) for some reason (the editor is already split), CMD-'=' will now fall back to scaling the windows, which is unexpected.
FLTK does this by default with letter shortcuts. For example, if Ctlr-Shift-'Z' is unused, the event is sent again with text case swapped: src/Fl.cxx:1459 . Imagine you have to menu items: "Print" Ctrl-P, and "Partition System Drive" Ctrl-Shift-P. Now, let's say there is no printer and the Print menu is grayed out, FLTK resends a Ctrl-P shortcut again as Ctrl-Shift-P, which then partitions the system drive, which is quite unexpected.
Le mercredi 28 février 2024 à 17:34:44 UTC+1, Matthias a écrit :
I am quite unhappy with allowing unshifted keys as shortcuts when the actual value is shifted (To allow CMD-'=' instead of CMD-'+' on the U.S. keyboard). Imagine your app has a menu item with CMD-'=' as a shortcut to split a text editor horizontally. This would override the CMD='+' functionality. But if the CMD-'=' is disabled (grayed out) for some reason (the editor is already split), CMD-'=' will now fall back to scaling the windows, which is unexpected.
I had thought of doing that, put the special processing only in function Fl_Screen_Driver::scale_handler(). But I was stopped exactly bythis scenario (which Albrecht had also reported in an earlier post): if a menu item with ctrl= shortcut is disabled,FLTK will send the shortcut event to the last handler which is Fl_Screen_Driver::scale_handler() and wouldtrigger the "zoom in" command. No improvement brought by the code change.
I will implement nevertheless the proposed change because it does improve on that other scenario:
- if the app calls Fl::keyboard_screen_scaling(0); to disable scaling shortcuts altogether, the proposed codechange has an effect because it prevents ctrl= keystrokes from colliding with ctrl+ keystrokes if the app expects only
one of them to have an effect.
So, we are left with a choice between 2 solutions :
1) Allow ctrl= to be generally interpreted as ctrl+ unless menu items attach other callbacks to these shortcutsor unless scaling shortcuts are disabled. Document that a scenario is to be avoided by FLTK apps: use a ctrl= shortcut thatcan be disabled at times. This choice facilitates obtention of the "zoom in" command with the keyboard (except with Germankeyboard layouts). It matches with what many applications do.
2) Strictly differentiate ctrl= from ctrl+. No unexpected shortcuts occur. Many users have to press 3 keys instead of 2to get the "zoom in" operation.
4) Another option *would* be to let users set arbitrary shortcuts for zoom functions. They could do this already today via their own shortcut handler or menus with shortcut. What I don't know is how they would call the "zoom" function in this case. Manolo?
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/94670216-99a3-457e-ad40-febd6bee56b2%40online.de.
On 2/28/24 19:34 Manolo wrote:
I will implement nevertheless the proposed change because it does improve on that other scenario:
- if the app calls Fl::keyboard_screen_scaling(0); to disable scaling shortcuts altogether, the proposed codechange has an effect because it prevents ctrl= keystrokes from colliding with ctrl+ keystrokes if the app expects only
one of them to have an effect.Yep, that's really necessary. Please go ahead!
Note: Choice 3) is what I will do (after Manolo centralized the key processing in the handler) if nobody else beats me to it. Volunteers may drop a note in this thread.
On Linux, I see what I believe is the expected/intended behavior, which is that I can scale down with "Ctrl -" and scale up with "Shift Ctrl =" (aka, "Ctrl +").I can also scale down with "Ctrl NumPad-" and "Ctrl NumPad+" (without Shift). I think this works very well.On Mac, it appears a little backwards for me. I can scale down with "Cmd -" and scale up with "Cmd =".Using "Shift Cmd =" (aka, "Cmd +") does nothing. This is inverted compared to Linux.On Windows, I can scale down with "Ctrl -" but neither "Ctrl =" or "Shift Ctrl =" do anything. The only way to scale up on Windows for me is "Ctrl NumPad+".
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/ba3f2795-08a4-43da-8147-47c53b350998n%40googlegroups.com.
On Monday 4 March 2024 at 14:46:21 UTC Daniel Harding wrote:
On Linux, I see what I believe is the expected/intended behavior, which is that I can scale down with "Ctrl -" and scale up with "Shift Ctrl =" (aka, "Ctrl +").
I can also scale down with "Ctrl NumPad-" and "Ctrl NumPad+" (without Shift). I think this works very well.
On Mac, it appears a little backwards for me. I can scale down with "Cmd -" and scale up with "Cmd =".Using "Shift Cmd =" (aka, "Cmd +") does nothing. This is inverted compared to Linux.
On Windows, I can scale down with "Ctrl -" but neither "Ctrl =" or "Shift Ctrl =" do anything. The only way to scale up on Windows for me is "Ctrl NumPad+".
So, like Daniel, I'm seeing odd behaviours under Windows
- and FWIW the Linux behaviour isn't quite what I expected either...
This was tested with commit a0ff3f6f5c6994f4260685d70cc5f8349a8fdb69 on Win11 with a UK layout keyboard (that happens to be TKL - more on that later...)I am only running code samples from the /test folder, not any other code.
Basically, what I find is that, in most cases, I can zoom smaller with "CTRL-" but I pretty much can not zoom larger with either "CTRL=" or "CTRL SHIFT=".
Some tests do (this might be a false memory - I tested _a lot_ of combinations, but right now I can not find one that does actually work!) respond to "CTRL SHIFT =" but most do not.
"CTRL 0" always seems to work to restore the default zoom level.
Since this keyboard is TKL, I do not have the option of using the keypad "+" symbol at all, so this zoom behaviour is basically useless for me - the option I use is pretty much always zoom larger, when things pop up too small on a high-DPI display.
Under Linux, I see "CTRL SHIFT =" does seem to work, but "CTRL =" does not.
I recognize that (Linux behaviour) was the behaviour that Albrecht and others favoured but it seems to be at odds with what I see from other apps. As Manolo reports, Firefox, does accept "CTRL =" as being a synonym for "CTRL SHIFT =". I also find that Chrome does too - I recall Albrecht saying it does not, but at least for me, it definitely does.
Under Windows (10 and 11) I tried quite a few apps., and many seem to accept "CTRL =" as a synonym for zoom larger - at least in my setup.I even discovered (during a particularly dull meeting) that Teams accepts that key combo. along with a random smattering of others MS apps.
Going off at a tangent, Manolo said the "problem" afflicts US/UK/FR/IT keyboards, but in reality the "problem" is much wider than that - due to technical lead in computing (US) or vestiges of past empire (UK/FR/IT) an awful lot of the worlds keyboards are "heavily influenced" by these layouts and have the same issue.Basically all Indic keyboards use a layout that is very heavily based on the UK and US layouts, and most Chinese keyboards (pinyin, canjie, wubi, whatever) are basically US keyboards.
Interestingly, the Japanese JIS layout (which I had thought was another US style layout) turns out to be a whole other thing - yes, it is _mostly_ like a US layout, but with a few keys moved about to better suit their orthography.So the "+" key is not in the "SHIFT =" position on a JIS keyboard. It is moved to "SHIFT ;" instead... Great, that helps us a lot...
All that said, I have nothing actually useful to offer...
……
> The FLTK X11 and Wayland code contains a few lines that do extra
> operations for number keys exactly to allow use of 'Ctrl+digit'
> keystrokes with Fr keyboards.
That's good - and good to know. Can you give me a pointer to where such
code is, for both platforms? TIA.
... for non-letter keys like '+', '-', '=' I couldn't find a usable
value. It looks like CTRL / X where X is a key on the default (US)
keyboard layout. This doesn't really help. There are more functions I
didn't explore (yet?) to map virtual keycodes to a specific key
dependent on the "keyboard layout". This *might* help if this would give
us the information that (a) the CTRL key and (b) the '=' key was
pressed. The latter maybe derived from the scan code and the current
keyboard layout...
If anybody could help by contributing code how to map a CTRL/K combo
with 'K' not being an alphabetical key, then I'd appreciate this very much!
On 3/5/24 21:50 Albrecht Schlosser wrote:
If anybody could help by contributing code how to map a CTRL/K combo
with 'K' not being an alphabetical key, then I'd appreciate this very much!
I'm still looking for a clean and system conformant way to get the correct key information. Any help would be appreciated.
The problem is that we don't get the key codes from Windows. We are using a "hand-made" translation table in our code instead, ...
I'm trying to find a better solution but so far I don't know if I can find a solution independent of hard-coded keyboard layout information. That would be my goal. Although I'm much more confident now. There *should* be a way to get the key information from the OS...