Bug Hunting Session
Bug 89014 - SIDEBAR: Adaptive Sidebar behaviour based on window size (e.g. while working with two LO sessions side by side)
Summary: SIDEBAR: Adaptive Sidebar behaviour based on window size (e.g. while working ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Sidebar-UI-UX
  Show dependency treegraph
 
Reported: 2015-02-01 16:36 UTC by Ajinkya Dahale
Modified: 2018-01-16 10:32 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ajinkya Dahale 2015-02-01 16:36:48 UTC
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.
Comment 1 V Stuart Foote 2015-02-01 16:52:49 UTC
@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.
Comment 2 Ajinkya Dahale 2015-02-01 17:48:35 UTC
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?
Comment 3 V Stuart Foote 2015-02-01 17:57:18 UTC
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 :-)
Comment 4 Yousuf Philips (jay) (retired) 2015-02-01 20:06:37 UTC
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.
Comment 5 Ajinkya Dahale 2015-02-02 12:12:51 UTC
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.
Comment 6 Yousuf Philips (jay) (retired) 2015-02-02 13:34:23 UTC
(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.
Comment 7 Robinson Tryon (qubit) 2016-08-25 04:45:05 UTC Comment hidden (obsolete)
Comment 8 Heiko Tietze 2018-01-16 10:32:32 UTC
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.