Description: Any time you have a document open which isn't saved (or there are changes since the last save) and you try to close it (Ctrl-W), the usual dialog "Save Document?" pops up. There are three buttons: Save, Don't Save, Cancel. These buttons also have the access keys underlined (S for Save, C for Cancel, N for Don't Save). Pressing S, C, or N does nothing. It should. Steps to Reproduce: 1. Open a document (any document) 2. Write some stuff 3. Press Ctrl-W or File-Close 4. The "Save Document?" dialog pops up 5. Press S, C, N Actual Results: Nothing happens after pressing the keys on the keyboard. N, S, C, nothing. Expected Results: N should close the document without saving, S should save (or bring up the "Save As" dialog), C should cancel. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.7.1 (X86_64) / LibreOffice Community Build ID: 47eb0cf7efbacdee9b19ae25d6752381ede23126 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: el-GR (en_GB); UI: en-GB Calc: CL threaded
You need to use the shortcuts Alt+N Alt+S Alt+C I don't know, but maybe as a delicate dialog, it was done this way to avoid errors.
(In reply to m.a.riosv from comment #1) > You need to use the shortcuts > Alt+N Alt+S Alt+C > > I don't know, but maybe as a delicate dialog, it was done this way to avoid > errors. I'm sorry but dialogs don't work like that. If that was done on purpose, it's the most idiotic thing anyone's done ever, since they made Windows ME. Any dialog in any program, in any operating system, works with access keys. Doesn't matter if it's a dialog that says "hi" and does nothing, or if it's a dialog which says "Destroy Earth", "Confirm" or "Cancel". The accelerators should work stand-alone, not with Alt! Who comes up with these ideas, really?
I bibisected this with Windows 7.4 repo to ae41ac6a621ce4ee7445d8964ae30ac99ce94f37 tdf#151385 Only trigger mnemonics in dialogs when alt key is pressed I tested some Microsoft applications and the behaviour varies. With Notepad, I don't have to use Alt to trigger actions in the "what to do with unsaved file" dialog (pressing Alt shows hints on what they are). However, this dialog is using different widgetry compared to the Save As dialog and in that one, I explicitly have to press Alt-S to save. Samuel: what do you think? It seems Microsoft is mixing things up. I can't find any guidelines as such. This doesn't really answer the question of what is the recommended way: https://learn.microsoft.com/en-us/windows/win32/menurc/about-keyboard-accelerators Personally, I do find it annoying that I have to press Alt in the confirmation dialog, especially when doing rapid-fire QA work, but that's the way it works on all operating systems now.
*** Bug 141776 has been marked as a duplicate of this bug. ***
(In reply to Buovjaga from comment #3) > I tested some Microsoft applications and the behaviour varies. With Notepad, > I don't have to use Alt to trigger actions in the "what to do with unsaved > file" dialog (pressing Alt shows hints on what they are). However, this > dialog is using different widgetry compared to the Save As dialog and in > that one, I explicitly have to press Alt-S to save. If I may chip in here: the "Save As" dialog always has some other element selected, like the filename text box, the file type drop-down, the directory structure, something. So, it can't react to just "S" or "C". HOWEVER If you type in a file name and tab-tab-tab to activate one of the two buttons (Save or Cancel), then ACCELERATORS WORK WITHOUT ALT! Let me repeat: if the active element is one that doesn't use keyboard inputs, accelerators work with a single key, no Alt required! Or if there are no other elements but only buttons, accelerators work just fine on their own. Obviously, you can't have accelerators work whilst the active element is, for example, the filename text box, that would be stupid. Or the directory structure, again, you press letter keys to help select stuff or go faster. But when the active element is a button, or when there are only buttons, accelerators work as they should. Without Alt. Now, I don't know what "other operating systems" are doing, and frankly, I don't care. Windows programs have been working like that since forever. Choosing to change an expected behaviour just because "other operating systems" do it differently is stupid. Other operating systems are OTHER operating systems. macOS has the "window close" button on the top left, should we change LO in Windows to also have the "close window" button on the left as well, just because "other operating systems" do?
(In reply to skagon from comment #5) > (In reply to Buovjaga from comment #3) > > I tested some Microsoft applications and the behaviour varies. With Notepad, > > I don't have to use Alt to trigger actions in the "what to do with unsaved > > file" dialog (pressing Alt shows hints on what they are). However, this > > dialog is using different widgetry compared to the Save As dialog and in > > that one, I explicitly have to press Alt-S to save. > > If I may chip in here: the "Save As" dialog always has some other element > selected, like the filename text box, the file type drop-down, the directory > structure, something. So, it can't react to just "S" or "C". > HOWEVER > If you type in a file name and tab-tab-tab to activate one of the two > buttons (Save or Cancel), then ACCELERATORS WORK WITHOUT ALT! You are right, I did not try to focus into the buttons in my earlier test, just tried to focus elsewhere. I think that seals the deal and we should follow the Windows way on Windows.
Kind of the opposite to Samuel's work on bug 151385 which IIRC was to bring other os/DE in line with the GTK3 work of bug 92630 and WF bug 97260 Personally, I prefer consistency of forcing the <Alt>+ mnemonic for accelerator action--ALWAYS within the LO UI. Whether working with a menu (where <Alt>+ is default) or for dialogs where it had varried. And, these are for *mnemonics* (either dynamically assigned or when coded in UI). Any inconsistent behavior of shortcuts, i.e. with <Ctrl>+ key (normally), are a different can of worms. INHO => NAB and WF so log as we are consistent.
(In reply to V Stuart Foote from comment #7) > Kind of the opposite to Samuel's work on bug 151385 > > which IIRC was to bring other os/DE in line with the GTK3 work of bug 92630 > and WF bug 97260 > > Personally, I prefer consistency of forcing the <Alt>+ mnemonic for > accelerator action--ALWAYS within the LO UI. Whether working with a menu > (where <Alt>+ is default) or for dialogs where it had varried. > > And, these are for *mnemonics* (either dynamically assigned or when coded in > UI). > Any inconsistent behavior of shortcuts, i.e. with <Ctrl>+ key (normally), > are a different can of worms. > > INHO => NAB and WF so log as we are consistent. I am shaking my head in disbelief here. If you want my opinion, this is why you are driving Windows users away. It's because the decision-makers around here only care about imposing *their* way, and it seems most of you are using Linux. Even this place reeks of this attitude that "only WE are doing it right" and "we hate Windows therefore nothing will work the 'windows' way". > …forcing the <Alt>+ mnemonic for accelerator action… See what I mean? Who are you to "force" anything? Actually, Windows works differently. And Windows users are hundreds of millions. If you want to drive Windows users away, go right ahead. Let's see whose loss it will be.
(In reply to skagon from comment #8) LibreOffice (and OpenOffice predecessor) are cross-platform with a common code base. Some accommodations in native code are implemented, but for example we will never implement UWP and the code base will remain win32 c++ We are obliged to document the UI in Help and use guides--but we have NO obligation to follow MS Windows norms--and as noted accelerators in dialogs on the Windows os/DE are not normalized, by Microsoft or other projects. The dev choice implementation here to require use of the <Alt> modifier with accelerators in dialogs is acceptable cross-platform. And I say that as a primary (98%) Windows os/DE user. The impact on Windows os/DE users is negligible--and certainly does not drive them away.
(In reply to V Stuart Foote from comment #9) > (In reply to skagon from comment #8) > > LibreOffice (and OpenOffice predecessor) are cross-platform with a common > code base. Some accommodations in native code are implemented, but for > example we will never implement UWP and the code base will remain win32 c++ I never said that LO should implement UWP. Your attempt at "reductio ad absurdum" is baseless. > We are obliged to document the UI in Help and use guides--but we have NO > obligation to follow MS Windows norms--and as noted accelerators in dialogs > on the Windows os/DE are not normalized, by Microsoft or other projects. What you are obliged to do is to follow norms. Otherwise, you will end up with a product as unusable as VI. > The dev choice implementation here to require use of the <Alt> modifier with > accelerators in dialogs is acceptable cross-platform. The "dev choice" should not be a dev choice. There should be people specialising in UI and User Experience to decide. Cross-platform does not apply. You are trying to equate a userbase of hundreds of thousands of users, working for decades with a specific paradigm, to a userbase less than 5% of the former. Furthermore, there is nothing, NOTHING, stopping you from utilising specific paradigms for specific operating systems. Nothing other than just being obstinate. > And I say that as a primary (98%) Windows os/DE user. The impact on Windows > os/DE users is negligible--and certainly does not drive them away. The impact on this particular Windows user is not negligible, and I know of at least two dozen other people who think the same. The impact on me is enough to make me install Microsoft Office and be done with all this malarkey. I don't have to sit here trying to defend the glaringly obvious. In Windows, things work a certain way. You don't want to do it, because you think you're the holder of the holy truth. I've seen this crap before. About fifteen years ago, Mozilla Firefox "devs" decided to be stupid and remove the "Ctrl-E" shortcut for search, because… "oh, on Linux we have Ctrl-K and WE SHOULD FORCE USERS TO LEARN THAT SHORTCUT, IN ORDER TO ENCOURAGE TRANSITION AWAY FROM WINDOWS." No, I'm not even making this up, they said that in the bugzilla thread that was opened! The result? I made an addon for Firefox that was restoring Ctrl-E, it had thousands of installs in a matter of days. Firefox "devs" restored the Ctrl-E shortcut in a few months. Unfortunately for both me and you, I don't think a plug-in would be enough to rectify this thing. I have the knowledge or disposition to make my own private build of LO, so yeah, I'm not staying around. If you don't respect Windows users on such a basic thing, it's an indication you're not going to respect Windows users in anything. Even though I've used LibreOffice since the very first days back in 2010, even though I've encouraged users to try LibreOffice for years (as an IT journalist), this is the straw that broke the camel's back. I'm not sticking around for a project that caters to the needs of the few, disrespecting the needs of the many. Someone could say it's racism. Of the worst kind. I don't know if *you* get to choose if this is getting fixed or not, but if it is, I'm out.
The reason I added the requirement for Alt is that you could accidentally close dialogs/trigger other actions when the alt key is not required. I wasn't aware of the usual Windows experience that you can omit the Alt key when the focus is in the dialog action area. So no problem with restoring the possibility to omit the Alt key when the focus is in the action area.
(In reply to Samuel Mehrbrodt (allotropia) from comment #11) > The reason I added the requirement for Alt is that you could accidentally > close dialogs/trigger other actions when the alt key is not required. > > I wasn't aware of the usual Windows experience that you can omit the Alt key > when the focus is in the dialog action area. > > So no problem with restoring the possibility to omit the Alt key when the > focus is in the action area. Thank you for your reply. Please also note bug 141776; this one also has the side-effect of the Start Centre shortuts also requiring Alt to be pressed, which is hugely counter-intuitive. In Windows, only the top-level menu accelerators need Alt; everything else works with just the accelerator key. It is not a bug, it's a feature.
Going to send this through UX-Advise. Documentation and consistency cross-platform in the application/use of <Alt> to expose/apply accelerators has been a recurring discussion. There is minimal impact on the Windows community, and considerable divergence in our published help/documentation when facets of the UI are "tailored" to nonsensical user demands to match some perceived UI norm for a particular os/DE. Just don't. IMHO => NAB and no need to revert this or any handling of the <Alt> modifier for accelerators mix.
(In reply to Samuel Mehrbrodt (allotropia) from comment #11) > The reason I added the requirement for Alt is that you could accidentally > close dialogs/trigger other actions when the alt key is not required. > Valid, then and if reverted. > I wasn't aware of the usual Windows experience that you can omit the Alt key > when the focus is in the dialog action area. > It's not.
(In reply to V Stuart Foote from comment #14) > (In reply to Samuel Mehrbrodt (allotropia) from comment #11) > > The reason I added the requirement for Alt is that you could accidentally > > close dialogs/trigger other actions when the alt key is not required. > > > > Valid, then and if reverted. > > > I wasn't aware of the usual Windows experience that you can omit the Alt key > > when the focus is in the dialog action area. > > > > It's not. You seem to be on a personal crusade, dude. You're spreading misinformation. The answer is: YES, IT IS the usual Windows experience. You're a liar! And a fanatic. You need to move on, or someone should show you the door. Fanaticism has no place in an open-source community.
Adding see also bug 54169 (for related <Alt> modifier hide/expose of mnemonic underlining) where Mike notes <Alt> behavior for exposing accelerators in dialogs in cmnt 59, suggesting Notepad be our reference. We're already there (matching Notepad use) for handling of key actions in the dialog--requiring the <Alt> (In reply to skagon from comment #15) > > You seem to be on a personal crusade, dude. You're spreading misinformation. > The answer is: YES, IT IS the usual Windows experience. Really? Nope... > You're a liar! And a fanatic. You need to move on, or someone should show > you the door. Fanaticism has no place in an open-source community. Guess you've not spent much time in the community... I'm pretty neutral.
(In reply to skagon from comment #15) > You seem to be on a personal crusade, dude. You're spreading misinformation. > The answer is: YES, IT IS the usual Windows experience. > You're a liar! And a fanatic. You need to move on, or someone should show > you the door. Fanaticism has no place in an open-source community. Please calm down man. You have given your arguments, we heard you. Now let others decide what will be done.
(In reply to V Stuart Foote from comment #16) > Adding see also bug 54169 (for related <Alt> modifier hide/expose of > mnemonic underlining) where Mike notes <Alt> behavior for exposing > accelerators in dialogs in cmnt 59, suggesting Notepad be our reference. > > We're already there (matching Notepad use) for handling of key actions in > the dialog--requiring the <Alt> > > (In reply to skagon from comment #15) > > > > You seem to be on a personal crusade, dude. You're spreading misinformation. > > The answer is: YES, IT IS the usual Windows experience. > > Really? Nope... > > > You're a liar! And a fanatic. You need to move on, or someone should show > > you the door. Fanaticism has no place in an open-source community. > > Guess you've not spent much time in the community... I'm pretty neutral. I can see how neutral you are, by blatantly lying and presenting your lies as "THE truth". When, in fact, anyone can check for themselves and see that it's all lies. ANY, I repeat, ANY dialog in Windows has the accelerators active without Alt. You would know that, had you used Windows without the Linux key bindings firmly entrenched in your brain. Just like any other Windows user who never had Linux experience. So, yes, you are on a personal crusade. And you're even lying about that! (In reply to Samuel Mehrbrodt (allotropia) from comment #17) > Please calm down man. > You have given your arguments, we heard you. Now let others decide what will > be done. I'm sorry that I can't be calm, when you've got a fanatic here, lying throughout the thread just to make his personal preference a fact. I'd hate to see such a behaviour rewarded or encouraged. Even worse, he's got a @libreoffice.org mail, which means he's working for TDF in some form. From the behaviour I've witnessed in this thread, he really should not. This is nobody's personal playground, nor is it a "Linux" playground. Treat users of all OSs with respect.
(In reply to skagon from comment #18) Hmm... Open Notepad. Type some text. <Alt>+F -> S (to open the Save dialog) Now type the 'S' (mnemonic for the 'Save' button action) to save. What happens? Repeat, but this time type the accelerator as '<Alt>+S' Enough said?
(In reply to V Stuart Foote from comment #19) > (In reply to skagon from comment #18) > Hmm... > > Open Notepad. > Type some text. > <Alt>+F -> S (to open the Save dialog) > Now type the 'S' (mnemonic for the 'Save' button action) to save. > > What happens? > > Repeat, but this time type the accelerator as '<Alt>+S' > > Enough said? This was covered in comment 5: if you are focused in the buttons (tab into them), you don't need Alt. In LibreOffice's save confirmation dialog you are focused in the buttons by default.
(In reply to V Stuart Foote from comment #19) Please ignore everything that skagon wrote after their comment 5 (which was the last comment that actually gave useful information). They need to calm down, and stop spamming here, making the issue filled with unrelated rant and hatred, and basically unmanageable (skagon: is your goal to make the improvement happen, or to drive contributors away, and stall it?). But please read comment 5 again. The idea is, that indeed the dialogs on Windows allow the mnemonic key without Alt, *when the active control does not take keyboard input*. skagon: note again, that your inappropriate behavior is based on your personal misunderstanding of others' intentions; e.g., Stuart obviously overlooked one important detail (which they don't know otherwise, similar to Buovjaga, who reported to learn that in comment 6); and your attitude lead to personal insults. Missing something is not a crime.
I'm in the camp of no accelerator when the button bar is in focus, maybe limited to Windows (as Samuel replied in c11). Don't think we need consistency over platforms but rather within. And Ilmari's convenience argument (c3) is also relevant.
*** Bug 158165 has been marked as a duplicate of this bug. ***
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ea1421747985bd09ad40565da8536e857b5c2e9a tdf#157649 Allow omitting Alt key when focus is in dialog action area It will be available in 24.8.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.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3ad0f2317492f5a11ed9786e849f18a5fa817480 tdf#157649 Allow omitting Alt key in Windows only It will be available in 24.8.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.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/aaefd2080ecb39a3deade23368a83acee91367ef tdf#157649 Allow omitting Alt key when focus is in dialog action area It will be available in 24.2.0.2. 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.
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/7c7507e9319e65f7e9a16cbb66ffdea859403d19 tdf#157649 Allow omitting Alt key in Windows only It will be available in 24.2.0.2. 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.
Just tested on 24.2.0.3 x86_64 and it only works on dialogs that only have buttons. For instance, Save As dialog's "Cancel" button does not have the "C" accelerator enabled. Also, as indicated in my original bug https://bugs.documentfoundation.org/show_bug.cgi?id=141776 report, the Start Center keyboard shortcuts, even though visible, are still non-operational (they used to). Please look into it, perhaps re-open bug 141776?
(In reply to skagon from comment #28) > Save As dialog's "Cancel" button does not have the > "C" accelerator enabled. Oh - but which specific Save As dialog is meant? By default, Windows dialogs are used; and they use own (defined by Microsoft!) accelerators. Just tested - Notepad.exe's Save As dialog also doesn't use the "C" accelerator...
(In reply to Mike Kaganski from comment #29) > (In reply to skagon from comment #28) > > Save As dialog's "Cancel" button does not have the > > "C" accelerator enabled. > > Oh - but which specific Save As dialog is meant? By default, Windows dialogs > are used; and they use own (defined by Microsoft!) accelerators. Just tested > - Notepad.exe's Save As dialog also doesn't use the "C" accelerator... You are right. Looks like someone at Microsoft fμcked up royally…