When resizing the window to half-maximum, we can hide the sidebar, or instead switch it into a toolbar. This way the sidebar does not take too much horizontal space at that time, and uses the space when it is available. When even the vertical space is limited, only the content can be shown.
@Ajinkya, Thanks for posting, good suggestion. But, we can already fully hide/show (button at middle edge of frame), or show just Tab bar (new default), or fully close the Sidebar with <F5>, <F11> accelerators already in place to relaunch (working on others). With those options, simply don't see too much need for additional option to render sidebar/tab bar to a horizontal toolbar.
Indeed it isn't a difficult job, especially now that I came to know of the keyboard shortcuts. However, automating it would be one less step each time we midify the shape of the window. Also, I observe a slight inconsistency in the buttons in the sidebar and the toolbars, which can be removed in this way. Perhaps rather than putting a WONTFIX, it could be left open for anyone interested to take a look?
Done. So now, please more completely describe what you'd like to achieve--and where? In Sidebar/Tab bar, in Toolbars, or both? Details, and sketched mock-ups are helpful. And appreciated :-)
Hey Ajinkya, Thanks for dropping your suggestion in. :D So presently with the sidebar fully open, it has a size of approximately 270 pixels or more if you are on the properties tab. So if i resized LO's window to half of my screen width, the sidebar would take up half of the available window space. So in order to save a step for a user to have to hide the sidebar, it would be useful for the sidebar to fully collapse or collapse to just showing the sidebar tab buttons.
Thanks Jay for expressing my point more clearly and in more details. However, I would like to point out that there's nothing special in particular about a half-maximize, but the sidebar(s) should be adaptive depending on the available vertical and horizontal space. For example, in a tablet like surface, there might already be too limited space for the sidebar to come up by default even when maximized. I'll extend this problem a bit more by suggesting a case where the space is not strictly speaking limited, but an adaptive sidebar can be of use nonetheless. When using book view or two-page view in Writer (at ~75% zoom), opening the sidebar abruptly forces the document into one-page view. Instead, the sidebar could be drawn over the pages, leaving the viewport shape unchanged. Further, the sidebar could be drawn on the opposite side of the page where the cursor currently is, so that that page is left unhindered. This discussion can go on, adding further design problems as they come up. So if you believe I should file a separate bug for each of them, or discuss it somewhere else, like the Redmine, please let me know.
(In reply to Ajinkya Dahale from comment #5) > Thanks Jay for expressing my point more clearly and in more details. > However, I would like to point out that there's nothing special in > particular about a half-maximize, but the sidebar(s) should be adaptive > depending on the available vertical and horizontal space. For example, in a > tablet like surface, there might already be too limited space for the > sidebar to come up by default even when maximized. Because of smaller resolutions that the sidebar isnt opened fully by default and in a maximized view on a tablet (as that is the only way an app can be), the user has the option to open the sidebar fully or not. http://gs.statcounter.com/#tablet-resolution-ww-monthly-201411-201501 > I'll extend this problem a bit more by suggesting a case where the space is > not strictly speaking limited, but an adaptive sidebar can be of use > nonetheless. When using book view or two-page view in Writer (at ~75% zoom), > opening the sidebar abruptly forces the document into one-page view. > Instead, the sidebar could be drawn over the pages, leaving the viewport > shape unchanged. Further, the sidebar could be drawn on the opposite side of > the page where the cursor currently is, so that that page is left unhindered. Two-page view is incorrectly labelled when it actually is automatic view. In Book view, it does not behave this way. > This discussion can go on, adding further design problems as they come up. > So if you believe I should file a separate bug for each of them, or discuss > it somewhere else, like the Redmine, please let me know. Well bug reports are intended to address one problem and solve it, so if you have additional issues you want to address, then they would need to be in different bug reports. If you want to brainstorm an idea, redmine would be good for that.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
We have four options for the sidebar: * fully open * collapsed with tab bar open (after clicking the x on the deck) * minimized to just a few pixels (after clicking the expander button left of the deck) * closed Would say that is sufficient for all use cases (despite the fact of inconsistent behavior meaning different interactions for one function). Closing as WFM.