I can reproduce it in

Version: 7.1.2.2 (x64) / LibreOffice Community
Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

but not in 

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 6e6e531b564cdc9d5b25287c215cdc5a1fcbb346
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

No repro

The ctrl + W command runs to close a file and close Libre Office, one after the other.

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: daf30c29be67b8b8fa361b0efd1a6cdbe087b6f8
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: CL threaded

Per comment 1, this should not have been set to NEW.

skagon: do you still reproduce this?

(In reply to Buovjaga from comment #3)
> Per comment 1, this should not have been set to NEW.
> 
> skagon: do you still reproduce this?

The [tab] key, arrows and [enter] do work. However, the shortcuts do not. For instance, pressing [w] will not open a new Writer file, nor will [c] open a new Calc file.
So, I suppose it's still partially reproducible, yes.

(In reply to skagon from comment #4)
> The [tab] key, arrows and [enter] do work. However, the shortcuts do not.
> For instance, pressing [w] will not open a new Writer file, nor will [c]
> open a new Calc file.
> So, I suppose it's still partially reproducible, yes.

- Do shortcuts like Ctrl + Q (quit), Ctrl + O (open) or Alt + F12 (options) work?
- For the "W" and "C" accelerators, I believe you need to press Alt as well to be able to use them (like you would have to in order to start using top-menu accelerators in Writer and Calc). I don't know if those letters on their own ever worked (but please let us know if you know about a version that did allow that, or if you have seen it documented somewhere).

Please let us know if those work.

(for the record, I can't reproduce in any version on Linux, I tried 5.4, 7.1, and a recent trunk build)

(In reply to Stéphane Guillou (stragu) from comment #5)
> (In reply to skagon from comment #4)
> > The [tab] key, arrows and [enter] do work. However, the shortcuts do not.
> > For instance, pressing [w] will not open a new Writer file, nor will [c]
> > open a new Calc file.
> > So, I suppose it's still partially reproducible, yes.
> 
> - Do shortcuts like Ctrl + Q (quit), Ctrl + O (open) or Alt + F12 (options)
> work?
> - For the "W" and "C" accelerators, I believe you need to press Alt as well
> to be able to use them (like you would have to in order to start using
> top-menu accelerators in Writer and Calc). I don't know if those letters on
> their own ever worked (but please let us know if you know about a version
> that did allow that, or if you have seen it documented somewhere).
> 
> Please let us know if those work.
> 
> (for the record, I can't reproduce in any version on Linux, I tried 5.4,
> 7.1, and a recent trunk build)

Those shortcuts you mentioned do work. However, as you said, "those letters on their own" worked in version 7.0 and everything before.

Moreover, it doesn't make sense to require another combination like [alt]+[w] or [alt]+[c]. These are not "shortcuts", it's not obvious that those would work. They are not in a menu, and the access keys on each option (icon) are already underlined – whereas in all Windows applications the access keys are never underlined (on a menu bar) until the "down" event of the Alt key. Being visible in Windows pretty much means you just have to press the corresponding underlined key (letter) on the keyboard.

Again, let me repeat: this behaviour worked until version 7.0, then stopped working, then it re-started working until 7.4 or 7.5 (can't remember exactly). It is the expected behaviour in Windows, that's why it was working for so many years.

I have a hunch that this issue may be related to this bug: https://bugs.documentfoundation.org/show_bug.cgi?id=157649

(In reply to skagon from comment #7)
> I have a hunch that this issue may be related to this bug:
> https://bugs.documentfoundation.org/show_bug.cgi?id=157649

Confirmed after doing a bibisect for bug 157649. Even though it's newer, let's close this as duplicate.

*** This bug has been marked as a duplicate of bug 157649 ***

I think this should re-open. The other bug is (sort of) fixed, but this remains broken. Please re-open!

Hmm, can not confirm with no document open and at the Start Center with default Recent documents thumbnails showing in the backing window.  

Clean user profile, *ALL* the Start Center accelerators work, though each *requiring* press and hold of the <ALT>+accelerator. Which I know some folks see as an issue, but the UI is consistent.

<ALT>+o -- Opens the File dialog
<ALT>+s -- Opens the Remote Files dialog
<ALT>+e -- moves focus to the Templates button, then requires <Enter> for change to templates backing window (a bit out of sync with that)
<ALT>+w -- Opens a new Writer document
<ALT>+c -- Opens a new Calc sheet
<ALT>+i -- Opens a new Impress presentation
<ALT>+d -- Opens a new Drawing document
<ALT>+m -- Opens a new StarMath Formula
<ALT>+b -- Opens a new Base database wizard
<ALT>+l -- Opens the LO help in a browser
<ALT>+x -- Opens the extensions.libreoffice.org web page in a browser

Version: 24.2.0.3 (X86_64) / LibreOffice Community
Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Oh, and toggling from Templates backing window to Recent documents--like the the <Alt>+e accelerator for Templates the <Alt>+r accelerator only will focus onto the SB button and requires the <Enter> to complete the toggle.

So that seems consistent UI for change/toggle of the SC backing window, though kind of seems like just the <Alt>+accelerator alone should be sufficient to be the same as the other widgets.

As reopened for Start Center handling

See comment #59 in see also bug 54169 which doesn't address what should be done for the SC in Windows.  Case could be made that the SC accelerators are like entries on the main menu, so should require use of the <Alt> as currently.  Equally, case can be made that the entire SC is like a dialog and the accelerators should not require the <Alt> key.

I'm actually OK either way, as with menu or as with dialog. Just need the SC accelerators to be consistent. 

Maybe give a nod to what is now legacy since about the 4.2 release of SC, and leave it as is.

Created attachment 192487 [details]
"Start Center" in MS Word 2016

I'm against it. As a Windows user, I can say that this is *not* an expected / established behavior here - to use accelerator keys without Alt **in main program windows** (as opposed to dialogs). It may be seen e.g. in MS Word: starting it without a file opens their "start center", with a list of recent documents, and a "sidebar" with items named "Home", "New", "Open", "Account", "Feedback", "Options" (see screenshot). None of these items work without Alt.

The point that it used to work is IMO not really important. Now it's consistent, and I see no reason to change it here.

And… here we go again! Same people, same arguments.

To cut to the important point here, if the underlines are visible, the accelerators should work WITHOUT any other key, i.e. [ALT].
It really is as simple as that.

Moreover, since the Start Centre is all about user *convenience*, the accelerators should actually be *accelerating*.
My muscle memory of decades is that we press [ALT] to get to the menu bar. That's how it works. If it's visible and has a letter underlined, you just press that key. Like "Save". It's [ALT]+[F], [S]. It is not [ALT]+[F], [ALT]+[S], simply because you're already at a point in the navigation where you've left the main window (where keys are meant for typing), so you can use all 26 characters for selecting options without having to move the mouse or the arrow keys.

Again, if the underline is visible, it automatically denotes (should denote anyway) that the underlined accelerators are *active*. No [ALT], no nothing!
If [ALT] is required, they should become underlined IF and WHEN the user presses [ALT].

This is plain UI logic.

(In reply to skagon from comment #15)
> Again, if the underline is visible, it automatically denotes (should denote
> anyway) that the underlined accelerators are *active*. No [ALT], no nothing!

Wrong. As bug 54169 was linked here, you should be aware that there is a *setting* for that. So it is perfectly valid, that the underline is *visible*, but still require the Alt. Indeed, but 54169 must be properly fixed. But not this.

And the bug 157649 also demonstrates the fact that underline and active state of the accelerators are absolutely orthogonal (at least on Windows, which is the focus here): in dialogs, no underline and still accelerators are active.

Adjusted the title to the continuing issue of mnemonic/accelerators on the Start Center UI requiring the <Alt>+ keying to trigger. Main menu shortcuts and accelerators are no longer the concern on this BZ issue.

So now, after tdf#54169 got fixed, there's no mnemonic shown in the start center on Windows, until you press [Alt]. As said, my take on this is WF.

As per comment 19, let's close as "won't fix". Thanks everyone.

*** Bug 152223 has been marked as a duplicate of this bug. ***

I just tested and it finally now works without the ALT key.  
Thank you

(In reply to skagon from comment #15)
> To cut to the important point here, if the underlines are visible, the
> accelerators should work WITHOUT any other key...
Good argument. But the SC has two panels, and I expect to jump to the first item in the list when pressing a key in the right documents pane. The Recent Documents/Templates toggle might fool a little but you are always on the right pane.

(In reply to Heiko Tietze from comment #23)
> (In reply to skagon from comment #15)
> > To cut to the important point here, if the underlines are visible, the
> > accelerators should work WITHOUT any other key...
> Good argument.

Please Heiko, did you read comment 16?

(In reply to Mike Kaganski from comment #24)
> Please Heiko, did you read comment 16?
Not in detail.

To repeat myself: whether accelerators are shown or not, I am challenging the argument that one can expect simple keystrokes to start a function. Fact is that we have the focus on the documents/file list (cursor keys to navigate) and alternative access is needed for other UI controls.

Created attachment 192515 [details]
Normal Start Centre view (for me)

This is what I see in the Start Centre.

> To repeat myself: whether accelerators are shown or not, I am challenging
> the argument that one can expect simple keystrokes to start a function. Fact
> is that we have the focus on the documents/file list (cursor keys to
> navigate) and alternative access is needed for other UI controls.

Please check attachment #2 I just posted. This is what I see every time I close a document.

Notice that the underlined accelerators/mnemonics are literally *everywhere*.

Also notice how the "Recent Documents" is highlighted, but nothing in the actual list. Not even an outline or a hint that this is the active (focused) area. For all intents and purposes, every time I see this, I think that the "Recent Documents" entry is active, therefore if I press the "down arrow" key, I should go to "Templates", and then "Writer Document".
Actually, I find it really annoying (not to mention counterintuitive) that the left list is not working as one unit, but rather there are three distinct areas and you actually have to [TAB], just to go from one area to another. This should be **one** unit! I don't mind the separators, but at least the arrow keys should allow you to move continuously!

Now, if "Recent Documents" is active, there should be some indication on the right side too. And the underlines should be gone, since they don't work (without [ALT]).

(In reply to skagon from comment #27)
> Please check attachment #2 I just posted. This is what I see every time I
> close a document.

I fixed bug 54169 only yesterday. It will be available in a future version (24.8).

> To repeat myself: whether accelerators are shown or not, I am challenging
> the argument that one can expect simple keystrokes to start a function.

I will challenge the argument that simple keystrokes should not start a function.
Every piece of software works like that. Photoshop has single-key selection for tools. SketchUp works the same. KiCad, same. Basically, almost **every** programme that does not have (or is) some kind of text editor, uses single keys for functions or tools.
The Start Centre does not use the keys for anything. Why the hell not use those keys to speed up selection? [W] for Writer document, [C] for Calc document, [D] for Draw document, etc.

I reiterate: in the Start Centre, these keys are just sitting there doing nothing!

(In reply to skagon from comment #29)

This argument does not mean that there should be inconsistency inside the same program. LibreOffice is a *document* software, and one of its main focus points is text. In Writer and Calc (and Math), typing is the main workflow. Start Center is nothing but an auxiliary tool. Having its behavior different from the main parts of the program is inconsistent with itself. It would confuse people, making them think "this is how things work in this program". And the benefit of what you suggest (just because "it is possible to implement") is practically indistinguishable from zero.

WONTFIX is the correct resolution.

(In reply to Mike Kaganski from comment #30)
> (In reply to skagon from comment #29)
> 
> This argument does not mean that there should be inconsistency inside the
> same program. LibreOffice is a *document* software, and one of its main
> focus points is text. In Writer and Calc (and Math), typing is the main
> workflow. Start Center is nothing but an auxiliary tool. Having its behavior
> different from the main parts of the program is inconsistent with itself. It
> would confuse people, making them think "this is how things work in this
> program". And the benefit of what you suggest (just because "it is possible
> to implement") is practically indistinguishable from zero.
> 
> WONTFIX is the correct resolution.

I disagree. The "consistency" argument is a non-sequitur. We're talking about the Start Centre. Auxiliary tool or not, it is there, and nobody would confuse it with anything else. Are you assuming that the users are morons? That they can't make the distinction between "Writer", "Calc", and "Start Centre"? They would get confused? Oh, please!

Like, if pressing [W] in the Start Centre opens up a new blank Writer document, someone would think that just pressing [W] anywhere, rather than typing the letter "W", would open up a new blank document? **That** is your argument? Seriously?

Please, let's get serious here. That functionality ** already existed ** in LO in the past, and it was damn useful! Please, put it back in! Leave the dogmatism outside and see this with a clear mind, and without thinking that LO users are stupid and won't understand how the keyboard works!

(In reply to skagon from comment #29)
> Every piece of software works like that.

It is very sad, that incorrect generalization is used to defend one's point of view, attempting to trick people in believing that this is common software behavior (using examples from a specialized graphic-oriented software).

The counter-argument was already given right here, in comment 14:
> It may be seen e.g. in MS Word: starting it without a file opens their "start
> center", with a list of recent documents, and a "sidebar" with items named
> "Home", "New", "Open", "Account", "Feedback", "Options" (see screenshot).
> None of these items work without Alt.

> 
> It is very sad, that incorrect generalization is used to defend one's point
> of view, attempting to trick people in believing that this is common
> software behavior (using examples from a specialized graphic-oriented
> software).


It is sadder to see dogmatism in people who will just ruin an already present functionality, just because they don't like it, or it doesn't conform to their view of "how it should be". If you'd like, I can make a list of all the programmes that have that very same common behaviour. Believe me, the list is long. VERY long.

Read my comment 31 again. It's right above. Go ahead, I'll wait.

Now that you (presumably) have read it, what do you have to say?

Again, the functionality was there! Someone decided it should stop working, initially because they believed it "should work like Linux", only with [ALT]. That is wrong.

Now you come along and practically claim that LO users are stupid, and won't understand the difference between the Start Centre and an open Writer or Calc document.

Got any better arguments, or shall you revert to "neh neh neh I won't fix it" whilst stomping your foot at the same time?

Actually seems behavior of the SC, with fix for bug 54169 in place for a 24.8 release, now does exactly what OP in comment 6 had requested. And this issue is resolved WFM

At 24.8 there are no SC accelerators *until* the <Alt> is pressed and held. Mnemonics are not visible and no action performed, honoring the Win32 SPI_GETKEYBOARDCUES setting.


@skagon, please test a current nightly against 24.8 and see resolution there.
Here are instructions for a parallel install [1] and the nightly installer builds can be downloaded here [2].

=-ref-=
[1] https://wiki.documentfoundation.org/Installing_in_parallel/Windows
[2] https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/

(In reply to V Stuart Foote from comment #34)
> Actually seems behavior of the SC, with fix for bug 54169 in place for a
> 24.8 release, now does exactly what OP in comment 6 had requested.

Indeed; but OP opted to move the goalpost later. And even the wording in comment 6 wasn't "make it consistent", but "let it work without Alt". Thus, WF is OK.

(In reply to V Stuart Foote from comment #34)
> Actually seems behavior of the SC, with fix for bug 54169 in place for a
> 24.8 release, now does exactly what OP in comment 6 had requested. And this
> issue is resolved WFM
> 
> At 24.8 there are no SC accelerators *until* the <Alt> is pressed and held.
> Mnemonics are not visible and no action performed, honoring the Win32
> SPI_GETKEYBOARDCUES setting.


What I had requested in comment 6 is that the original functionality is restored. Original functionality is that accelerators work WITHOUT pressing [ALT]. There are no "changed goalposts". Read comment 1 and see what I say there!

> Expected Results:
> Keyboard should work. Pressing [TAB] should cycle through the options, shortcuts
> should be working, e.g. [W] should open a new Write document.

I don't know why you are trying to make it seem as if I am "changing the goalposts" by lying. It's right there in comment 1 for all to see!

For the millionth time: it used to work properly and fine (no [ALT] needed), until someone decided to screw everything up. Please fix it!

(In reply to skagon from comment #36)
> 
> What I had requested in comment 6 is that the original functionality is
> restored. Original functionality is that accelerators work WITHOUT pressing
> [ALT]. There are no "changed goalposts". Read comment 1 and see what I say
> there!

And that is the WONTFIX, it is not coming back. 

Please focus on the actual implementation in master branch resolving bug 54169 as present now in a nightly against 24.8.0

(In reply to Mike Kaganski from comment #32)
> (In reply to skagon from comment #29)
> > Every piece of software works like that.
> 
> It is very sad, that incorrect generalization is used to defend one's point
> of view, attempting to trick people in believing that this is common
> software behavior (using examples from a specialized graphic-oriented
> software).
> 
> The counter-argument was already given right here, in comment 14:
> > It may be seen e.g. in MS Word: starting it without a file opens their "start
> > center", with a list of recent documents, and a "sidebar" with items named
> > "Home", "New", "Open", "Account", "Feedback", "Options" (see screenshot).
> > None of these items work without Alt.

Since you seem to want further proof:

• Media Player Classic (a ton of keys)
• VLC (same as above)
• Mozilla Thunderbird : this is a case on its own. Practically ALL of the keys are there as shortcuts and nobody gets confused when writing an e-mail. Would you look at that! For example, N is for Next unread message, P is for previous unread, B is for previous message, F next message, W is for Watch thread, etc. Nobody "confuses" the shortcuts with actual text input.
• Facebook (on browser): it's got a ton of one-key shortcuts. C for comment, L for like, S for share post, J to jump to next post etc.

…need I go on? Probably not, since you're just being obtuse.

(In reply to V Stuart Foote from comment #37)
> (In reply to skagon from comment #36)
> > 
> > What I had requested in comment 6 is that the original functionality is
> > restored. Original functionality is that accelerators work WITHOUT pressing
> > [ALT]. There are no "changed goalposts". Read comment 1 and see what I say
> > there!
> 
> And that is the WONTFIX, it is not coming back. 
> 
> Please focus on the actual implementation in master branch resolving bug
> 54169 as present now in a nightly against 24.8.0


Yeah, why would I care about a bug that was not submitted by me, and solves nothing I'd care about? Let whoever submitted that bug check if it was resolved or not.

(In reply to skagon from comment #38)
> • Mozilla Thunderbird : this is a case on its own. Practically ALL of the
> keys are there as shortcuts and nobody gets confused when writing an e-mail.
> Would you look at that! For example, N is for Next unread message, P is for
> previous unread, B is for previous message, F next message, W is for Watch
> thread, etc. Nobody "confuses" the shortcuts with actual text input.

Accidentally hitting these surprise shortcuts in Thunderbird annoys me very much. It makes the UI seem unstable.

(In reply to Buovjaga from comment #40)
> (In reply to skagon from comment #38)
> > • Mozilla Thunderbird : this is a case on its own. Practically ALL of the
> > keys are there as shortcuts and nobody gets confused when writing an e-mail.
> > Would you look at that! For example, N is for Next unread message, P is for
> > previous unread, B is for previous message, F next message, W is for Watch
> > thread, etc. Nobody "confuses" the shortcuts with actual text input.
> 
> Accidentally hitting these surprise shortcuts in Thunderbird annoys me very
> much. It makes the UI seem unstable.

It's not "unstable", it's quick and useful. I've been using Thunderbird for almost 20 years now and I don't ever remember hitting a key accidentally and being surprised. I know when keys are meant to do something *other* than type.

(In reply to skagon from comment #39) 
>... 
> Yeah, why would I care about a bug that was not submitted by me, and solves
> nothing I'd care about? Let whoever submitted that bug check if it was
> resolved or not.

Because, as you are dependent on others to design and implement this open source software, actually testing and commenting on what is relevant to the project would be more appreciated than your intransigent position.

Alternatively code submissions are welcome. Looking forward to your first submission.

(In reply to V Stuart Foote from comment #42)
> (In reply to skagon from comment #39) 
> >... 
> > Yeah, why would I care about a bug that was not submitted by me, and solves
> > nothing I'd care about? Let whoever submitted that bug check if it was
> > resolved or not.
> 
> Because, as you are dependent on others to design and implement this open
> source software, actually testing and commenting on what is relevant to the
> project would be more appreciated than your intransigent position.
> 
> Alternatively code submissions are welcome. Looking forward to your first
> submission.


My first code here would be to undo this crap. Oh, wait…

You WONTFIX, then I WONTTEST…