Bug 158112 - Sidebar pane shortcuts conflict with Alt+NumPad input (comment 5, comment 9)
Summary: Sidebar pane shortcuts conflict with Alt+NumPad input (comment 5, comment 9)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.6.2.1 release
Hardware: All Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:24.8.0 target:24.2.1
Keywords:
: 158111 158201 158351 158490 158772 158786 158829 158967 159055 159226 159310 159389 159524 159674 159798 (view as bug list)
Depends on:
Blocks: Sidebar-UI-UX 156443
  Show dependency treegraph
 
Reported: 2023-11-08 08:31 UTC by perko.jernej
Modified: 2024-02-20 15:59 UTC (History)
24 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description perko.jernej 2023-11-08 08:31:33 UTC
Description:
Cell display and cell preview window do not match.

Steps to Reproduce:
1. Open new LibreOffice Calc document
2. Write in any cell any character and follow it with space (example: "Something ")
3. Press enter to confirm cell
4. Append to that same cell character '°' (AltGr + 5)
5. Press space
6. In cell it is now displayed "Something °SUM(Število)", with "Število" being highlighter (selected)
7. "SUM(Število)" is not desired in this case so try to delete it by pressing backspace
8. In cell it is currently visible "Something °SUMŠtevilo)" and in cell preview window it is shown "Something °SUM()"

Actual Results:
In cell it is currently visible "Something °SUMŠtevilo)" and in cell preview window it is shown "Something °SUM()"

Expected Results:
I excpected that cell view and preview windows would match.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Note that I edited the cell in preview window. It appears that if editing cell directly problem doesn't occur.

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (sl_SI); UI: sl-SI
Calc: CL threaded
Comment 1 Buovjaga 2023-11-13 17:45:57 UTC
So this SUM(Število) is just supposed to appear out of nowhere? I don't reproduce.

What if you deactivate Tools - Options (LibreOffice - Preferences on macOS) - LibreOffice - View - Use Skia for all rendering?

A screen recording would be nice, you can use something like https://obsproject.com/

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the information.
Comment 2 Buovjaga 2023-11-13 17:57:21 UTC
Ok, now I get it. Alt+5 on the NumPad could insert some ASCII character, but it is also the shortcut for the Functions pane of the Sidebar (just like 1 to 4 for the other panes). I see that this can be distracting.

For now, you could use another way: type the hexadecimal code for the character and press Alt+X. For ° it would be B0. You can discover the codes from Insert - Special Character.

But bug 156443 says that Alt+NumPad is not really supported yet. Let's alert UX team.
Comment 3 Buovjaga 2023-11-13 17:57:30 UTC
*** Bug 158111 has been marked as a duplicate of this bug. ***
Comment 4 raal 2023-11-13 22:14:07 UTC
*** Bug 158201 has been marked as a duplicate of this bug. ***
Comment 5 V Stuart Foote 2023-11-14 00:04:54 UTC
When implemented the accelerators for Sidebar Decks were <Ctrl>+<Alt>+[1-9] as for bug 84502

Due to complaints of AltGr <==> <Ctrl>+<r-Alt> interference with localizations, the Sidebar Deck accelerators/shortcuts were changed to just <Alt>+[1-9] by Caolán for bug 151059 [1]

Couldn't We restore the <Ctrl>+<Alt> but adjust the keysym mapping to adjust the MOD2 modifier to distinguish between l-Alt and r-Alt for continued AltGr os emulation? But gain more explicit control over the accelerator/shortcut assignments.

Otherwise, LibreOffice is Unicode focused by HEX value including our <Alt>+X and Special Character Dialog/CharMap handling--are we really obliged to support MS ASCII/OEM "AltCode" [2] handling?  IMHO past time to dump that legacy Win crud, which MS has deprecated. 

=-ref-=
[1] https://gerrit.libreoffice.org/c/core/+/155831
[2] https://en.wikipedia.org/wiki/Alt_code
Comment 6 ady 2023-11-18 23:08:07 UTC
(In reply to V Stuart Foote from comment #5)
> are we really obliged to
> support MS ASCII/OEM "AltCode" [2] handling?

Please be aware that users that need to insert characters that are not included in their keyboard layout might be using these type of shortcuts. One typical scenario is users inserting characters of other/multiple languages (such as accented letters/vowels while using a US keyboard).

When such needs are sporadic, other methods of inserting foreign characters are available. OTOH, when such needs are (very) frequent, users might even remember/memorize such keyboard shortcuts.
Comment 7 Heiko Tietze 2023-11-23 09:41:26 UTC
We discussed the topic in the design meeting.

An idea to solve the problem is to use alt+shift+<num>. Or to remove the default shortcuts, and make it available for customization. This means a considerable effort and could be detrimental to a11y (no default). 

Sidenote: ctrl+alt+<num> is available for customization but should not.
Comment 8 V Stuart Foote 2023-11-24 19:03:10 UTC
*** Bug 158351 has been marked as a duplicate of this bug. ***
Comment 9 V Stuart Foote 2023-11-24 19:15:59 UTC
Mike K. proposes a potential numberpad scancode solution in see also bug 156443
Comment 10 Buovjaga 2023-12-02 19:13:06 UTC
*** Bug 158490 has been marked as a duplicate of this bug. ***
Comment 11 xordevoreaux 2023-12-02 22:40:22 UTC
If I can use alt codes in the REST of the windows interface across multiple programs, I should be able to in LibreOffice, and, until recently, I COULD.

Restore this functionality.
Comment 12 xordevoreaux 2023-12-02 23:09:00 UTC
I always thought based on Windows issues cropping up that weren't on Linxus and devs at Document Foundation were completely biased against windows, and now I know...

"IMHO past time to dump that legacy Win crud, which MS has deprecated."
Comment 13 xordevoreaux 2023-12-02 23:17:29 UTC
I'm not seeing deprecation for alt codes in Windows.

https://learn.microsoft.com/en-us/windows/whats-new/deprecated-features

Was there a particular source that you were reading?

Windows.Crud.Com?
Comment 14 V Stuart Foote 2023-12-03 01:16:28 UTC
(In reply to xordevoreaux from comment #13)
> I'm not seeing deprecation for alt codes in Windows.
> 
> https://learn.microsoft.com/en-us/windows/whats-new/deprecated-features
> 
> Was there a particular source that you were reading?
> 
> Windows.Crud.Com?

The Wikipedia article gives the history [1].

Deprecated when Microsoft implemented the "EnableHexNumpad" registry string value and opened the entire Unicode for use moving MS Windows beyond limitations of localized code pages.

Nothing biased against Windows, the project is cross platform and Unicode centric with extensive ICU lib based handling rather than native Windows os/DE.

Our Unicode toggle (<Alt>+x) and Special Character dialog provide consistent UI cross platform.

=-ref-=
[1] https://en.wikipedia.org/wiki/Alt_code
Comment 15 Mike Kaganski 2023-12-03 08:37:50 UTC Comment hidden (off-topic)
Comment 16 V Stuart Foote 2023-12-08 16:01:10 UTC
*** Bug 158351 has been marked as a duplicate of this bug. ***
Comment 17 V Stuart Foote 2023-12-19 13:03:36 UTC
*** Bug 158772 has been marked as a duplicate of this bug. ***
Comment 18 V Stuart Foote 2023-12-20 01:23:27 UTC
*** Bug 158786 has been marked as a duplicate of this bug. ***
Comment 19 libretist 2023-12-20 02:50:03 UTC
The bug is much easier to reproduce in Writer, see bug 158786
Comment 20 ady 2023-12-20 15:34:03 UTC
The amount of dupes will keep increasing with time, because the method is very popular (and certainly not deprecated from the POV of users) in certain cases as mentioned in comment 6.

Since these popular shortcuts were ignored when the conflicting shortcuts were introduced, we could infer that:
* newly proposed (or changes of) shortcuts in LO are not evaluated as consciously/deeply/broadly as they might need to; and
* knowledge or awareness of these specific (popular) shortcuts is/was not (completely) understood nor investigated nor tested (as they should, at least once).

So, FYI and JIC:

* The relevant shortcuts (in MS Windows at least) are (exclusively):
 [ALT]+[Numbers in the Numeric Pad]

* Regarding the amount of digits for the shortcuts, using 3 digits (from the NumPad) is not the same as using 4 digits (from the NumPad). For instance, [ALT]+([1]-[2]-[3]) does not introduce the same character as [ALT]+([0]-[1]-[2]-[3]).

* Numbers in the upper row of the normal keyboard are _not_ equivalent in terms of these shortcuts

* [AltGr] is _not_ equivalent in terms of these shortcuts; they work with [ALT]

* Other combination of special keys are not supposed to be equivalent, but some software aimed at accessibility-needs might interpret some other combination of keys, or some "gesture", as equivalent to [ALT]. Other software (or hardware) might use some alternative keys in order to "fake" the Numeric Pad when the real keyboard does not include a real one.

* Regarding the amount of digits for the shortcuts, using 3 digits (from the NumPad) is not the same as using 4 digits (from the NumPad). For instance, [ALT]+([1]-[2]-[3]) does not introduce the same character as [ALT]+([0]-[1]-[2]-[3]).
Comment 21 V Stuart Foote 2023-12-20 19:13:59 UTC
@Mike's suggestion in bug 156443 of logging the key input between <Alt>'s KEYDOWN and KEYUP and parsing that value would allow continued handling of the SB shortcuts as <Alt>+[1-9], and to keep the MS Win Alt codes, and likewise the extended Unicode NumPad Alt codes with "EnableHexNumpad" Windows registry enabled.
Comment 22 libretist 2023-12-20 22:52:05 UTC
(In reply to V Stuart Foote from comment #21)
> @Mike's suggestion in bug 156443 of logging the key input between <Alt>'s
> KEYDOWN and KEYUP and parsing that value would allow continued handling of
> the SB shortcuts as <Alt>+[1-9], and to keep the MS Win Alt codes, and
> likewise the extended Unicode NumPad Alt codes with "EnableHexNumpad"
> Windows registry enabled.

Can Mike's suggestion distinguish between ALT+7 as a LibreOffice shortcut and ALT+7 as input for the bullet point sign "•" in Windows ?
(see here: https://bugs.documentfoundation.org/show_bug.cgi?id=156443#c4 )
If not, then it doesn't seem like a good suggestion to me.
Comment 23 Mike Kaganski 2023-12-22 10:47:10 UTC
*** Bug 158829 has been marked as a duplicate of this bug. ***
Comment 24 libretist 2023-12-27 04:22:35 UTC
(In reply to V Stuart Foote from comment #14)
> (In reply to xordevoreaux from comment #13)
> > I'm not seeing deprecation for alt codes in Windows.
> > […]
> 
> The Wikipedia article gives the history [1].
> Deprecated […]
>  
> [1] https://en.wikipedia.org/wiki/Alt_code

I don't see anything about deprecation in this link.

I agree with comment #20
> The amount of dupes will keep increasing with time, because the method is
> very popular (and certainly not deprecated from the POV of users)
Comment 25 libretist 2023-12-28 18:53:58 UTC
"component" should probably be changed from "Calc" to something broader (maybe "LibreOffice"??)
since this bug is not limited to Calc but also affects Writer
Comment 26 Mike Kaganski 2024-01-02 10:50:57 UTC
*** Bug 158967 has been marked as a duplicate of this bug. ***
Comment 27 Alexander Berg 2024-01-05 13:52:41 UTC
Often you are assigned to a different thread because the topic may be duplicate. The issue of “Alt+numbers” could possibly be solved in this way: Leave the convenient Alt+numbers function. Everyone who wants to choose special characters from a list is free to do so, likewise the input of unicodes. Let's see why "ctrl+F5" (official) and "Alt+1" open the attribute window even though "Alt+1" is not defined.
Comment 28 Mike Kaganski 2024-01-10 14:15:23 UTC
https://gerrit.libreoffice.org/c/core/+/161891 for tdf#156443 will fix this - by completely disabling Alt+NumPad shortcuts, allowing only Alt+Numbers from main keyboard area. Basically, what V Stuart Foote suggested (even though I disliked the idea initially).

Please shout if the last point (disabling Alt+NumPad) is concerning.
Comment 29 Mike Kaganski 2024-01-10 14:53:58 UTC
Forgot to mention, that the change referenced above is Windows-specific. It will not affect any other OS.
Comment 30 Alexander Berg 2024-01-10 15:12:52 UTC
Luckily only Windows is affected. But then I'm happy. Sarcasm doesn't really help, but it seems sensible to simply undo the program adjustments.
Comment 31 Commit Notification 2024-01-10 16:39:53 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/772da0f1aa6891a0b31d45d99a5978c65ed24e34

tdf#156443, tdf#159079, tdf#158112: support Windows Alt codes >=256

It will be available in 24.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 32 V Stuart Foote 2024-01-11 15:39:42 UTC
(In reply to Commit Notification from comment #31)
> 
> https://git.libreoffice.org/core/commit/
> 772da0f1aa6891a0b31d45d99a5978c65ed24e34
> 
> Affected users are encouraged to test the fix and report feedback.

Both flavors of Microsoft NumPad ALT codes, the "OEM" (1 to 3 digit codepage) and "ASCII" (4,5 decimal digits matching the Unicode BMP) [1], are restored.  While the <Alt>+[1-9] keyboard shortcuts remain available.

Pretty deliberate distinction in place, so think the UI will be acceptable while retaining current customization.

Thanks Mike!

@Seth, seems this divergence between the Windows Numpad ALT codes (both the "OEM" and "ASCII" for Unicode BMP) and the SB deck's <Alt>+[1-9] shortcuts (Windows only) now will need some mention in help/documentation.

=-Testing-=

With TB-78 nightly 20230111
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 3cb1ed4339fc9aec414c0f112a69705a7a4d9cc6
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL:
win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

=-ref-=
[1] https://en.wikipedia.org/wiki/Alt_code
Comment 33 Alexander Berg 2024-01-11 16:44:26 UTC Comment hidden (noise)
Comment 34 Mike Kaganski 2024-01-12 01:18:07 UTC
(In reply to V Stuart Foote from comment #32)
> "ASCII" (4,5 decimal digits matching the Unicode BMP)

Not only BMP. As explained in "Decimal input (Alt codes)" at [1], Alt + 120132 also works.

[1] https://en.wikipedia.org/wiki/Unicode_input#Decimal_input_(Alt_codes)
Comment 35 V Stuart Foote 2024-01-12 15:46:58 UTC
(In reply to Mike Kaganski from comment #34)
> (In reply to V Stuart Foote from comment #32)
> > "ASCII" (4,5 decimal digits matching the Unicode BMP)
> 
> Not only BMP. As explained in "Decimal input (Alt codes)" at [1], Alt +
> 120132 also works.
> 
> [1] https://en.wikipedia.org/wiki/Unicode_input#Decimal_input_(Alt_codes)

@Mike, *

Oh Cool! In addition to the whole BMP (not just the first 9999 as decimal), it also supports the full SMP--only rub is having to lookup/calculate the decimal values for the Unicode graphemes.

Fortunately LibreOffices charmap in the "Special Character..." dialog does list both Hex and Decimal values. Still, imagine the additional work to support the Windows "EnableHexNumpad" would be appreciated as HEX is so much more efficient for entry.

Also, I'd call this issue fixed, and worthy of back port.

Double thanks!
Comment 36 Commit Notification 2024-01-12 18:31:42 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/45023ae9619cdc4332afb8f743d1695a23e8d866

tdf#156443, tdf#159079, tdf#158112: support Windows Alt codes >=256

It will be available in 24.2.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 37 Buovjaga 2024-01-18 18:37:16 UTC
*** Bug 159055 has been marked as a duplicate of this bug. ***
Comment 38 Buovjaga 2024-01-21 14:01:25 UTC
*** Bug 159310 has been marked as a duplicate of this bug. ***
Comment 39 ady 2024-01-24 05:07:01 UTC
*** Bug 159226 has been marked as a duplicate of this bug. ***
Comment 40 V Stuart Foote 2024-01-26 20:28:20 UTC
*** Bug 159389 has been marked as a duplicate of this bug. ***
Comment 41 Tracey 2024-01-27 17:39:40 UTC
Whenever I enter accented characters via <alt>+num-pad, I always seem have to prefix the "number" with a zero (¿4 digit numbers?)
I do NOT know if this is required or not.

If this is so for all accented characters using this method, can the short-cut to the right side-bar only be triggered when the whole numerical entry is only a single digit (¿1 thru 9?) and all others are used to enter a character?

Please advise.
Thanks, Tracey
Comment 42 V Stuart Foote 2024-01-27 20:50:40 UTC
The fix at 24.2.1 and 24.8.0 splits the LibreOffice UI shortcuts assigned for SB decks from the MS Windows decimal Alt codes using the Numpad keys.

The <Alt>+[1-9] (with keyboard numbers) assigned to the SB decks are now distinct from the <Alt>+[1-9] (with numpad numbers) restoring these MS "OEM" decimal Alt codes (those from 1-256):

<Alt> + VK_NUMPAD1 --> ☺ WHITE SMILING FACE (Unicode U+263A)
<Alt> + VK_NUMPAD2 --> ☻ BLACK SMILING FACE (Unicode U+263B)
<Alt> + VK_NUMPAD3 --> ♥ BLACK HEART SUIT (Unicode U+2665)
<Alt> + VK_NUMPAD4 --> ♦ BLACK DIAMOND SUIT (Unicode U+2666)
<Alt> + VK_NUMPAD5 --> ♣ BLACK CLUB SUIT (Unicode U+2663)
<Alt> + VK_NUMPAD6 --> ♠ BLACK SPADE SUIT (Unicode U+2660)
<Alt> + VK_NUMPAD7 --> • BULLET (Unicode U+2022)
<Alt> + VK_NUMPAD8 --> ◘ INVERSE BULLET (Unicode U+25D8)
<Alt> + VK_NUMPAD9 --> ○ WHITE CIRCLE (Unicode U+25CB)

Additionally the full range of MS decimal "OEM" Alt codes, as well as the decimal MS "ANSI" alt codes (e.g. those starting with "0") are available. With an enhancement that the entire Unicode Basic Multiplane (BMP) and Supplemental Multiplane (SMP) can be entered now via decimal Alt code.

A future enhancement to handle Alt code entry via HEX and the MS Windows "EnableHEXNumpad" registry value has been suggested.
Comment 43 Buovjaga 2024-02-02 15:38:47 UTC
*** Bug 159524 has been marked as a duplicate of this bug. ***
Comment 44 Tracey 2024-02-07 17:52:53 UTC
writer: <alt>+nnnn(numpad) opens side-bar :-(, but does NOT enter character :-(
calc: <alt>+nnnn(numpad) opens side-bar :-( ---AND--- enters character :-)

#1 I would like the side-bar to NOT appear when entering a multi-digit number (both writer and calc fail).
#2 I would like the nnnnn character to be entered (writer fails).

Thanks, Tracey

Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 45 ady 2024-02-07 19:09:03 UTC
(In reply to Tracey from comment #44)

> Version: 24.2.0.3 (X86_64) / LibreOffice Community

Please read carefully the posts. The patch is expected to be part of 24.2.1 (emphasis on the 3rd number, "1", not "0"). Alternatively, test with a Dev version.
Comment 46 John van Someren 2024-02-07 19:18:19 UTC
Thanks for the speedy fix (not that I've had a chance to test it). However, Comment 44 only mentions the locale as EN-US. Will I have to wait for a later release for it to work in British English?
Comment 47 V Stuart Foote 2024-02-07 22:22:05 UTC
(In reply to John van Someren from comment #46)
>... Will I have to wait for a
> later release for it to work in British English?

No, just the 24.2.1.2 rc2 release build,  week of ~19 Feb.

The behavior is locale neutral, at 24.2.1 it will work with what ever Alt+Numpad the MS os/DE provides per locale.
Comment 48 Buovjaga 2024-02-10 13:37:21 UTC
*** Bug 159674 has been marked as a duplicate of this bug. ***
Comment 49 Mike Kaganski 2024-02-20 15:59:13 UTC
*** Bug 159798 has been marked as a duplicate of this bug. ***