Created attachment 172926 [details] View menu with duplicate Hotkeys View menu - the same hotkeys for two items ("Toolbars" and "Show Tracked Changes"). Pressing "t" with "View" menu open leads to "Show Tracked Changes" and that is misleading, since the first "T" hotkey is underlined in item "Toolbars". Expected behavior: Either: - remove T from "Toolbars" Or: - assign another hotkey ("o" or "r") as "t" is reserved and we shouldn't break existing UX. Version: 7.1.4.2 Build ID: 10(Build:2) CPU threads: 16; OS: Linux 5.12; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
No repro Version: 7.1.4.2 / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Additional notes: - the key is "K" in above configuration - from the "Build ID: 10(Build:2)" it seems to be a distribution package specific issue
Repro Version: 7.1.4.2 (x64) / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 1; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: en-US (en_DE); UI: en-US Calc: threaded
repro in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: b89ebf135818ccaa45bbfb164099a6e199bd7d11 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded
That is acceptable, the "hot key" accelerator assignments are not expected to be unique. Sequence is <alt> -> v -> t, that opens the Toolbar menu. A cursor <left> closes the Toolbar menu and another t focuses to the Track Changes menu entry. Absolutely consistent and expected behavior. By long-standing project practices the accelerator assignments do not have to be unique.
Alt-V -> T runs "Show Tracked Changes" on my box. And that is NOT consistant as I see Toolbars with T underlined first
Created attachment 172950 [details] Animated GIF screen capture (via ShareX) of Writer 7.1.3.2 <alt> + V + T accelerator behavior Windows builds (In reply to Alexey Rubtsov from comment #5) > Alt-V -> T runs "Show Tracked Changes" on my box. And that is NOT consistant > as I see Toolbars with T underlined first Can not confirm. <Alt> + V + T opens the ~Toolbars submenu; an <esc> or <Left> cursor closes; a second T applies the ~Track Changes mode. screen capture attached. Version: 7.1.3.2 (x64) / LibreOffice Community Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
(In reply to V Stuart Foote from comment #6) > Can not confirm. <Alt> + V + T opens the ~Toolbars submenu; an <esc> or > <Left> cursor closes; a second T applies the ~Track Changes mode. > a second T focuses the ~Track Changes mode--would need a <Space>/<Enter> to toggle the mode. Only keys used in the screen clip <alt>, V, T, <left> / <esc> (which both close the sub menu).
(In reply to V Stuart Foote from comment #7) > (In reply to V Stuart Foote from comment #6) > > Can not confirm. <Alt> + V + T opens the ~Toolbars submenu; an <esc> or > > <Left> cursor closes; a second T applies the ~Track Changes mode. > > > > a second T focuses the ~Track Changes mode--would need a <Space>/<Enter> to > toggle the mode. > > Only keys used in the screen clip <alt>, V, T, <left> / <esc> (which both > close the sub menu). I've checked it again, it seems to be DE (framework) related issue. On Budgie and Gnome (GTK) it focuses on "Track Changes mode" and in KDE - Toolbars
Because of the submenu I'd change the shortcut in this case to C. Pressing an accelerator again is acceptable but when I have to close a submenu it becomes keyboard unfriendly. Code pointer: officecfg/registry/data/org/openoffice/Office/UI/WriterCommands.xcu old: <value xml:lang="en-US">Show ~Tracked Changes</value> new: <value xml:lang="en-US">Show Tracked ~Changes</value> But IIUC accelerators are assigned automatically, apparently by the OS/DE. Do you have any insights, Julian?
(In reply to Alexey Rubtsov from comment #8) > > I've checked it again, it seems to be DE (framework) related issue. On > Budgie and Gnome (GTK) it focuses on "Track Changes mode" and in KDE - > Toolbars That's weird. Would expect the Menus to behave consistently in sequnce handling the accelerators. A welding issue? Otherwise, changing the accelerator to remove the conflict is fine. I agree with Heiko. If we have the option to not duplicate accelerators for menu controls that open a submenu--we should not. That makes for better UX.
For the gtk case there's no weld related stuff wrt the toplevel menubar/menus. But it is a native gtk menubar(*) and for me the first "t" goes to "show _tracked change" and the second goes to "_toolbars". No idea why it picks which one to start at (not under our control I assume) but it does cycle between the two options on each "t" *) which should be similar to the mac case, on which is mostly based, where the mac menubar is the shared system menubar. Anyone know what happens on mac ?
(In reply to Caolán McNamara from comment #11) > Anyone know what happens on mac ? macOS has no mnemonics, no "alt"+hotkey. It's possible to put the focus on the menu bar and use the arrow keys, that's all.
On pc Debian x86-64 with master sources updated today, 1) with gen or kf5 rendering Alt-V opens View menu typing T opens "Toolbars" submenu (so with the pb already described) If close the submenu and menu and try again, I got the same. 2) with gtk3 rendering Alt-V opens View menu typing T opens "Show Tracked Changes" If I close the submenu and menu and try again, I got this time "Toolbars" If I close the submenu and menu and try again, I got this time "Show Tracked Changes" and so on. Interestingly, with gtk3, when LO "chooses" "Toolbars", it doesn't open submenu and so we can type again "T" to select "Show Tracked Changes" For the rest, I can't tell. Knowing that even if we solve the pb for en-US, each language can have this pb too since we must choose a letter present in the translated command ; I wonder how MsOffice deals with this.
Let's change the default anyway, even when it's not a solution for every environment.
Re-evaluating the EasyHack in 2022 This issue is still relevant. The accelerator (here referred as hotkeys) for these two menu items should become different.
Bogdan B committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/54ca50536e1c98f0bfe3b32d2a8c72668289e183 tdf#142888 Changing Tracked Changes accelerator It will be available in 7.5.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.