When opening and closing documents, I do everything from the keyboard. But with gtk3, you have to use the mouse to bring the close dialog into focus. Steps to reproduce: 1. Open a new document 2. Type something 3. CTRL-W Expected Results: 1. Save document dialog pops up with "Save" hightlighted Actual Results: 1. With gtk3, save dialog pops up with nothing highlighted and not in focus 2. With "$ SAL_USE_VCLPLUGIN=gtk ./soffice", it works as expected
I just realized there's two issues going on here. 1) The currently selected button isn't highlighted. 2) The keyboard shortcuts are missing.
Created attachment 122121 [details] gtk vs gtk3
(In reply to Luke from comment #1) > 1) The currently selected button isn't highlighted. Well, looking at your screenshot _it is_ highlighted (there is a thin orange frame around the save button). > 2) The keyboard shortcuts are missing. It's a feature, and how any other gtk3 app work. The shortcuts are hidden until you hold the alt key. See Bug 92630.
> thin orange frame around the save button On my setup, that line is practically invisible. GKT2 had both the frame and a shaded button. The hightlight/shade is missing. This is a poor UI choice, but wouldn't be an issue for me if it weren't for the 2nd problem. > It's a feature, and how any other gtk3 app work. The shortcuts are hidden > until you hold the alt key. See Bug 92630. The problem is you never used to have to hold ALT+S to save, only press "S", so my muscle memory is broken. This breaks the workflow for seasoned users. The lack of a visible highlight compounds the issue, making it look like the focus has been lost. Simon or Caolán, Can we restore the old behavior to enable dialog box shortcuts to work without pressing alt?
Oh no, please no. Let’s not introduce even more convoluted and obscure options for everything. And for the theme issue, well, you know where to report it: Launchpad.net. We do not develop GTK+ themes.
Adolfo, I'm sorry for confusing things by bringing up two separate issues. I will file a bug report on Launchpad.net for the invisible orange frame issue. To be clear this report is about: GTK+ 3 Keyboard Shortcuts Not Working on Dialog Boxes It is a regression in the gtk3 plugin that breaks users workflow. We shouldn't force users to relearn how do things, hiding the old behavior behind a feature with zero discoverability. I bisected this down to: 238575424341dedaef9713fcdb988ed39ccbf82c -> BAD d2cefbe7effbee079c05a5a8234305650618fdc1 -> GOOD http://cgit.freedesktop.org/libreoffice/core/commit/?id=74407aef94b6d8dfdd69891c4a6e578587ef3e71 tdf#92630 Enable auto-accelerator behaviour for gtk Is in that range. It affects all dialog boxes removing the ability to just press a key to use the bottom buttons.
> It is a regression in the gtk3 plugin that breaks users workflow Calling it a “regression” is misleading. A new feature was introduced that made LibreOffice match the GTK+ (default) setting of hiding the accelerators until the Alt key is pressed. Since now LibreOffice matches this default setting of your DE, there is no regression here. Just disable that setting in dconf-editor or the terminal (with the gsettings command), if you’re bothered by it.
Created attachment 122170 [details] Where to disable automatic mnemonics in dconf-editor
Adolfo, You solution is not acceptable. That is a global variable. And we should not force users to make changes like that just to keep the workflow consistent. The GTK3 workflow should be the same as the GTK2 and Windows by default. We should only use the accelerators in menu items ONLY. By using them in the dialog buttons, we force the user to use different shortcuts for differ toolkits. Ctrl+W, S -> Ctrl+W, Alt+S This is a bug. Shortcut should not change between widget toolkits.
Standard behaviour in GTK applications is that buttons in dialogs with accelerators defined only operate when the shortcut key is pressed along with a modifier; they do not operate when the shortcut key is pressed on its own. LibreOffice may have worked otherwise in the past, but the requirement to press a modifier key to access an accelerator for a dialog button is standard GTK behaviour, not an error.
I've also just checked running LO with the GTK plugin disabled (by setting environment variable SAL_USE_VCLPLUGIN to "gen", and this re-enables the use of shortcut keys on dialogs without a modifier key. So as far as I can see, behaviour of dialog shortcuts is now correct for both non-GTK (no modifier required) and GTK (modified needed) operation of LO. As my comment above - GTK requires a modifier key for shortcuts, both in dialogs and menus - this is by design and not a bug.
Simon, Thank you for the explanation. Is it possible to not use GTK accelerators in the dialog box buttons so that gen, gtk, and windows can all behave the same way? In other words only use accelerators for menus and not dialog boxes?
It's possible, but it's the wrong thing to do. The whole point of the GTK plug-in is to make LO both look *and behave* like a GTK application - all GTK applications use modifiers for accelerators in dialogs, as that is the way the toolkit is written; it's how GTK works. If the GTK plug-in is modified to behave as you suggest, while it might indeed mean that LO's behaviour is consistent across all toolkits, it means that LO's behaviour is inconsistent with that of other applications when running on a system based on GTK, which defeats the entire purpose of the plug-in. Bottom line - you can either have the GTK appearance with the GTK behaviour, or you can turn off the GTK appearance and have the behaviour you want. But the GTK behaviour should not be removed from the GTK appearance - the whole point of the GTK plug-in is to provide consistency in a GTK environment.
Just to clarify my comment above, when I say it is possible to do what you want, it involves changing and rebuilding the code - I am not aware of any setting or variable that can be used to achieve the effect you want in an existing LO build.
*** Bug 97586 has been marked as a duplicate of this bug. ***