LibreOffice Global: Ctrl+F5 is defined to toggle focus between document contents and controls. LibreOffice Writer/Calc: Ctrl+F5 is defined to toggle the sidebar. Definition for Writer/Calc takes precedence. Consequence: No way to switch focus between document content and controls by keyboard alone. You have to use the mouse if you want to use keyboard shortcuts defined for controls. Proposal: Define Alt+F5 to toggle focus between document contents and controls. UI-Language: German. Did not check if this behaviour depends on the UI-Language.
Ctrl+F5 also is default for Impress and Draw; not for Math. Version 7.1.8.1, on Windows 10.
Ctrl+F5 shows/hides the sidebar. We collected the (admittedly clumsy) keyboard interactions at https://wiki.documentfoundation.org/Design/Guidelines/Sidebar. What exactly is missing / not working?
(In reply to Heiko Tietze from comment #2) > What exactly is missing / not working? Hope that bug 146925 answers your question.
(In reply to Albrecht Müller from comment #3) > Hope that bug 146925 answers your question. Unfortunately not. A bug is not answering... (In reply to Heiko Tietze from comment #2) > What exactly is missing / not working? Is it a documentation question?
Created attachment 178256 [details] Contains background information to bug 146906, tries to demonstrate the problem and describes problems encountered when creating the demonstration.
(In reply to Heiko Tietze from comment #4) > (In reply to Albrecht Müller from comment #3) > > Hope that bug 146925 answers your question. > > Unfortunately not. A bug is not answering... > > (In reply to Heiko Tietze from comment #2) > > What exactly is missing / not working? > > Is it a documentation question? I tried to answer the questions in more detail in the attachment and also included a crash report I got when working on this document. I can fix the particular problem reported here myself thus I could close the bug with WORKSFORME. But is this helpful to others who might run into the same problem?
Many thanks for your detailed analysis. I simply missed the point that accelerators for uno:ToggleControlFocus clashes with .uno:Sidebar both being assigned to Ctrl+F5. Combinations with Alt are often used for system-wide events and I'd be careful using it for something else. Since F6/Ctrl+F6 activates the a11y mode to tab through the UI elements, we could use Shift+Ctrl+F6 for uno:ToggleControlFocus. Or leave it empty and let the user configure. PS: If you are able to reproduce the crash reliably please file another ticket with a short description and a link to this attachment.
Btw, if you want to enter recurring phrases the auto text feature is handy. https://help.libreoffice.org/7.3/en-US/text/swriter/guide/autotext.html
We discussed the topic in the design meeting. The use case is clear and reasonable (there is no way to enter form controls without using the mouse in Writer; Base works as expected). Alt+F5 is used to switch to some window mode and shouldn't be used. Ctrl+Shift+F6 has the charm of being close to the a11y-mode (F6, Ctrl+F6) but is disabled in the customization for some reason. We should investigate why. If that's not possible, we could use Ctrl+Shift+F5. If we assign a shortcut for this function in Writer we should change it in Base and other modules too for consistency. Code pointer: officecfg/registry/data/org/openoffice/Office/Accelerators.xcu
(In reply to Heiko Tietze from comment #9) > We discussed the topic in the design meeting. The use case is clear and > reasonable (there is no way to enter form controls without using the mouse > in Writer; Base works as expected). What is expected in Base? To get the sidebar or to shift the focus? > > Alt+F5 is used to switch to some window mode and shouldn't be used. > Ctrl+Shift+F6 has the charm of being close to the a11y-mode (F6, Ctrl+F6) > but is disabled in the customization for some reason. We should investigate > why. If that's not possible, we could use Ctrl+Shift+F5. > Careful: Ctrl+Shift+F6 clashes with Calc's function to enter a mode that allows to define fixed and scrollable parts of a table using cursor keys. I suspect that this is hardcoded. It also clashes with practices in other programs (Thunderbird, Firefox, and old MS-Access 97) where key combinations with F6 are used to cycle through various screen areas or forms. Thus I would expect that key shortcuts containing F6 would for example cycle through various open forms belonging to some Base document. For the use of F6 in MS Office you may want to analyse https://support.microsoft.com/en-us/office/keyboard-shortcuts-in-office-e765366f-24fc-4054-870d-39b214f223fd Did you consider combinations with the F10 function key? Did you notice that the Alt key alone has a similar (identical?) function as F10? It toggles between menu and current focus. I think this is a function similar to the uno:ToggleControlFocus command. > If we assign a shortcut for this function in Writer we should change it in > Base and other modules too for consistency. > > Code pointer: officecfg/registry/data/org/openoffice/Office/Accelerators.xcu I think consistency is easy to achieve if the shortcut is assigned globally. It is just necessary to check that it is not shadowed by an assignment in some other module. Apropos consistency: Why do Base forms use Alt+Backspace for Undo? Other components of LibreOffice use Ctrl+Z instead.
(In reply to Albrecht Müller from comment #10) > Careful: Ctrl+Shift+F6 clashes with Calc's function to enter a mode that > allows to define fixed and scrollable parts of a table using cursor keys. I > suspect that this is hardcoded. Never seen this. > ...combinations with F6 are used to cycle through various screen areas or forms. As commented above, we use F6 and ctrl+F6 as well for accessibility. And that's why the shift+ctrl+f6 comes in mind. > Did you consider combinations with the F10 function key? No, and I wouldn't do. > Apropos consistency: Why do Base forms use Alt+Backspace for Undo? Other > components of LibreOffice use Ctrl+Z instead. Off topic here, please file another ticket if you think another shortcut needs to be changed. In general, we should be very careful here since users might became used to it.
(In reply to Heiko Tietze from comment #7) > PS: If you are able to reproduce the crash reliably please file another > ticket with a short description and a link to this attachment. Created bug 147799 to show the crash when trying to open text documents containing form controls with keyboard shortcuts. Document was prepared using LibreOffice version 6.4.7.2 and Ubuntu 20.04 where defining keyboard shortcuts is possible. The document crashes the Windows version only.
(In reply to Heiko Tietze from comment #11) > (In reply to Albrecht Müller from comment #10) > > Careful: Ctrl+Shift+F6 clashes with Calc's function to enter a mode that > > allows to define fixed and scrollable parts of a table using cursor keys. I > > suspect that this is hardcoded. > Never seen this. Open some Calc document. Press Ctrl+Shift+F6. Then press the cursor keys. Depending on the keys you press a vertical and a horizontal line will appear that you can move using the cursor keys. Press enter when done. This splits the spreadsheet in up to four areas where you can see different parts of it. The behaviour depends on the state of the spreadsheet: If the spreadsheet has fixed parts then the cursor keys move the borders of these parts. If there are no fixed areas then the area of the spreadsheet is partitioned as described above. Unfortunately I do not know a shortcut that allows you to select the different areas. I don't write separate bug reports for the other problems: - The missing keyboard shortcut. Maybe the necessary shortcut exists but then there is a problem with the ux-discovery design principle and/or the help information. - When changing the selected area using mouse clicks the macro recorder does not record a command that does the area switch.
(In reply to Heiko Tietze from comment #11) > > ...combinations with F6 are used to cycle through various screen areas or forms. > As commented above, we use F6 and ctrl+F6 as well for accessibility. And > that's why the shift+ctrl+f6 comes in mind. > > > Did you consider combinations with the F10 function key? > No, and I wouldn't do. > On the page https://wiki.documentfoundation.org/Design/Guidelines/HIG_foundations#UX_Manifesto I found the sentence "Familiarity (the dialog should be consistent with user’s expectations)". This page also refers to the design principles page (https://wiki.documentfoundation.org/Design/Principles#Speedy) where I found the ux-consistency principle: "Software should be internally consistent with itself and externally consistent with similar interfaces to leverage the user's existing knowledge, unless this would be detrimental to usability. [Source: Nielsen]" It may be helpful to know what the user's expectations are and what their existing knowledge is. That's why I did some research on the shortcut Ctrl+Shift+F6. I now think this shortcut belongs to a set of related keys that has had well established meaning for a quarter of a century. I would summarize my current knowledge like this: The function key F6 is used to navigate through various parts of an application. The combination with the Shift key usually (there are exceptions) reverses the direction of navigation. F6 and Shift+F6 visit several parts within some window such as menu, toolbars, and content window. Together with Ctrl or Alt the F6 key switches between different contents, e.g. between different files loaded into the same application. There are slight variations between Ubuntu and Windows. Ubuntu has a built in generic OS support for the Alt+F6 and Alt+Shift+F6 keyboard shortcut combinations which work roughly like the Super+` and Super+Shift+` shortcuts. They switch between different windows of the same application. Windows has no such generic support and expects that applications implement this functionality themselves in a way that is tailored to their specific needs. MS-Access 97 for example uses Strg+F6 and Strg+Shift+F6 to switch between different forms that belong to the same database. MS-Excel 97 switches between the open files. LibreOffice seems to rely on the OS support and therefore does not offer this functionality under Windows. Therefore I think that there is a considerable number of users that are familiar with these semantics of the F6 key. They would probably expect that the shortcut Strg+Shift+F6 would shift the focus backwards between open Writer or Calc windows or between forms that belong to a Base document. This means that the current function of the Strg+Shift+F6 in Calc and it's proposed use both violate the ux-consistency principle and therefore might considered as bugs. The current use of the Strg+F6 key is probably also not consistent with user expectations.
(In reply to Heiko Tietze from comment #11) > > Apropos consistency: Why do Base forms use Alt+Backspace for Undo? Other > > components of LibreOffice use Ctrl+Z instead. > > Off topic here, please file another ticket if you think another shortcut > needs to be changed. According to my experience the benefits of filing tickets are very limited. The one-bug-at-a-time rule would inflate attachment 178256 [details] to thousands of bug reports. I gave up filing tickets almost completely. Instead, I collect notes that help me to deal with issues I run into. As this proved useful I have more than 1000 pages already … > In general, we should be very careful here since users might became > used to it. That's why I think it's so important to define the right shortcut here. The hard part is to find a suitable keyboard shortcut for a function that is necessary due to a pretty weird feature: LibreOffice allows you to create documents that contain controls that build a complete user interface. By default you can use this interface to enter information into various text controls or check boxes, but you can also delete the submit button that should start processing the content you just entered. Try this using the attachment 178256 [details]. Delete some paragraph where a control is anchored on: The control is gone too. I think this violates the ux-error-prevention principle. Another examples underlines why it's important to find the right shortcut keys: In the attachment, section "ZERO WIDTH SPACE" explains how an inconsistency in the definition of keyboard shortcuts may cause loss of data when you try to insert this character. There is also a clash with the sequence Ctrl+A, Ctrl+K, Ctrl+V, Enter. Used with Firefox this executes a harmless and common operation: The browser usually will display the results of a web search using a query from the clipboard. The Ctrl+A key is irrelevant for this operation. LibreOffice will execute an operation that is probably not intended and usually causes considerable damage to text documents. It contains no safeguard against the unintended execution of this operation. (ux-error-prevention principle!) In the meantime I think that Ctrl+Z and Alt+Backspace are synonyms. Users may think that they have to use Ctrl+Z in some modules of LibreOffice and Alt+Backspace in others as the menu entries for Undo show either the Ctrl+Z or the Alt+Backspace shortcut but not both.
Created attachment 178680 [details] 178256: Contains background information to bug 146906, tries to demonstrate the problem and describes problems encountered when creating the demonstration. Fixed a typo (ZERO WIDH SPACE)
(In reply to Albrecht Müller from comment #15) > (In reply to Heiko Tietze from comment #11) > > > Apropos consistency: Why do Base forms use Alt+Backspace for Undo? Other > > > components of LibreOffice use Ctrl+Z instead. > > > > Off topic here, please file another ticket if you think another shortcut > > needs to be changed. > > According to my experience the benefits of filing tickets are very limited. > The one-bug-at-a-time rule would inflate attachment 178256 [details] to > thousands of bug reports. I gave up filing tickets almost completely. > Instead, I collect notes that help me to deal with issues I run into. As > this proved useful I have more than 1000 pages already … 8 of your reports are fixed/worksforme while 20 are still open. I would say that is far from "very limited". Your "thousands of bug reports" is of course hyperbole, but I recommend to watch my presentation of someone who actually did that: https://www.youtube.com/watch?v=LHrmDPMMGak
(In reply to Buovjaga from comment #17) > 8 of your reports are fixed/worksforme while 20 are still open. I would say > that is far from "very limited". Your "thousands of bug reports" is of > course hyperbole, but I recommend to watch my presentation of someone who > actually did that: https://www.youtube.com/watch?v=LHrmDPMMGak Lets's look at the problem at hand instead of discussing statistics: What is my benefit when this bug is solved? I will have to throw away the solution I found, learn a new keyboard shortcut and have to find ways to merge the keyboard shortcuts definition of a new version of LibreOffice with those I defined. Thus from my point of view the most efficient way is not to report the bug and take a note how to deal with the problem, e.g. stating that I have to define some other key for the toggle focus function. Thus we could close this bug with "WORKSFORME". This would be nice for statistics but would not improve LibreOffice. The help information of LibreOffice describes StarBasic functions such as CreateUnoStruct, CBool and a lot of other functions. To my knowledge it does not describe dispatch commands or UNO functionality. If you visit https://wiki.documentfoundation.org/Development/DispatchCommands and https://api.libreoffice.org/docs/idl/ref/namespaces.html (on this page click on detail level 7 to see the full tree) you will see that there are thousands of dispatch commands and UNO constructs. For some context look into the "What is missing?" section of the attachment. The one-bug-at-a-time philosophy would require to write a bug report for each missing description. These are the thousands of bug reports I mentioned.
(In reply to Albrecht Müller from comment #18) > The help information of LibreOffice describes StarBasic functions such as > CreateUnoStruct, CBool and a lot of other functions. To my knowledge it does > not describe dispatch commands or UNO functionality. If you visit > https://wiki.documentfoundation.org/Development/DispatchCommands and > https://api.libreoffice.org/docs/idl/ref/namespaces.html (on this page click > on detail level 7 to see the full tree) you will see that there are > thousands of dispatch commands and UNO constructs. For some context look > into the "What is missing?" section of the attachment. The one-bug-at-a-time > philosophy would require to write a bug report for each missing description. > These are the thousands of bug reports I mentioned. The OpenOffice.org dev guide from 2009 has recently been imported into TDF wiki and I am merging the contents per chapter for easy discovery of information. Much of the API has remained stable over the years, but now we can update the guide. People are already updating the contents, getting rid of obsolete stuff etc. For the WIP, see https://wiki.documentfoundation.org/Documentation/DevGuide
(In reply to Albrecht Müller from comment #13) > Open some Calc document. Press Ctrl+Shift+F6. Then press the cursor keys... Does not work for me (Linux/kf5). But the function is known. According to sc/README.md (https://opengrok.libreoffice.org/xref/core/sc/README.md?r=ea5641ba) | ### CTRL+SHIFT+F6 | Dumps the SfxItemSet representing the cell properties' of the | current selection as a xml file. The file will be named dump.xml Looking into the code (sc/source/ui/view/gridwin.cxx) I found this: ScGridWindow::KeyInput(const KeyEvent& rKEvt) ... #ifdef DBG_UTIL if (rKeyCode.IsMod1() && rKeyCode.IsShift()) ... else if (rKeyCode.GetCode() == KEY_F6) dumpCellProperties(); I'd prefer to remove this shortcut(s, there are some more). Eike, any concerns? (In reply to Albrecht Müller from comment #14) > The function key F6 is used to navigate through various parts of an > application. The combination with the Shift key usually (there are > exceptions) reverses the direction of navigation. Thanks for your thorough analysis. Would come to a slightly different conclusion: F6 (with modifiers) is used to make the UI accessible. We have this rule incorporated in the sidebar HIG (https://wiki.documentfoundation.org/Design/Guidelines/Sidebar). That's why Shift+Ctrl+F6 sounds best to me. Side note: This website is informative for comparing shortcuts https://defkey.com/what-means/alt-f5 and https://defkey.com/search?irq=Shift%20%2B%20Alt%20%2B%20F6
(In reply to Heiko Tietze from comment #20) > | ### CTRL+SHIFT+F6 > | Dumps the SfxItemSet representing the cell properties' of the > | current selection as a xml file. The file will be named dump.xml > > Looking into the code (sc/source/ui/view/gridwin.cxx) I found this: > ScGridWindow::KeyInput(const KeyEvent& rKEvt) > ... > #ifdef DBG_UTIL > if (rKeyCode.IsMod1() && rKeyCode.IsShift()) > ... > else if (rKeyCode.GetCode() == KEY_F6) > dumpCellProperties(); > > I'd prefer to remove this shortcut(s, there are some more). Eike, any > concerns? I'm against removing as we need some means to access those dump facilities. If it conflicts, rather find a better shortcut.
(In reply to Eike Rathke from comment #21) > ...we need some means to access those dump facilities. If this was a user request I'd say WF due to unclear use case ;-). What if we change the dump shortcuts to require shift+mod1+mod2+<key>?
FWIW the Writer and Impress way is that SW_DEBUG=1 / SD_DEBUG=1 is needed, then some F<number> shortcuts invoke debug functionality. Perhaps Calc could do the same, then users get their F6 and devs get the debug F6 when they opt in.
(In reply to Heiko Tietze from comment #20) > Thanks for your thorough analysis. Would come to a slightly different > conclusion: F6 (with modifiers) is used to make the UI accessible. We have > this rule incorporated in the sidebar HIG > (https://wiki.documentfoundation.org/Design/Guidelines/Sidebar). That's why > Shift+Ctrl+F6 sounds best to me. > > Side note: This website is informative for comparing shortcuts > https://defkey.com/what-means/alt-f5 and > https://defkey.com/search?irq=Shift%20%2B%20Alt%20%2B%20F6 Did you ever try https://defkey.com/what-means/ctrl-shift-f6 ? What I found there: Microsoft Word 2019 : Goto previous window Opera: Switch to previous tab Adobe Illustrator: Navigate to previous document SSMS: Move to previous document Adobe Acrobat 2017: Move to previous open document window Microsoft Front Page: Switch to previous window IBM Cobol Editor: Previous Editor Micosoft Teams: Goto previous section Bluebeam Revu: Previous document Microsoft Access 2019: Switch to next or previous database window Microsoft Power Apps: Move to previous stream MindManager 21: View previous map Sage 50: Move to previous window Tableau: Cycle backward through open worksheets I don't think that users would expect that this key combination would toggle the keyboard focus between text and controls. I think the sidebar guideline probably did not consider a well established use of the Ctrl+F6 and Ctrl+Shift+F6 key combinations. LibreOffice does not offer a common functionality and due to the use of the Ctrl+F6 combination in the sidebar it probably cannot offer it. Remark: My proposal to use Alt+F5 was motivated by the idea to remove the clash with a as little a change as possible, just by using a different modifier key. That's a workaround for me but probably not the best shortcut for this purpose.
In the French version, the shortcut [Alt Gr]+[2] to make a tilde (~) does not work, but opens or closes the styles pane.
Hi, In relation with the previous post, I also have a keyboard shortcut conflict (although, not with CTRL+F5, but we were advised on the user forum to comment this issue). Use case : in Writer, using the french UI and a Belgian keyboard layout, inserting a tilde is supposed to be done using AltGr++ (the key next to the right shift is common to +, = and ~). When hitting AltGr++ in Writer, we are swithed to the formula insertion mode. Removing shortcuts in the keyboard customization didn't help (there doesn't seem to have shortcut customization for the AltGr key, only for Alt) Regards, K.
Hi Noben, (In reply to Noben K from comment #26) > In relation with the previous post, I also have a keyboard shortcut conflict > (although, not with CTRL+F5, but we were advised on the user forum to > comment this issue). Since it is another issue/key stroke, please search for that specific case, or feel free to create a new report. Thanks :) Cor
On the original issue of using the keyboard to swap focus between document and controls. Ctrl+F5 and Ctrl+F6 were obviously intended (and still work if not over-ridden) as 'focus to controls' and 'focus to document' respectively. (Clear Ctrl+F5 of the 'Sidebar' function in Customise > Tools for the Libre program you're in, and it will work as 'focus to controls'.) Ctrl+F6 was reserved, and not over-ridden, but Ctrl+F5 was not reserved and has been over-ridden by the Sidebar toggle. Is there any reason why Ctrl+F6 cannot become a genuine *toggle* between control focus and document focus? ie: if document is current focus, Ctrl+F6 moves focus to controls (if there are any), if controls are current focus Ctrl+F6 moves focus to the document. Then we don't need to find some other key combination for 'focus to controls', and Ctrl+F5 can remain as the Sidebar toggle. I'm not sure what should happen to the 'Control Focus' function in Customise > Tools (.uno:ToggleControlFocus), if anything, if this change is made.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/854107d275aac0f4042a154145b95c34543f24c5 Resolves tdf#146906 - Keyboard shortcut conflict: Ctrl+F5 It will be available in 25.2.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.
(In reply to Commit Notification from comment #29) > Heiko Tietze committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > 854107d275aac0f4042a154145b95c34543f24c5 > > Resolves tdf#146906 - Keyboard shortcut conflict: Ctrl+F5 > > It will be available in 25.2.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. I checked that there is no mention of the shortcut in Help, so no need to update anything there.
Created attachment 196365 [details] Screencast for discussion in https://gerrit.libreoffice.org/c/core/+/173122
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2ac51182e63c109bb44334f86b6ab3bcdf247494 Related tdf#146906 - Remove hard-coded access to split window It will be available in 25.2.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.
(In reply to Innesw from comment #28) > Is there any reason why Ctrl+F6 cannot become a genuine *toggle* between > control focus and document focus? ie: if document is current focus, Ctrl+F6 > moves focus to controls (if there are any), if controls are current focus > Ctrl+F6 moves focus to the document. Then we don't need to find some other > key combination for 'focus to controls', and Ctrl+F5 can remain as the > Sidebar toggle. If there is no undesired interference with getting the focus to the document from other UI elements, that should be fine. (Can't test anything in Ubuntu 24.04 with Gnome though .. )
The patch implemented (#comment29) seems to be a simplistic fix of 'Ctrl+F5 may do two things, therefore remove one of them'. It does not resolve the fundamental issue. Ctrl+F6 moves the focus from the form controls to the document. There needs to be a way, using the keyboard, of moving the focus from the document to the form controls. Ctrl+F5 used to do that, before it was overridden by the sidebar toggle. Some of the previous discussion was about finding an alternative keystroke to Ctrl+F5 for the action. My suggestion was for Ctrl+F6 to switch the focus in both directions. I asked if there was any reason why this could not work. As yet nobody has provided such a reason.