Bug 159230 - Shortcuts are not available for Find and replace dialog in Mac
Summary: Shortcuts are not available for Find and replace dialog in Mac
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.5.9.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: accessibility
: 152379 (view as bug list)
Depends on:
Blocks: Shortcuts-Mac
  Show dependency treegraph
 
Reported: 2024-01-16 19:24 UTC by Daniele
Modified: 2024-02-12 07:10 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of dialogue with letters not underlined (46.48 KB, image/png)
2024-01-16 19:24 UTC, Daniele
Details
Find & Replace drop-down menu (54.74 KB, image/png)
2024-01-18 16:23 UTC, Daniele
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniele 2024-01-16 19:24:11 UTC
Created attachment 192003 [details]
Screenshot of dialogue with letters not underlined

Hi, shortcuts are not available for Find and replace dialog in Mac (letters in options are not underlined).
It seems that other Os have them.
Could you please implement this feature in Mac too?

Version: 7.5.9.2 (AARCH64) / LibreOffice Community
Build ID: cdeefe45c17511d326101eed8008ac4092f278a9
CPU threads: 8; OS: Mac OS X 14.2.1; UI render: default; VCL: osx
Locale: es-ES (en.UTF-8); UI: en-US
Calc: threaded
Comment 1 steve 2024-01-16 20:27:17 UTC
In which dialog are you seeing underlined letters on macOS? Can you share a screenshot?
Comment 2 Daniele 2024-01-17 08:57:59 UTC
Hi steve,
I am not seeing any underlined letters in any dialog actually.

What I meant is that other Os such as Linux have them (see anonanon73440385 screen recording in this thread: https://ask.libreoffice.org/t/find-replace-not-working/60260/2).

So I wondered if the Mac OS release could have this feature implemented too.

And I was referring to the Find and Replace dialogue since there repetitive work is usually done.
Comment 3 steve 2024-01-17 13:52:41 UTC
I don't think it is a good idea for LO to deviate from standard OS behavior.
Adding keyword: needsUXEval
Comment 4 Daniele 2024-01-18 16:23:06 UTC
Hi Steve,
I see your point now. Actually I must have been mixed up when using a Linux computer for some time to do my work. I thought that it was a feature once available in Mac Os.

However it would be really useful to have the shortcuts already created for the users and made available in a simple and intuitive way.

Having underlined letter may not be the case as it would not meet MacOs users expectations.

Some other way would nonetheless be really helpful: either in the drop-down menu, as a subsection (>) of Find & Replace (see attachment) or in the Find & Replace window itself as a checkable option (show shortcuts for example), or in another intuitive place (available shortcuts?).
Comment 5 Daniele 2024-01-18 16:23:43 UTC
Created attachment 192038 [details]
Find & Replace drop-down menu
Comment 6 Heiko Tietze 2024-01-22 12:38:22 UTC
We follow the system settings, and under Linux the kf5 VCL always shows mnemonics while gtk3 only when Alt is pressed. MacOS has deprecated mnemonics for some reason, see https://developer.apple.com/documentation/appkit/nscell/1560878-mnemonic.

Now I wonder if we can show/provide them anyway. What do you think, Caolan and Patrick?
Comment 7 Patrick Luby (volunteer) 2024-01-22 14:33:51 UTC
(In reply to Heiko Tietze from comment #6)
> Now I wonder if we can show/provide them anyway. What do you think, Caolan
> and Patrick?

Hate to be the bearer of bad news, but macOS has reserved most Option+key combinations for input methods. Even in the US QWERTY input method, nearly every Option+key is transformed into a Unicode character key press event before LibreOffice gets the event.

Also, Control+key is reserved for many system functions and input method features.

This is one of the main reasons why almost no applications (even Apple's own applications) do not implement Windows style mnemonics.

In theory, maybe there are some combination of keys that aren't reserved by macOS, but in my quick review with US QWERTY and Japanese - Kana input methods as well as Apple's list of standard system shortcuts (see link below):

https://support.apple.com/en-us/HT201236
Comment 8 Heiko Tietze 2024-01-22 15:02:12 UTC
(In reply to Patrick Luby from comment #7)
> macOS has reserved most Option+key combinations for input methods
So even showing the mnemonics by default wont work. => WF, actually NOB
Comment 9 Patrick Luby (volunteer) 2024-01-22 15:19:26 UTC
(In reply to Heiko Tietze from comment #8)
> So even showing the mnemonics by default wont work. => WF, actually NOB

Correct. A couple of examples for the bug filer and any other new macOS users switching from Windows:

1. Pressing Option+m on a US QWERTY keyboard (to check the "match case" checkbox in the Search and Replace dialog for example) passes a key input event with the "µ" Greek character.

2. Pressing Option-e on a US QWERTY keyboard passes a key input event with the "`" acute accent character. Then, pressing only a regular key such as "a" immediately after releasing Option-e, passes two key input events: backspace (to remove the acute accent) and a "á" character.

3. Interestingly, pressing Option-key with the Japanese - Kana keyboard passes Romaji (ASCII) characters.
Comment 10 Patrick Luby (volunteer) 2024-01-23 14:37:27 UTC
Maybe this helps, but Apple publishes the following support document:

https://support.apple.com/en-us/HT201236

By replacing /en-us/ with other language/country combinations (e.g. fr-fr, ja-jp) we can see the most common standard macOS key shortcuts.

FWIW, Command-H is in the same section as Command-C, Command-V, and Command-Q.

I just tested with English, French, and Japanese languages with Safari on macOS Sonoma with US QWERTY, French AZERTY, and Japanese - Kana and in all cases, Command-H hides Safari so maybe we can trust Apple's support document?
Comment 11 Mike Kaganski 2024-02-11 05:46:48 UTC
*** Bug 152379 has been marked as a duplicate of this bug. ***