Description: Please create a shortcut key's combination to switch from one opened document to another opened document. In Word it's CTRL+F6. Thank you. Steps to Reproduce: 1.Open document. 2.Open another document. 3.Press CTRL+F6. 4. You easily change from one document to another. Actual Results: There is no short keys combination. Expected Results: Easily changing from one opened document to another opened document. Reproducible: Always User Profile Reset: No Additional Info: Thank you.
Sorry I shouldn't have done this proposal. Can't delete it. Take it as resolved. Thans.
On some os/DE the <Alt>+` (the Unicode U+0060 GRAVE ACCENT) moved between app frames of the LO module. While the main menu's 'Window' provides a lb to pick from--it requires some number of key strokes to reach the lb. Consistent handling across os/DE probably requires new UNO and explicit mapping of an accelerator.
What exactly do you understand as "opened document"? Is it two Writer text where you need to read A and type in B (using a small screen that allows only one view at a time) or is it a Writer text and a Calc sheet? In any case what is wrong with alt+tab or with alt+W + the mnemonic from the open document?
(In reply to Heiko Tietze from comment #3) > What exactly do you understand as "opened document"? Is it two Writer text > where you need to read A and type in B (using a small screen that allows > only one view at a time) or is it a Writer text and a Calc sheet? > > In any case what is wrong with alt+tab or with alt+W + the mnemonic from the > open document? When the current soffice.bin holds multiple documents, the main menu's 'Window' will list each document (for all the modules). Alt+W accelerator just opens that menu listing and then cursor reposition and selection is required. What is missing is direct movement (forward / backward within current LibreOffice instance) between documents on that list by keyboard action rather than multi-key entry for the menu selection. I.e a NextDocument/PreviousDocument UNO or maybe some indexed selection from the list of *open* documents (obviously distinct from documents on the MRU list which may or maynot be open).
(In reply to V Stuart Foote from comment #4) > What is missing is direct movement... Why do we need to invent wheels when OS provide everything? For sure we do not have all functions implemented that might exist, not even coffee making. But without a use case it's hard to follow a request. Still NI.
(In reply to Heiko Tietze from comment #5) > (In reply to V Stuart Foote from comment #4) > > What is missing is direct movement... > Why do we need to invent wheels when OS provide everything? For sure we do > not have all functions implemented that might exist, not even coffee making. > But without a use case it's hard to follow a request. Still NI. Well, on Windows at least, the os/DE does not isolate the soffice.bin and *all* open applications appear on the <Alt>+<Tab> selector. We provide the main menu listing as UI, so not unreasonable to provide direct keyboard access to toggle amongst open document instances of the current soffice.bin. Likewise we have the enhancement request for a MDI of bug 37134 that would likely expand on our current 'Window' menu controls.
My OS allows to configure the task switcher so it goes back to the last item in the stack. If you want to switch between more than two windows without the "hassle" to click on Windows or type alt+W, I'd still ask for a use case why we need to invent LibreOffice-OS.
Created attachment 197931 [details] Useful video to understand the proposal In order for me to explain the proposal more clearly, I kindly beg developers to watch this video. Thanks. https://app.screencast.com/usMX8aNamNfOF
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to V Stuart Foote from comment #4) > When the current soffice.bin holds multiple documents, the main menu's > 'Window' will list each document (for all the modules). Alt+W accelerator > just opens that menu listing and then cursor reposition and selection is > required. Indeed. Alas that is broken for me (bug 163555) > What is missing is direct movement (forward / backward within current > LibreOffice instance) between documents on that list by keyboard action > rather than multi-key entry for the menu selection. I.e a > NextDocument/PreviousDocument UNO or maybe some indexed selection from the > list of *open* documents (obviously distinct from documents on the MRU list > which may or maynot be open). I'm with Heiko that this is a matter of the OS handling various windows. (and for me also broken with bug 163555)
(In reply to icp from comment #8) > Created attachment 197931 [details] > Useful video to understand the proposal > > In order for me to explain the proposal more clearly, I kindly beg > developers to watch this video. Thanks. > https://app.screencast.com/usMX8aNamNfOF Thanks, That is about the navigator, manipulating with (order of) sections of the document. I miss any relation with "Add shortcut key combination for change from one document to another "
(In reply to icp from comment #8) > Created attachment 197931 [details] > Useful video to understand the proposal > > In order for me to explain the proposal more clearly, I kindly beg > developers to watch this video. Thanks. > https://app.screencast.com/usMX8aNamNfOF Yep that video seems to be a different issue of structured content movement within an open document, a feature already implemented in the SB Navigator deck (or its F5 "floating" instance). Not the topic of the original posting in comment 0 Otherwise seems behavior of the <Alt>+` *would* be os/DE specific as we do not define/assign QUOTELEFT_MOD2 (just the QUOTELEFT_MOD1 or MOD3 used for the sc formula toggle). Still think an ability to manipulate the lo soffice.bin instance (as is listed in the main menu 'Window' lb) would be useful UI and would benefit from UNO creation for customization.
We discussed the topic in the design meeting. MSO traverses through documents of the same module, ie. Word Doc1...DocN or Excel Sheet1...SheetN. LibreOffice's approach is one suite for all where all types of documents are treated equally. And we do list open documents under the menu entry Windows, and switching via mnemonic is possible. It could be easier if the list was numbered like "_1: Untitled 1.odt, _2: Untitled 2.odt, _3: Untitled1.ods, etc. But this has limitations and is not following the approach of Microsoft anyway. There is a) window management belongs to the OS, b) no clear use case that makes ctrl+F6 better than ctrl+tab, c) occupying a precious shortcut is odd, d) alternative access methods exist. Putting all together the request is not a solution => WF. Nevertheless, if a volunteer wants to implement the commands Next/Previous Window it should not be detrimental to usability. So keeping the request open.