Seems to be limited to the Start Centre. Works as expected in other components
Steps to reproduce
- Start LibreOffice to the Start Centre
- LO closes
(bisected, so taking the liberty of setting to NEW)
This seems to have begun at the below commit.
Adding Cc: to firstname.lastname@example.org; Could you possibly take a look at this? Thanks
Author: Simon Long <email@example.com>
Date: Wed Jul 8 18:02:50 2015 +0100
tdf#92630 Enable auto-accelerator behaviour for gtk
Reviewed-by: Caolán McNamara <firstname.lastname@example.org>
Tested-by: Caolán McNamara <email@example.com>
@Matthew, isn't this a duplicate of bug 92516
This can be fixed by modifying the Window::KeyInput function in vcl/source/window/window.cxx - I added code to this to prevent accelerators having any effect when underscores are not shown, and this is preventing the CTRL+combination from being passed through.
However, this seems to me to expose a more fundamental problem with this particular window - its behaviour is non-standard in various ways. First off, CTRL-Q does close any other LO application, so they are clearly handling accelerators and shortcuts differently.
But this window does several odd things. First off, the shortcut keys shown against the file types to create new documents work without any modifier being held down, but they are shown with underscores, which is standard notation for an ALT+<key> combination - is this really desired behaviour? They actually work with any of <key>, ALT+<key> and CTRL+<key> - this cannot be right, surely?
Hitting H on its own is a shortcut for the Help button at the bottom of the screen, as is ALT-H - this is in spite of the fact that there is an underscore on the H of the Help menu at the top of the screen - as far as I can tell, it is not possible to open the Help menu with a keyboard shortcut in spite of it being signalled as possible by the presence of the underscore. This in turn renders the menu behaviour as non-standard.
I also don't understand why the holding down and releasing of the ALT key on this screen does not hide the accelerator underscores, in spite of the code I wrote to do this working perfectly in every other window and dialog in LO.
If you want a quick fix to the problem reported, modify the statement "if (cod.GetCode () >= 0x200 && cod.GetCode () <= 0x219)" in the function above to "if (cod.GetCode () >= 0x200 && cod.GetCode () <= 0x219 && cod.GetModifier () != 0x2000)", which means that CTRL presses override the accelerator tests, but I strongly feel that the correct thing to do is to rewrite the key handling code in this application to work consistently with the rest of the LO interface.
(In reply to V Stuart Foote from comment #2)
> @Matthew, isn't this a duplicate of bug 92516
you are right. it looks to me the same issue described under Windows.
*** This bug has been marked as a duplicate of bug 92516 ***
no, wait a moment... it's not the same...
according to comment 0 the "Ctrl+Q" doesn't quits LibO start center under Linux
while it works under Windows if you just click it without entering the "File" menu where the "Ctrl+Q" is uneffective on Windows too... see: https://goo.gl/I51BWI
As above - from what I can see, my change has revealed some strange behaviour in the way the Start Centre handles keyboard input; it looks to me as if something is overriding the normal passing of keyboard input through the hierarchy, in which I believe in other applications the menu bar has priority over the rest of the window. The Start Centre was not handling keyboard shortcuts correctly prior to my change; the change has exacerbated the problem by breaking it further, but it looks to me as if the keyboard handling in the Start Centre needs to be revisited and corrected, as it is currently doing something odd. (It may be doing it for perfectly valid reasons, but I've not looked at the code, so I don't know what they are!)
I know we'd done some strangeness in making the StartCenter .UI based, but since OS X and WNT don't implement GTK, I'm not surprised a major rework for GTK3 has caused hiccups on non-Linux platforms.
Startcenter has a special hack to make the accelerators like Ctrl+q working, see
BackingWindow::Notify() in sfx2/source/dialog/backingwindow.cxx
It seems that this Notify() is not called any more which is the core of the issue here; but what happened so that the key events do not reach it any more, I have no idea without some real debugging.
Jan Holesovsky committed a patch related to this issue.
It has been pushed to "master":
tdf#92866 startcenter: Make the accellerators work again.
It will be available in 5.1.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Migrating Whiteboard tags to Keywords: (bibisected)
@Kendy, Simon, *
On Windows 8.1 Pro with
Build ID: 4a8c0d313540bd78c9c381edd548b976c580ca9a
CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL;
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-01-04_02:00:52
Locale: en-US (en_US)
When in the Start Center if the main menu has focus the <Ctrl>+Q and <Ctrl>+O shortcuts have no action (Exit or Open dialog respectively).
But an <F6> or <F10>, or now apparently <Alt> (which is acting like <F10>), key entry to move focus down to the Tab buttons, or to the Thumbnails enables both those global "shortcuts".
Something is still not correct with when shortcuts are enabled or not.
Still unable to Exit LO using File - Exit.
I can Exit using Ctrl Q - click the "x" but no other way.
Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737
CPU Threads: 2; OS Version: Windows 6.1; UI Render: default;
Locale: en-US (en_US)
In Comment #3 "holding down and releasing of the ALT key on this screen does not hide the accelerator underscores" is resolved bug #99324. The aspects around duplicate accelerators shown in the backing window and the menubar seems to have been hacked around in the interim with changing accelerators so there isn't duplicates by default. Its probable there's still some dubiousness in there somewhere.
In Comment #5, depending on the way you read it, there might be a suggestion that ctrl+q doesn't work when the file menu is open. That's expected behaviour.
Comment #12 is probably bug #92516
Comment #0 was start center and ctrl+q under linux and probably resolved by kendy's original fix. It definitely works in 5-1 under Linux gen/gtk/gtk3
I'm fairly satisfied that Comment #0 is fixed by the commit of Comment #9. Some of the other aspects are resolved via #92516 and #99324. If there are remaining aspects please split them up as new bugs.