Key-combination for zoom (forked from fltk-general Sys-Menu-Bar thread)

[imacarthur]

Albrecht suggested we bring this conversation here from fltk-general, and in any case split it out of the Fl_Sys_Menu_Bar thread, as it is somewhat orthogonal to that.

Summary: Should fltk interpret   CMD= as being "the same" as CMD+, i.e. to mean "zoom larger"?

Albrecht said:

<quote>

I do not agree with Manolo's view, I agree with Daniel's view. I can also not make much sense of ctrl/= working like ctrl/+, no matter on what (international) keyboard is used.

But we should better discuss this in fltk.coredev rather than using this thread. 

</quote>

Manolo said:

<quote>

FLTK aims to reproduce what Firefox does in its View menu, Zoom submenu :

the "Zoom in" menu item lists ⌘ + as shortcut (not ⌘ ⇧ something)

and pressing the key containing '+' and  the key ⌘ together triggers the "Zoom in"

operation.

Depending on the keyboard layout in use, symbol '+' may be in the shifted

(English, French) or the unshifted (German) position of its key. 

Firefox's "Zoom in" menu item always displays the same shortcut (⌘ +) 

whatever the keyboard layout in use.

On non macOS platforms, ⌘ is replaced by Ctrl.

The present code in FLTK does the same across platforms.

</quote>

So... for my part, I'm with Manolo on this. That is to say, I think that "CMD=" can/should be interpreted as "the same" as "CMD+"

Why?

Because on a standard UK-ISO or US-ANSI layout keyboard, which is what I am most likely to be using, the "+" symbol is ONLY available[1] as the shifted state of the "=" key.

This key is adjacent to the key for "-_" where "-" is available in the unshifted position.

So the "natural" way to handle zoom (and that used by many apps) is for these two keys to be the "opposite" of each other.

But when I'm zooming larger, I do not want to have to press 3 keys "CMD SHIFT +" when the zoom smaller uses only 2 keys "CMD -", that just feels strange and unnatural.

If we treat "CMD =" as also meaning zoom larger, it then Just Works - and is consistent with what many other apps seem to do.

YMMV.

[1] The "+" key is available unshifted on the keypad of a "full" keyboard, but most of my keyboards are TKL, so I do not have that option and even when I do use a "full" keyboard I almost never use the keypad, it just sits there taking up desk space... And I do not think that is actually all that unusual, TBH.

[Albrecht Schlosser]

[top-posting intentionally for clarity]

I understand the arguments that on *some* national keyboards having to press the SHIFT key to trigger some of the zoom functions is inconvenient. However I can't understand that FLTK would do things that are not documented and appear to be wrong on other national keyboards. And, BTW, the special treatment of the French keyboard (as code comments say), is not limited to the '=' key, there's also something related to the '6' key, and the ctrl/à key (a key combination that's impossible probably on all but French keyboards).

I see also that Firefox behaves as Manolo describes but Google Chromium does not (at least not with a German keyboard). There *are* differences, it's not the case that "other" applications all work the same way.

If I hit ctrl/0 I get the expected result (reset zoom). If I hit ctrl/shift/0 on my German keyboard I don't get the same result as with ctrl/0 - I rather get the the behavior of ctrl/= (because '=' is on the '0' key in the shift state), and this is equivalent to ctrl/+ (zoom in). This is at least unexpected behavior.

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.

@Ian: thanks for moving this issue to fltk.coredev.

[end of my comments]

[Manolo]

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 value

of 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?

[Albrecht Schlosser]

On 2/27/24 17:09 Manolo wrote:

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.

This would be OK if we kept this odd behavior. [This doesn't mean that I assume that we remove it, it's just a conditional statement.]

(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 value

of the layout, which I don't know how to do, and must be avoided at all cost.

Sorry, but no. The "correct" behavior would be that you need to press and hold both the ctrl and shift keys if you want to get ctrl/+ (zoom in) on a French or US/UK keyboard. Note to others: French and US/UK keyboards have '=' in the unshifted and '+' in the shifted position on the same key.

Testing this with a French keyboard setup in test/keyboard shows the correct values:

- ctrl +         '=/+' : Fl::event_key() == Fl::event_text() == '='
- ctrl + shift + '=/+' : Fl::event_key() == Fl::event_text() == '+'

That's what I mean with *correct* behavior, and that's what FLTK is doing for us to get the correct event text.

Admittedly, it's less convenient for (some) users, but for the purpose of this discussion: there's nothing that would prevent us from doing this.

OTOH: on a German keyboard we have '0' in the unshifted position and '=' in the shifted position.

- If the user presses ctrl + '0' they get what they expect (zoom reset).
- If they press ctrl + shift + '0' (i.e. ctrl/=) they get unexpected behavior (zoom in).

That's because + is in shifted or unshifted position on the layout.

See above, there's nothing wrong with this - unless I'm missing something.

(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?

No, not really. The current behavior triggers unexpected effects (zoom in/out/reset) when I press some keys on my keyboard other than the specific keys defined for that purpose. The same would be true for other keyboard layouts - and other users, it's not just me.

Let's assume an US keyboard and let the user define a shortcut for ctrl/= in a menu. This is using ctrl plus the unshifted '=' key (the shifted key would be '+'). Let's further assume that this menu shortcut can be enabled or disabled somehow depending on context. Now, what happens?

(1) While the ctrl/= menu shortcut is enabled, the corresponding menu action is triggered because it has priority. So far OK.

(2) While the ctrl/= menu shortcut is disabled for any reason, the user gets the unexpected "zoom in" behavior (ctrl/+). Expected would be: no action.

Note: these are admittedly contrived examples that show how unexpected and even "undefined" such handling of "other" key values can be. That's why I wanted to have it discussed.

That said, we must decide what we want to have:

The behavior of Firefox is not a good example. Either Firefox "knows" how to get the keyboard layout and does what they think is appropriate, or they are just doing it because it's convenient. If it's the latter, then it is their choice, and a browser is different than a GUI tool like FLTK because the browser is free to do whatever they want, whereas FLTK should do what the programmer of an app wants and what they are programming with all variations of key handling etc..

If the "convenient" behavior where getting ctrl/+ behavior on a key where '+' is in the shifted position without pressing the shift key (FR/US/UK keyboard) is what we want, then it's possible to do that, but I would have a bad feeling with this decision. I would definitely want to make this an option rather than the default.

Last but not least: there's also special handling of the '6' key in the code which has not been mentioned yet. That's one more questionable interpretation of user input.

[Evan Laforge]

Just to throw in my 2 cents, and sorry if I'm off-base due to lack of
context, but I would expect fltk to offer a way to do zoom and bind it
to keys like anything else can be bound, but I wouldn't expect or want
any bindings already set up for it. That way I will bind (or not)
whatever keys are appropriate for whatever program I'm writing. So in
my view, fltk shouldn't try to interpret anything on its own, it
should give the tools to bind key commands (as it does) and the author
of the program should do the interpreting. Only the author of the
program knows in what countries and with what keyboards they expect
their program to run, and which conventions to obey or flout. Only OS
vendors get to try to take some attempt at establishing global
standards and defaults, and I don't think zoom is one of them. Or
rather it is, but it's already done in a global way via DPI settings
and accessibility features.

Besides all that, in the conventions I'm familiar with, -/+ is for
changing font size, for a word processor or document viewer otherwise
word-writing-oriented program. It doesn't apply to most programs, and
I wouldn't expect it to cause a general DPI change, which I suppose
this is about.

[Manolo]

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 remove

3 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 them

by the app prevails.

- For convenience, the Ctrl + shortcut is accepted without pressing the shift key even if

character '+' 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 = while 

keeping 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 using

shortcut FL_COMMAND+'=' for another purpose.

But I see that under macOS these applications have a menu item with the ⌘ + shortcut

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

[Manolo]

Le mercredi 28 février 2024 à 09:49:01 UTC+1, Manolo a écrit :

 ……

- This prevents an FLTK app from giving another meaning to shortcut Ctrl = while 

keeping Ctrl + for scaling.

 ……

I understand, as Albrecht pointed out, that accepting it prevents FLTK from using

shortcut FL_COMMAND+'=' for another purpose.

Correction: the present special treatment of FL_COMMAND+'+'  prevents much less than that.

A deactivated menu item with shortcut FL_COMMAND+'=' fails, as Albrecht explained previously.

But having FL_COMMAND+'=' as shortcut of a menu item works and doesn't prevent

Ctrl+Shift+'+' to zoom in.

[Albrecht Schlosser]

On 2/28/24 09:49 Manolo wrote:

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.

This is a good move. The (supposedly positive) side effect of this change is that FLTK does no longer accept ctrl/= on a German keyboard (where I need to press shift as well), or in other words ctrl plus shift plus key ('0' | '=') does no longer trigger the "zoom in" command (as it did  before).

That's good, thanks.

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.

If we'd decide not to retain this special processing, it would be enough to remove

3 lines at the end of this function.

... or, even better, from the modified Fl_Screen_Driver::scale_handler() function. See above.

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 them

by the app prevails.

- For convenience, the Ctrl + shortcut is accepted without pressing the shift key even if

character '+' 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 = while 

keeping Ctrl + for scaling.

I believe if the modified ctrl/+ detection would be moved from test_shortcut() to scale_handler() it would be less of an issue.

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 using

shortcut FL_COMMAND+'=' for another purpose.

But I see that under macOS these applications have a menu item with the ⌘ + shortcut

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

I would be fine with the latest changes plus my suggestion to move the "special treatment of the FL_COMMAND+'+' shortcut" to Fl_Screen_Driver::scale_handler() to make this "special treatment" local to this command recognition - which has the lowest priority anyway.

The impact on other code would AFAICT not be visible anymore and users could also disable it with one well-documented function (Fl::keyboard_screen_scaling(0)) w/o leaving other side effects (in test_shortcut).

For future development I'm thinking about

(a) Fl::option(something) to enable/disable this FLTK zoom/scale function (this would be trivial)

and

(b) an uncomplicated method (function) to let the user establish their own shortcuts.

Point (b) needs a well-defined API and should definitely be done later (1.4.x > 1.4.0 or in 1.5.0).

[melcher....@googlemail.com]

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.

[Manolo]

Le mercredi 28 février 2024 à 17:34:44 UTC+1, Matthias a écrit :

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.

I had thought of doing that, put the special processing only in function Fl_Screen_Driver::scale_handler(). But I was stopped exactly by

this 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 would 

trigger 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 code

change 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 shortcuts

or unless scaling shortcuts are disabled. Document that a scenario is to be avoided by FLTK apps: use a ctrl= shortcut that

can be disabled at times. This choice facilitates obtention of the "zoom in" command with the keyboard (except with German

keyboard 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 2

to get the "zoom in" operation.

 

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.

Is that an argument in favor of equating two shortcut combinations since FLTK does it already with the 26 letters?

[Albrecht Schlosser]

On 2/28/24 19:34 Manolo wrote:

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 by

this 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 would 

trigger the "zoom in" command. No improvement brought by the code change.

The "new" implementation would likely change that effect because you check the shift key as well. But anyway, that's moot, let's go ahead with:

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 code

change 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!

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 shortcuts

or unless scaling shortcuts are disabled. Document that a scenario is to be avoided by FLTK apps: use a ctrl= shortcut that

can be disabled at times. This choice facilitates obtention of the "zoom in" command with the keyboard (except with German

keyboard 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 2

to get the "zoom in" operation.

3) Implement choice 2) but allow to use the "modified" processing if the user sets an FLTK option which is yet to be defined: Fl::option(whatever). If we do this (and I say now: we MUST do this), then it's the user's choice to enable the option either per user or system wide. They can even switch the behavior at the program level by switching this option at runtime. If all the processing is done at one place this should be really easy to implement but it would fix all problems some users may have. That all said, this zoom function is supposedly used rarely, there shouldn't be a big issue with that.


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? This way the program could maybe not only switch the scaling factor to one of the list of predefined factors but programmers could set their own values. What about a zoom slider? I'm not kidding, but this is something I wouldn't want to consider for 1.4.x anyway.


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.

[Manolo]

Le mercredi 28 février 2024 à 20:01:44 UTC+1, Albrecht Schlosser a écrit :

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?

Here is what a zooming callback should do, given

    float f; the new value of the scaling factor

and

   Fl_Window *top;  the focussed window

// the screen containing Fl_Window *top
    int screen = Fl_Window_Driver::driver(top)->screen_num();
    Fl_Screen_Driver *screen_dr = Fl::screen_driver();
    static float initial_scale = screen_dr->scale(screen);
    screen_dr->rescale_all_windows_from_screen(screen, f * initial_scale);
    // to display the transient yellow window
    Fl_Screen_Driver::transient_scale_display(f, screen);
    Fl::handle(FL_ZOOM_EVENT, NULL);
 

[Bill Spitzak]

Not very clear what is being proposed, but I suggest Alt+'+' and Alt+'=' be different shortcuts. However the fallback behavior can have *both* of them do scale-up.

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

[Albrecht Schlosser]

Thanks for the details, I'll take this into account. For usability it would obviously need to be wrapped in a user-callable function.

My idea is basically two overloaded methods:

void Fl::new_scaling_factor(int);
void Fl::new_scaling_factor(float);

Other arguments would be added as required, this is only pseudo code.

The former would increment or decrement the current scaling factor relative to the internal list of scaling factors, i.e. +1 would go to the next step, -1 one step smaller, 0 or another value (to be defined) would reset to the initial scaling, like ctrl/+, ctrl/-, and ctrl/0 would do.

The latter could maybe set an arbitrary scaling factor if that's feasible.

That's just an idea though...

[Manolo]

Le mercredi 28 février 2024 à 20:01:44 UTC+1, Albrecht Schlosser a écrit :

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 code

change 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!

Committed at 5f20698

[Manolo]

Le mercredi 28 février 2024 à 20:01:44 UTC+1, Albrecht Schlosser a écrit :

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.

I volunteer to implement this with the attached patch.

 

[melcher....@googlemail.com]

Thanks for updating fltk-options as well ;-)

[Albrecht Schlosser]

OK, thanks, please go ahead. Patch looks good (untested).

[Daniel Harding]

Thank you for the attention on this.

When using the default options (not doing anything to enable Fl::OPTION_SIMPLE_ZOOM_SHORTCUT or change any other default options) I'm seeing some inconsistent behavior.

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+".

All of this testing was done on test/fullscreen with an ANSI keyboard, using FLTK commit 5ba756e compiled with default options.

[imacarthur]

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

[Bill Spitzak]

I really recommend that the implementation be to just add Ctrl+= as another shortcut for zoom-in, rather than adding code to FLTK to make Ctrl++ be "special".

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

[Albrecht Schlosser]

Replying to Ian's and Daniel's mail together:

On 3/4/24 18:15 imacarthur wrote:

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.

Same here.

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.

Yes, indeed. There's an issue with Fl::event_key() and Fl::event_text() on macOS using an US/UK keyboard and the '-' ('_') and '=' ('+') keys (uppercase symbols in ():

If one of these keys is combined with either the ctrl, shift, option, or command (cloverleaf) key then the contents of Fl::event_key() and Fl::event_text() are swapped which explains the wrong behavior AFAICT.

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

I can confirm the Windows issue. It's even worse than the macOS case described above because Fl::event_key() and/or Fl::event_text() are often not the expected values. With "expected values" I mean - in most parts - the behavior on Linux with different keyboards.

To be clear: I'm testing with test/keyboard.cxx as *THE* reference on Linux. This looks like the "best" implementation so far but maybe it's not correct in all cases. Different international keyboards may have an unclear impact.

- and FWIW the Linux behaviour isn't quite what I expected either...

Hmm, for me the Linux behavior seems to be fine.

 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=".

The former ("CTRL=" not zooming) is as intended, at least if you don't activate OPTION_SIMPLE_ZOOM_SHORTCUT. The latter ("CTRL SHIFT=" not zooming) is unexpected. It should send the equivalent of "CTRL+" which should always work - but it doesn't under Windows.

Example: using (1) CTRL/= and (2) CTRL/SHIFT/= (aka CTRL/+) with UK keyboard:
Shortcut: K = Fl::event_key(), T = Fl::event_text()

Linux (1): K: '=', T: '='
Linux (2): K: '+', T: '+'

Windows (1): K: '=', T: n/a
Windows (2): K: '=', T: n/a

So, under Linux we get "useful" values in both K and T, but under Windows we get the same values in K for both the shifted and the non-shifted key, and T is not available at all.

Since the application (i.e. the internal scale handler) can't "guess the keyboard layout" the Windows version can't get the correct result - unless you set OPTION_SIMPLE_ZOOM_SHORTCUT which interprets ctrl/= as zoom-in. I'm not sure if we lose the necessary information somewhere of if Windows doesn't offer it but I would guess it's the former.

Note that this is only a description of what I found out so far. This wrong and inconsistent behavior on different platforms would also affect user programs that try to use shortcuts for CTRL/= etc. (any non-ASCII key, probably), hence this is something that needs fixing.

Note also that the fault is IMHO not in the recognition of shortcuts in the scale handler but much earlier in the inconsistent return of keypress values in Fl::event_text() and Fl::event_key().

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.

Explanation: if "CTRL SHIFT =" sent something that could be interpreted as "CTRL +" then this would work. However, this is not the case under Windows (see above).

"CTRL 0" always seems to work to restore the default zoom level.

Yep, same for "CTRL -" (OK).

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.

OK, that's the current status but not the intention. As I wrote above we need to fix Fl::event_text() and Fl::event_key(). Unfortunately. But this would be the right time to do it, before we release yet another (minor) version with these bugs.

Under Linux, I see "CTRL SHIFT =" does seem to work, but "CTRL =" does not.

That's expected. What happens if you set OPTION_SIMPLE_ZOOM_SHORTCUT? It should "work" with "CTRL =" if the option is ON.

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.

My point is that the strict rule is correct. Technically. If you want your FLTK applications to behave like Firefox etc. (with your UK keyboard) then feel free to set OPTION_SIMPLE_ZOOM_SHORTCUT. This could be done once per user or per system and ... that's it.

It would be debatable if this option should be the default, seeing that there are so many issues. However, our current solution is only valid for keyboards where the '+' symbol is in the shifted position of the '=' key. That's not a "correct" solution as well (see below: JIS keyboard).

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.

I don't know why these apps are doing this. I admit that it is convenient for users of such apps but as long as we document that the key combos are ctrl/+/-/0 that would be wrong, and we should not affect user programs in that way. But again, there's an option you can set.

I would also add that apps like Firefox are not like a GUI library. We need a clean interface otherwise user programs might not be cross-platform compatible. I'm not sure if Firefox (Mozilla) knows more about the keyboard layout than we do at this point in time. Maybe they do and can offer a compatible solution for any keyboard layout.

But unfortunately that's not all, see below.

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

This is one of the reasons I was anticipating: other international keyboards may have different keyboard layouts. Should be now add "CTRL ;" to the list of options for "zoom in"? This is a rhetorical question, my answer is obviously "NO".

Note also that the current documentation of OPTION_SIMPLE_ZOOM_SHORTCUT is not correct or at the very least misleading (citation):

"When the keyboard in use has '+' in the shifted position of its key, pressing that key and ctrl triggers the zoom-in operation."

As we can see this is not true for the JIS keyboard because the code allows this extra option only if the key in question is '=', i.e. if '+' is in the shift position on the '=' key and no other key.

All that said, I have nothing actually useful to offer...

Besides fixing the wrong Fl::event_key() and Fl::event_text() values on different platforms the only proper solution would IMHO be to add an easy way to let users configure the zoom/scale shortcuts they want. Then the user (app programmer) would be responsible to resolve this mess for all keyboard layouts.

Currently we can only switch the zoom/scale option entirely off. I'll work on a better way and propose (or push) a patch later...

[Albrecht Schlosser]

On 3/5/24 16:32 'Albrecht Schlosser' wrote:
> To be clear: I'm testing with test/keyboard.cxx as *THE* reference on
> Linux. This looks like the "best" implementation so far but maybe it's
> not correct in all cases. Different international keyboards may have
> an unclear impact.

To clarify further: you need commit
4c0a2ffb8159f58d1f9f0b5298770deff874895e (Tue Mar 5 03:08:30 2024 +0100)
to (re-)enable zooming in the test/keyboard app.

Another (less usable) option is test/handle_events.cxx which needs
improvements to output keyboard shortcuts (Fl::event_key() and
Fl::event_text()) in a better format. I'll probably work on this as well...

[Daniel Harding]

FTR I completely agree with Albrecht's analysis and conclusions.

[Manolo]

I would just like to stress, even if it's present also in Albrecht's analysis, that this new issue is independent from the GUI scaling mechanism. It's in how FLTK's Windows platform processes keystrokes with Ctrl and a non-alphabetic key. I can add that there is also an issue under FLTK+Windows with 'Ctrl+digit' keystrokes for Fr keyboards that have numbers in the uppercase position of their key. 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.

[Manolo]

About whether apps such as Firefox know the keyboard layout in use.

At least under macOS, I think they don't need that, because macOS itself provides support:

it sends two events to the app (⌘= followed by ⌘+) from a single press  of ⌘ and the '=|+' key without pressing shift.

macOS does that specifically for that key. For example, pressing ⌘ and the key labelled with ';|.'  doesn't send 2 events to the app.

I didn't check what happens with Japanese keyboards. Does it send ⌘; followed by ⌘+ ?

[Albrecht Schlosser]

On 3/5/24 19:54 Manolo wrote:
> I would just like to stress, even if it's present also in Albrecht's
> analysis, that this new issue is independent from the GUI scaling

> mechanism.It's in how FLTK's Windows platform processes keystrokes

> with Ctrl and a non-alphabetic key.

Yes, I agree.

> I can add that there is also an issue under FLTK+Windows with
> 'Ctrl+digit' keystrokes for Fr keyboards that have numbers in the
> uppercase position of their key.

Well, that's a similar issue.

My research on Windows did unfortunately not yield an usable result. It
looks like Windows provides first a keydown event with a "scan code"
which is the "physical" key number (location). In the second stage
(message) Windows gives us a "translated" value which is fine for all
printable ASCII and Unicode characters. This can be used to put the
value in Fl::event_text(). This works also for CTRL combined with letter
keys. So far, so good.

However, 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...

These MS docs are really confusing, and "simple" tests result in more
and more questions. I'm close to giving up.

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!

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

[Manolo]

Le mardi 5 mars 2024 à 21:50:41 UTC+1, Albrecht-S a écrit :

 ……

> 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 X11, that's in file src/Fl_x.cxx, function fl_handle(const XEvent&) lines 1879ff

    // Special processing for number keys == keycodes 10-19

For Wayland, that's in file src/drivers/Wayland/Fl_Wayland_Screen_Driver.cxx,

function process_wld_key(), lines 535ff

  // special processing for number keys == keycodes 10-19 :

[Albrecht Schlosser]

On 3/5/24 21:50 Albrecht Schlosser wrote:

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

I'm still looking for a clean and system conformant way to get the correct key information. Any help would be appreciated.

However, I made progress: I found the culprit of the inconsistent key codes on Windows!

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, and this table is based in large parts on Windows' "virtual key codes" (for all function keys, letter keys, etc.) which is good but there is another much smaller part (11 non-letter key codes) that translates key codes to key symbols like '+', '-', ';', etc. - and this part of the table uses the US/UK keyboard layout unconditionally! This is the reason why (some) ctrl/X combos (for X = non-letter keys) worked, mainly on US/UK keyboards but not on other keyboards.

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

[Albrecht Schlosser]

On 3/6/24 17:51 Albrecht Schlosser wrote:

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.

Don't bother, problem solved!

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

GOOD NEWS: Finally I found the solution. It's kinda tricky but I can now get the desired key info with a Windows function even for ctrl/+ etc. independent of the keyboard layout - both with and w/o the shift key and w/o hard-coded translation tables. Phew, that was hard (Windows) stuff.

This will eventually enable FLTK to get the correct Fl::event_key() and Fl::event_text() information we were missing in the current code. My code still needs cleanup and I need to determine when to call which function, but I'm now sure it will work. I'll let you know about my progress, probably tomorrow.

[Daniel Harding]

Awesome! Look forward to seeing it. Nice work.

[melcher....@googlemail.com]

I think that VkKeyScanEx can convert a '+' into the key combination that needs to be pressed:

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-vkkeyscanexa

You can also run all possible key codes and have WIN32 return the associated ASCII text (GetKeyNameText)

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getkeynametexta