Ctrl-S, the shortcut for Saving the file, is sometimes used in other dialogs to mean different things. It can easily lead the user to thinking that they've saved the file, when they haven't. Please consider making Ctrl-S have a single mapping. And make sure it works no matter what dialog or panel is active (unless you're locked in a modal dialog, of course). Concrete examples I've noticed are the Styles and Formatting Modify-style panel, and Find & Replace. I honestly think it could even be argued that the current behaviour is a design bug!
Hi Luke, Are you sure? In dialog's you use characters in combination with Alt, not with Ctrl.. As far as I know. When hitting Ctrl+S, doesn't do that the same as just hitting S? Thanks! Cor
Set as WorksForMe now. Please reopen and give specific information if there is need to. Thanks! Cor
No, not for me under Ubuntu Linux. Ctrl-S is a shortcut for Save, Alt-S does not save the document. Typing an "s" of course inserts an "s" character into the document. I also noticed for example that even if you click into the paragraph style or Font Style or Font size text fields, Ctrl-S no longer works to save the document: you have to click into the document text area before the shortcut works. As another example, if I open the Find & Replace dialog, and from that the Format dialog, and then click to the Font Effects tab, Ctrl-S make the Font Color active (and set to Sky blue?) and each extra Ctrl-S seems to step through to the next font color. Exploring a little more, Alt-w in that dialog will cycle the Shadow option through three states: the label for Shadow selected and the checkbox filled (orange), then the checkbox ticked and filled, then unticked and white (empty). Alt-o does not have the same effect on the Outline option: it simply alternately selects and deselects the label text while the checkbox stays in the state it was (filled (orange) and unticked, filled and ticked, or unticked and white (empty). Alt-B for Blinking cycles through all three states. So some Alt sequences in dialogs do operate shortcuts. But Ctrl-S appears to be sent to the dialog, not to the main document, so the save shortcut does not work unless the document has focus.
Thanks for your explanation Luke. This means that you want to change the global behaviour of the UI. Many key strokes are bound to the environment, element that has the focus in the UI. I would say a WontChange... But that's only me..
I see what you mean. But if the design currently allows a critical shortcut (easily the most important shortcut) to be reused for other functions in other parts of the UI depending on whether they have focus or not, in my opinion that's a major design error. (FWIW, I have about 30 years experience in programming and designing UIs and UI technologies, including working with a lot of HCI people.) I am unaware of any popular applications which reuse the Save shortcut for other functions in the UI. In fact I was unaware of the practice of having a keyboard shortcut (other than Tab/Enter) depend on what UI element has focus: hence the common practice to have many combinations of modifiers (like Alt, Ctrl, Shift, Meta, and even if desperate Alt-left and Alt-right), purely to avoid any duplication of a shortcut key, ever. It's unfortunate, but necessary (IMHO). Keyboard shortcuts are normally "absolute paths" to a single function in the application. Making them context-sensitive is, ah, quite unusual. I suppose if the shortcuts are partitioned into two sets, so that the Alt-shortcuts are context sensitive and the Ctrl-shortcuts are absolute, that might have good arguments in its favour. Anyway, I will be interested to hear what the design team thinks. Cheers!
Apologies: when I said "I am unaware of any popular applications" I of course meant "I am unaware of any *other* popular applications"!
Bringing this to the attention of the design team.
Hmmm, the MOD1 + KEY_S is already a global assignment for the uno:Save action in LibreOffice. It should perform that uno:Save function already every where in a LibreOffice session. Unless it is being intercepted by the OS/DE, or is not implemented/handled correctly in a module. I don't believe it diverges from those uses in LO. So would need specifics of OS/DE and specific STR to call this anything but WFM. In fact, in Windows it does run uno:Save of the document while in the Styles and Formatting modify-style or in Find & Replace dialogs. Definitions for the globals are found here: =-ref-= http://opengrok.libreoffice.org/xref/core/vcl/source/window/keycod.cxx
I'm very glad to hear that it's not intended to work as it does for me! My OS is Ubuntu 14.04, Desktop Environment is Unity but with the classic interface packages so it behaves more like traditional DEs of the past. Steps to Reproduce are: 1. Open a LO file (I only checked Text Document, Drawing, Presentation and Spreadsheet). 2. Do something (e.g. add a piece of text) 3. Open the Find & Replace dialog 4. Type Ctrl-S and note that the document is not saved. 5. In the F&R dialog, open Other Options -> Format -> font Effects 6. Type Ctrl-S and note that the document is not saved and that the Font Color widget now has focus and (perhaps) has selected the color Sky Blue 7. Type Ctrl-S and as per step 6, but now the color after Sky Blue is selected. many sequences are possible: just get the focus anywhere except the body of the document. E.g. click into the text area of the Paragraph Style or Font or Font Size widgets on the top area, and then note that Ctrl-S does not save the file. The bug is perfectly reproducible for me. It only happens for LO - all other applications for which Ctrl-S = Save, work as expected at all times. I think this means the DE is not involved in the odd behavior, but you would know better than I. If you need more information, just let me know.
I can confirm this. If you click to the Search Taskbar, to the Font selection etc. CTRl+S does not save. You have to click to the Document, then CTRL+S works. Tested on Ubuntu 14.04.
Ctrl+S isnt an active shortcut key when a user is within a dialog, as i would assume it should be, it only works to save a document when the focus is on the document. This is the behaviour on Windows and Linux (Gnome 3, KDE 5, Mate). The Ctrl+S behaviour in the Font Effects tab is no different than just pressing 'S' by itself, it jumps through the entries which start with 'S', which means it is ignoring the pressing of Ctrl. This is WFM. (In reply to V Stuart Foote from comment #8) > In fact, in Windows it does run uno:Save of the document while in the Styles > and Formatting modify-style or in Find & Replace dialogs. Not sure how this worked for you, but didnt for me on Windows 7.
@Jay, * <Ctrl>+S is supposed to be a global as assigned an enum in vcl--and receive the uno:Save action, AFAIK. But seems like we are modifying the assignment for localization in .xcu, and also are assigning the "S" for use as accelerators. I'm not clear on what is supposed to happen--which definition gets precedence and where in the UI. I've asked on the Dev list for a bit of clarification--but no sage advice from there yet. http://nabble.documentfoundation.org/Are-vcl-Global-Shortcuts-and-localized-accelerators-diverging-td4176098.html
I've found yet another awful problem for me caused by this. See https://bugs.documentfoundation.org/show_bug.cgi?id=99014 for a description regarding an operation in LO which has resulted in thousands of pieces of text with the wrong typeface and font size. Because LO does not support Find All and Replace All for text formats (you can *find* one, but you can't "find all"; nor can you select a *replacement format*, so you can't use F&R to Replace one, let alone all of them). This means you have to manually find them one at a time (Find Next). Fixing it would be as easy then as hitting Ctrl-M - except that F&R dialogue has focus, and Ctrl-M goes to that and does nothing useful. So you have to: 1. Click into F&R dialogue (best if you hit the Find Next button) 2. Click back on titlebar of main doc 3. Hit Ctrl-M and repeat these somewhat crippling hand contortions a thousand times. Aagh!
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
The request here is not limited to ctrl+S as alt+f4 also doesn't work when you are in a modal situation. That can be dialog (which closes on alt+f4) but also in case of floating widgets like add table or set colors at the standard toolbar and also when a dropdown is expanded (and in those cases nothing happens). You have to press escape or click somewhere to get back into the normal flow. That's a WFM as it also happens in other programs (just open the main menu in any app and press alt+f4). And what's to do is perfectly clear for users. However I can crash the program with alt+f4 when the focus is at the sidebar in the font name dropdown (not when it is open). Happens not in master, so this issue has been fixed.
FWIW in comment #8 and comment #12 those key combinations are just categorized by vcl, vcl doesn't itself do anything when it sees them. A consumer can look at the category to decide to do something, typically cut and paste categories are actively examined by consumer widgets.