Summary: | Windows: alt+numpad doesn't work for Unicode decimal codes, like in WordPad/Word | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Mike Kaganski <mikekaganski> |
Component: | LibreOffice | Assignee: | Mike Kaganski <mikekaganski> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | buzea.bogdan, himajin100000, mentoring, m.weghorn, quentin, sky, tobias, vitaliy.a.timoshenko, vsfoote |
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Windows (All) | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=151059 https://bugs.documentfoundation.org/show_bug.cgi?id=159079 https://bugs.documentfoundation.org/show_bug.cgi?id=158112 https://bugs.documentfoundation.org/show_bug.cgi?id=150511 |
||
Whiteboard: | target:24.8.0 target:24.2.1 | ||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | 158112 | ||
Bug Blocks: |
Description
Mike Kaganski
2023-07-24 13:35:22 UTC
+1 This depends on bug 158112, because until the conflict with shortcuts is resolved, implementing the proposal is not realistic. @Mike, isn't the trigger on Windows the Keyup release of the <Alt> key. So we could isolate and continue to use the <Alt>+[1-9] shortcuts for the SB decks, exactly as you suggest? How would your proposed method distinguish between ALT+7 as a LibreOffice shortcut and ALT+7 as input for the bullet point sign "•" in Windows ? (In reply to Mike Kaganski from comment #0) > 2. When Alt key's WM_KEYUP arrives, analyze the stored sequence, and decide > if it's Unicode (i.e., if it starts with [0] or is greater than 255) or not. > 3. If it's non-Unicode, just drop the sequence, and process the following > WM_CHAR as before. Many characters I regularly insert via ALT+numbercode are not handled by your method: ALT+7 = • ALT+3 = ♥ ALT+11 = ♂ ALT+12 = ♀ ALT+16 = ► ALT+24 = ↑ ALT+25 = ↓ ALT+26 = → ALT+27 = ← ALT+128 = Ç AKT+135 = ç ALT+145 = æ ALT+146 = Æ ALT+152 = ø ALT+156 = £ ALT+157 = Ø ALT+168 = ¿ ALT+171 = ½ ALT+172 = ¼ ALT+174 = « ALT+175 = » ALT+184 = © ALT+241 = ± ALT+243 = ¾ ALT+246 = ÷ ALT+251 = ¹ ALT+252 = ³ ALT+253 = ² (In reply to libretist from comment #5) Do you really understand what this issue is about? The non-Unicode (lower numbers) codes were already working using the normal WM_CHAR method ("as before"). Please avoid commenting without understanding the technical background. (In reply to Mike Kaganski from comment #6) > (In reply to libretist from comment #5) > > Do you really understand what this issue is about? The non-Unicode (lower > numbers) codes were already working using the normal WM_CHAR method ("as > before"). Please avoid commenting without understanding the technical > background. That's funny. One doesn't know what one doesn't know. Of course I thought I understood your suggestion. Otherwise I wouldn't have commented, obviously. But if I got something wrong, please explain why/what. Thank you. (In reply to libretist from comment #7) The proposal here is based on the status *prior* to bug 158112. You may recall, that you wrote bug 158786 as a "regression": before the assignment of Alt+Number to sidebar panels, you could normally use the ALT+168 combination, and get what you expected. As explained in comment 0, the *combinations starting with 0 or greater than 255* weren't processed correctly. Values below 256 were processed using Windows WM_CHAR message, which contains a resulting character value, but only truncated. So the whole text there discussed how to enable *also* greater values. Then comment 3 (not mine) could confuse people, because it suggested this proposal as a "solution" to bug 158112 (which is it not, and can't be). As you noted in bug 158112 comment 22, even Alt+single_digit is a useful special character combination. But in any case, before writing things like "Many characters ... are not handled by your method", one needs to make sure they understand what they object to. But don't the VK_NUMPAD[0-9] emit different scancodes to the VK_[0-9]? Hex values (and decimal) of 0x60 -- 0x69 (96-105), 0x30 -- 0x39 (48-57) respectively. [1][2] Also the loworder (1-254) "OEM" and 4-digit "ANSI" (dec 0032-0255 matching Unicode BMP) MS Alt keys *only* work for the NUMPAD keys? So on Windows builds the SB shortcuts in fact could still use the <Alt>+[1-9] and leave the Alt+NUMPAD[0-9] for os/DE use. The 'EnableHexNumpad' flavor ALT codes maybe needing a bit more handling, but by that point our <Alt>+x toggle already services Unicode centric users. =-ref-= [1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-tvtt/261ddfb0-ce10-4380-9b7a-4b50f482b8ec [2] https://learn.microsoft.com/en-us/windows/win32/inputdev/virtual-key-codes (In reply to V Stuart Foote from comment #9) > But don't the VK_NUMPAD[0-9] emit different scancodes to the VK_[0-9]? Hex > values (and decimal) of 0x60 -- 0x69 (96-105), 0x30 -- 0x39 (48-57) > respectively. [1][2] Indeed. We are able to disambiguate ~all keys on keyboard. If wanted, we can also keep the numpad numbers for Alt-extended characters, and other numbers for shortcuts. This still requires fixing bug 158112 (e.g., exactly this way: making Alt+Number shortcuts only work for non-numpad numbers) first, as I explained in comment 3. > The 'EnableHexNumpad' flavor ALT codes maybe needing a bit more handling, > but by that point our <Alt>+x toggle already services Unicode centric users. EnableHexNumpad may be a separate issue, if needed. I mentioned it here, but with a note that "a follow-up enhancement could be filed for that". So it may be excluded from consideration here. However, I would think that Alt+NonNumpadNumber shortcut would still be confusing. Also, listing the Alt+Number in customization provokes for using it; and people who will try will *mostly* complain that it doesn't work: they would expect numpad numbers to do what they expect from the shortcut, and see it doesn't (because it would be used for Alt+Numpad Number extended character function). I am strongly in favor of removing Alt+Number as an assignable key combination on Windows, completely. (In reply to Mike Kaganski from comment #10) > I am strongly in favor of removing Alt+Number as an assignable key > combination on Windows, completely. OK, not opposed, other than normal cross-platform documentation issues. So back to resolving bug 158112 and my suggestion about returning to the <Ctrl><Alt>+[1-9], but to avoid bug 151059 by adjusting to handling for <AltGr> <==> <Ctrl><Alt> needed for os/DE VK_MENU mapping when missing <AltGr> keyboards. Distinguishing between l-Alt and r-Alt modifier key scancodes could be an approach on several issues. But treacherous as we'd already tried similar for bug 95761 (Jurgen's work) [1] to normalize the <Alt>+[x|c]Unicode toggle [2] and that had gotten messy and had to be reverted for bug 97908. =-ref-= [1] https://gerrit.libreoffice.org/19923 [2] Justin's implementation on bug 73691 (In reply to Mike Kaganski from comment #8) sorry for my misunderstanding https://gerrit.libreoffice.org/c/core/+/161891 Since it affects a number of issues, I decided to handle this myself. This will also fix tdf#159079. Also, this will fix tdf#158112 - 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. 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. (In reply to Mike Kaganski from comment #13) > https://gerrit.libreoffice.org/c/core/+/161891 > > Since it affects a number of issues, I decided to handle this myself. > This will also fix tdf#159079. > Also, this will fix tdf#158112 - 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. On track, but could be an accessibility issue with the Numlock override of the NumPad scancodes. The NVDA assistive technology extensively uses the NumPad for program controls. If LO interferes with that, it could be a major annoyance for that group of users. Michael W., any perspective? (In reply to V Stuart Foote from comment #15) > The NVDA assistive technology extensively uses the NumPad for program > controls. If LO interferes with that, it could be a major annoyance for that > group of users. > > Michael W., any perspective? I don't know the details of how this works on Windows, but I think that screen readers intercept keyboard events *before* they get sent to the application, while Mike's change from a quick look only changes the handling inside of LO, in which case I wouldn't expect any problems. I won't have access to a keyboard with a Num block before Tuesday, but if somebody has, a quick test whether e.g. the NVDA+numpad5 command to report the current object still works might be useful when the desktop layout is used for NVDA ("Preferences" -> "Settings" -> "Keyboard" -> "Keyboard layout"). Doc: https://www.nvaccess.org/files/nvda/documentation/userGuide.html#ObjectNavigation CC'ing Quentin, who might have further insights regarding NVDA. (In reply to Michael Weghorn from comment #16) > I won't have access to a keyboard with a Num block before Tuesday, but if > somebody has, a quick test whether e.g. the NVDA+numpad5 command to report > the current object still works might be useful when the desktop layout is > used for NVDA ("Preferences" -> "Settings" -> "Keyboard" -> "Keyboard > layout"). So seems to be no issues, the default NVDA key (Numpad 'Ins' key) continues to function. With default NVDA key of the numpad Insert, "NVDA+n" and "NVDA+<NumPad_5>" both behaved with expected NVDA responses. =-Testing-= Win10 (22H2 19045) NVDA Version: 2023.3 (2023.3.0.29780) 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 (In reply to V Stuart Foote from comment #17) > So seems to be no issues, the default NVDA key (Numpad 'Ins' key) continues > to function. > > With default NVDA key of the numpad Insert, "NVDA+n" and "NVDA+<NumPad_5>" > both behaved with expected NVDA responses. Great, thanks for testing! All should be fine then from what I can say. 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. *** Bug 59400 has been marked as a duplicate of this bug. *** |