It seems that starting from 6.3 series, the "Edit Fields" dialog (first create a field with Insert -> Field -> Date, then select the field and Edit -> Fields to open the dialog) added mnemonic keys to the buttons at the bottom (Help, OK, and Cancel). I'm guessing it started in 6.3 series because in 6.2.8 they don't have mnemonic keys, and in 6.3.4 they do. The "OK" button uses letter "O" for the mnemonic, however it clashes with the "Format" column that's already using "O". Now when I press Alt+O the focus goes to the OK button instead of the Format column as it used to. Since the "Format" column used "O" first, and it also exists in the Insert -> Field -> More Fields... dialog and maybe others, the "OK" button probably should yield and use "K" instead. Similarly, in the same dialog, the "Select" column, the "Offset in days" spinbox, and the "Edit" button all use "E" as mnemonic. But that's probably less problematic to users as those are less frequently accessed from keyboard. My "About LO" information: Version: 6.4.0.1 (x64) Build ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; Locale: zh-CN (zh_CN); UI-Language: en-US Calc: threaded
I confirm it with Version: 6.5.0.0.alpha0+ (x64) Build ID: e26d89371f0e4f41476c9a99be01d98dedb76776 CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-GB Calc: threaded
(In reply to Ming Hua from comment #0) > "OK" button probably should yield and use "K" instead. Highly unlikely. It comes from a "standard" form used across all the dialog boxes. How about F for Format? (which is currently assigned to Fixed content, which I could change to x). But notice that 'o' is also used with Format in the Field dialog (Ctrl-F2) -- because there is no OK there. (Also I think that Edit will not be active in this dialog box, so the 'e' should not conflict with the 'e' in Select.) Should we ask UX?
(In reply to sdc.blanco from comment #2) > (In reply to Ming Hua from comment #0) > > "OK" button probably should yield and use "K" instead. > Highly unlikely. It comes from a "standard" form used across all the dialog > boxes. That's unfortunate. To be honest I don't find the mnemonics for these standard buttons particularly useful (as I said in comment #0, this seems to be a new thing starting from 6.3.x series), and it's really annoying if they can't be overidden. > How about F for Format? (which is currently assigned to Fixed content, which > I could change to x). > > But notice that 'o' is also used with Format in the Field dialog (Ctrl-F2) > -- because there is no OK there. I'm indifferent to the eventual choice of the mnemonic character, as long as I can easily have access to the item I want from keyboard. On that note, I wonder if it's possible to have the first highlight choice when Alt+O pressed to be on the "Format" column instead of "OK" button... > (Also I think that Edit will not be active in this dialog box, so the 'e' > should not conflict with the 'e' in Select.) But surely the Edit button will be active in some cases (although I didn't find any in a few attempts)?
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7c54dfe7b8822cebd314347bb643ce61477095b1 tdf#129935 improve accelerator key choices for Edit Fields dialog It will be available in 7.1.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 Commit Notification from comment #4) > Affected users are encouraged to test the fix and report feedback. It seems to work for me now. T for Type, S for Select, F for Format, O for OK, etc. No conflicts, so I will close as FIXED. Reopen if new problems with accelerator keys appear.
Verified in: Version: 7.1.0.0.alpha1 (x64) Build ID: 987671387712c4f9061d6216ff2f001a7bb9e57b CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: zh-CN (zh_CN); UI: en-US Calc: threaded Thanks for the fix, Seth!