Created attachment 159379 [details]
sidebar size on 15" screen

Looks too wide when docked. Wasnt' so in LO 6.4. So that would be a regression, at least until we see the reason it's widened and if that was well though of.

Created attachment 159391 [details]
resonable sidebar width on windows builds

Not seeing this on Windows builds of master.

Version: 7.0.0.0.alpha0+ (x64)
Build ID: 962b415edb47187737a5f05c4ff3f6724a19c564
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

Created attachment 159396 [details]
sidebar compared 6.4 7.0+

A few pixels more due to welding of controls, IIRC. Far from 30% as shown by OP, so unconfirmed.

As from the UX POV the sidebar has a reasonable width. Very small screens are just not suited for this UI and should consider alternatives (View > User Interface). => WFM

@Heiko, OPs clip in attachment 159379 [details] is more than a couple of pixels!

If they are unable to drag the Sidebar Deck narrower on gtk3 this is a glitch in the Welding.

https://bugs.documentfoundation.org/show_bug.cgi?id=130197 wanted to set writer sidebar to ~about all the same width, the table panel is approx 10 toolbar buttons wide so this pane is also set to approx 10 toolbar buttons wide so the width is determined by the width of the themes toolbar buttons, so the width of this panel basically depends on the width of the table pane. If someone wants to make the panel narrower the table pane is the thing that needs to be changed to allow loosening the width of the paragraph pane

(In reply to Caolán McNamara from comment #7)
> https://bugs.documentfoundation.org/show_bug.cgi?id=130197 wanted to set
> writer sidebar to ~about all the same width, the table panel is approx 10
> toolbar buttons wide so this pane is also set to approx 10 toolbar buttons
> wide so the width is determined by the width of the themes toolbar buttons,
>...

OK, but clip attachment 159379 [details] appears a lot more than 10 toolbar button in width, with much of the extra width in the spin buttons as Adreas was concerned with in bug 131097

> was concerned with in bug 131097

s/131097/bug 130197

This problem is definitely reproducable (v7.0.0.3, Windows 10 64-bit, 2004 build).

It seems to occur when text scaling is greater than 100%.  The greater the scaling above 100%, the greater the minimum sidebar width.

Sorry, to be clear:

It seems to occur when WINDOWS text scaling is greater than 100% (not scaling in LibreOffice).

(In reply to Simon Garrett from comment #11)
> Sorry, to be clear:
> 
> It seems to occur when WINDOWS text scaling is greater than 100% (not
> scaling in LibreOffice).

Yes but that is bug 128243 where I just added attachment 164332 [details]
<clip>
Sidebar deck on 1920x1080 (148ppi screen) w custom scaling set at 225%

This clip shows effect of WDM scaling to 225% on *minimum* width of the Writer sidebar Properties deck with the Table content panel showing.  

@Caolán, * -- excessive width is not the Table content panel as suggested in bug 130197 for aligning content, but seems to reside still in calculating the spin box width size when DE scaling is applied.
</clip>

Not clear if for gtk3, or the other vcl backends, on Linux the spacing on scaled UI is an issue. But it is for sure on Windows builds with the WDM scalling UI.

I am also experiencing this issue of excessive minimum width of the sidebar. I like to have the navigator open at all times and document zoom at 120%, but the sidebar's width overlaps with the page at that point. It's very irritating to be unable to reduce the width of the sidebar farther, especially since there don't seem to be any elements which demand the excess space. I would much prefer being able to collapse the sidebar in a way that distorts it to being forced to adhere to a fat minimum width.

My LO version is 7.1, but I've been experiencing it since at least 6.4.

My laptop screen is ~17", resolution of 1920x1080, and screen scaling at recommended setting of 150%.

*** Bug 136428 has been marked as a duplicate of this bug. ***

Setting os to ALL as dupe had Win and Linux reports.

Maybe a weld glitch in calculating 10 'toolbutton' widths for layout of SB content panels in two aligned columns [1] (see bug 130197 ).

And apparently that calculated spacing can get very off when the os/DE UI is scaled, e.g. bug 128243

@Caolán, please would you take another look.

=-ref-=
[1] https://gerrit.libreoffice.org/c/core/+/87462

Understand this as a Windows bug since the sidebar width is okay on Linux.

As a general comment, the design team discussed the topic. The initial width of the sidebar should be defined by the deck with the larges controls. By doing so we avoid jumping UIs. But we also want to allow users to reduce the sidebar width per deck. No deck should be resizable beyond the width of its controls (it's always possible to collapse the sidebar or hide completely). Switching between decks must not change the user defined width of the deck.

*** Bug 136793 has been marked as a duplicate of this bug. ***

(In reply to Heiko Tietze from comment #16)
> Understand this as a Windows bug since the sidebar width is okay on Linux.
> 
> As a general comment, the design team discussed the topic. The initial width
> of the sidebar should be defined by the deck with the larges controls. By
> doing so we avoid jumping UIs. But we also want to allow users to reduce the
> sidebar width per deck. No deck should be resizable beyond the width of its
> controls (it's always possible to collapse the sidebar or hide completely).
> Switching between decks must not change the user defined width of the deck.


It is also a Linux bug. I reported on this a few weeks ago concerning LO 7, documenting with a video; but my bug report has somehow disappeared.

Current (version 7.0.2.2) behavior is as follows: Opening the Styles sidebar (CTRL-F5) puts it to the width of 8 icons arranged horizontally on its top bar. The user can even (and unnecessarily) _expand_ this further; but he is not allowed to shrink it. This was allowed in earlier LO Writer versions. To allow for it does not mean satisfying discretionary whims of users. It simply makes no sense to make this sidebar wider than the longest style name listed in it.

Still the same situation with 7.1 beta and 7.0.4.1. Is there any way I can help to get rid of this problem without programming skills?

Just to confirm that I see the same problem in all windows versions of 7.x up to and including 7.1.0 beta 1. The waste of space is considerable on small screens. When using styles, which I know well, I only need to see the first few characters of the style name to be able to select the correct one. The much greater ability to resize downward the sidebar seen in 6.x (and before) is much better than now available in 7.x.

UX Design decision ( see https://bugs.documentfoundation.org/show_bug.cgi?id=90374#c40 )was to eliminate the ability to drag Sidebar width below the minimum where all controls are visible. That is a change for some decks where it was possible to start to hide controls. It also established that a default opening width for the Sidebar wold be calculated, but that user could adjust down to the minimum per deck of the controls visible.

That is, the minimum width for a deck will now be the calculated width of its exposed controls. Uses can control that by selecting Small or Large icon size for the Sidebar (Tools -> Options -> View).

And, this issue while valid is now a clear WF.

Unfortunately, UI scaling (e.g. for HiDPI support ) for some os/DE the control widths can be miscalculated as for Windows WDM with UI scaling (bug 128243).

Two considerations may be added to this design decision:

1) The same reasoning obviously has not applied to the Navigation bar, whose width can be shrunk such that some controls get hidden.

2) That all controls should remain visible may or may not be a reasonable requirement. However, there is more than one way to guarantee this. For instance, the top line of the bar containing the controls could undergo line-break. Or the controls could be arranged in two lines from start, instead of one - far too long - line, as it is now.

Created attachment 167803 [details]
Page sidedar - much wider than the contents

In attached picture you can see that page tab shrink to minimum is nearly twice wider than it's contents. Even if the idea of this feature was to avoid hiding of control elements, implementation is ugly.

Thank you for indicating that this was a deliberate design change, not a regression or other bug. It looks like I will be left using 6.4 for the time being.

While I note the discussion, it never appeared to me to be broken in 6.4 in a way which required fixing (to a non-programmer). I agree with Mr Lehmann that there are other alternatives. It is perhaps a little weird that the style and formatting panel can be shrunk in 6.x in a way which causes the icons at the top to disappear with no clue that they are hidden. Two rows as suggested would be one alternative or perhaps a down-pointing black arrowhead might appear once icons were hidden to show that there were hidden icons (as can happen to tray icons in the windows taskbar, for example).

I second Christian's suggestion of multiple rows. That seems like a very commonsensical fix which maintains visibility of the controls while providing a lot more flexibility in the sidebar's width.

In my opinion this is a serious layout issue. If I were to start using LO today (instead of around a decade ago, counting OpenOffice), it's the kind of problem that could turn me off to Writer right away and send me back to MS Office.

(In reply to Christian Lehmann from comment #23)
> Two considerations may be added to this design decision:
> 
> 1) The same reasoning obviously has not applied to the Navigation bar, whose
> width can be shrunk such that some controls get hidden.
> 

Not with current 7.1.0 or master/7.2.0 the Navigator's minimum width is the combined width of the 'Navigate by' and the 'Go to Page' listbox and button controls. Unfortunately wider than they need to be on Windows os/DE. They can no longer be slid hidden.

(In reply to Apt from comment #26)
> I second Christian's suggestion of multiple rows. That seems like a very
> commonsensical fix which maintains visibility of the controls while
> providing a lot more flexibility in the sidebar's width.
> 

No, allowing the Sidebar Deck and its Content panels to shuffle controls--to maintain visibility but loose context--is no solution, and would be worse UX than the simple 'slide hidden to collapse' of the original implementation.

The UX agreed fixed minimum / no-hiding has its issues, especially with os/DE scaling in use for HiDPI. But correctly handling the out of control width calculation should bring improvement.

Thanks for the reply, Stuart. If a mitigation measure like multiple rows is not acceptable to the designers, I do hope the incorrect width fix is not too delayed then. At the moment this is my second biggest issue w/ LO.

Ad comment 27,
"No, allowing the Sidebar Deck and its Content panels to shuffle controls--to maintain visibility but loose context--is no solution, and would be worse UX than the simple 'slide hidden to collapse' of the original implementation."

At the risk of misunderstanding the jargon: It seems that no argument has been offered in favor of reducing the user's screen space by a rectangle dominated by a stiff horizontal line of controls. If the suggestions for remedy offered by users do not seem to be workable to developers, then it seems to be their task to find a method of revising a wrong design decision.

Just for clarification: It is not a just question of reducing the size of the icons and their spacing a bit. The point is that, in order to display the styles' names, at most _half_ of the width currently allotted to the styles bar is needed.

(In reply to Christian Lehmann from comment #30)
> Just for clarification: It is not a just question of reducing the size of
> the icons and their spacing a bit. The point is that, in order to display
> the styles' names, at most _half_ of the width currently allotted to the
> styles bar is needed.

The Sidebar controls are reasonably sized. Also, the Sidebar can be undocked to float where unobtrusive.

There is an issue for the Windows builds where the WDM os/DE scaling of the UI beyond 100% is not correctly applied to the controls. That is open as bug 128243, the Linux os/DE on VCL backends do not apparently suffer the same distortion.

If you are on a Windows build, the correct relationship of the controls will appear at 100% scaling--which of course is too small for effective use on a HiDPI screen.

Design decision applicable to all Decks/Content panels of the Sidebar is to *not* hide any of the controls, and to establish a minimum width calculated for each deck so that all of its controls are visible.  Allowing the controls to shuffle would not help as it would loose context, but also would increase the vertical height of the Deck--not a solutions and horrible UX.

Before it was decided not to hide controls, some Decks were allowed to reduce width hiding controls--until the deck would collapse to show the Tab bar. That function has been removed, and now with no controls hidden the Deck will immediately collapse when the Tab bar buttons are double clicked.

For reference so you can use the correct terminology...

Nomenclature of components on the Sidebar are as here: https://wiki.documentfoundation.org/File:LO-HIG_SideeBar-Terminology.png

Design discussion is as here:
https://wiki.documentfoundation.org/Design/Guidelines/Sidebar

Thanks for the clarification. However, why don't you take up the argument (by myself and quite a few users by now) that the deck has double the width that it would need? It occupies space on the screen whether you float it or dock it. And believe me it is just the same on Linux, as has been demonstrated by screen shots and even videos.

I would not argue against the design decision of not hiding any of the controls, as I have to admit to having been a victim to missing controls that I myself had previously hidden.

However, I still miss an argument why the controls cannot be arranged in two rows from start, esp. if the same is acceptable on the navigation bar (and in several other menu windows, for that matter).

(In reply to Christian Lehmann from comment #32)
> ...
> However, I still miss an argument why the controls cannot be arranged in two
> rows from start, esp. if the same is acceptable on the navigation bar (and
> in several other menu windows, for that matter).

You of course mean the Navigator <F5> deck, the 'Navigation Bar' is a standard two button toolbar.

The Navigator deck (floating <F5>, or Sidebar resident) is constrained as all other decks.  The Content panel controls are in two rows because that is what functionally makes sense--while the deck width is controlled by the Navigate by listbox, its Previous/Next buttons, and the Goto Page spin box. Or rather by the calculated width of those controls.

The layout of the Sidebar is deliberate and suited to task.

There is nothing to be gained by reworking the content panels of the decks into layouts that consume vertical space to reduce width of the deck, and a lot to be lost by losing the contextual relationship between blocks of controls.

The Sidebar assemblage was always intended to optimize visibility of controls by making use of the extra horizontal space on a display. As opposed to the menu/toolbar paradigm alone which consumes vertical space on the display to expose more controls.

Okay, this is evidently a different weighing of priorities. Users like the ones on this bug discussion list, who have less than 30" monitor size and need to work with more than one Writer window open will have to revert to version 6.4.

(In reply to Christian Lehmann from comment #34)
> Okay, this is evidently a different weighing of priorities. Users like the
> ones on this bug discussion list, who have less than 30" monitor size and
> need to work with more than one Writer window open will have to revert to
> version 6.4.

Wow that is kind of a misstatement of fact. There is almost no difference in control width layout between the 6.4 and 7.0 releases. 

Otherwise users on Linux are pretty much unaffected by UI scaling, and those on Windows are only affected when they have scaled their UI above about 150%. 

If you do not like the Sidebar deck showing, collapse it to the Tab bar or use the 'Hide'/'Show' thumbs to fully collapse--or close the Sidebar completely. Perhaps use one of the MUFFIN layouts--the 'Single Contextual' with the Sidbar collapsed is rather functions.

What os/DE and scaling are you working with?

(In reply to V Stuart Foote from comment #33)
> 
> 
> The Sidebar assemblage was always intended to optimize visibility of
> controls by making use of the extra horizontal space on a display. As
> opposed to the menu/toolbar paradigm alone which consumes vertical space on
> the display to expose more controls.

So, the conclusion is reduce working space to get visible all the nice stuff in sidebar. Sounds like programming for programmers, like somebody using alternative office is doing programming for libreoffice, which he/she is not using and do not considers that somebody else is really using it. 

Besides, about half of vertical area in sidebar is not used in Properties and some other views and horizontal space is used very inefficiently, e.g. in Page view.
To my understanding more work space should be prioritized instead of continuous visibility of all the stuff in the sidebar. I don't understand this discussion, somebody made mistake and it should be corrected.

Of course, I can survive without sidebar, I'm already closing it, because it is not possible to work in Writer with sidebar on, but it was really nice addition in Libreoffice and it is still nice in alternative products. I'm using star/open/libreoffice since 199x and I will continue to use it and pay annual donations, but it would be nice not to propose mistakes as innovations.

OK, with nothing substantive being proposed, guess this can be closed => NAB

Likewise as enhancement request to modify Sidebar GUI layout, seems non-actionable and a clear => WF

Sad to hear such absolutely non-substantiated decision. Thanks' to such decisions it becomes very hard to tempt somebody to stay with Libreoffice.

In our company will find better use for money booked for donation to Libreoffice this year.

Stuart, thank you for the work you've done so far on the underlying issue, which as I understand it is the incorrect width calculation for the sidebar with UI scaling applied. If the fix for this is a ways off, would it be feasible to temporarily add an option (off by default and perhaps featuring a warning) to turn off the minimum width restriction for the sidebar so that users like me can rely on it as a mitigation for the issue of excessive minimum width?

(In reply to Apt from comment #39)
> Stuart, thank you for the work you've done so far on the underlying issue,
> which as I understand it is the incorrect width calculation for the sidebar
> with UI scaling applied. If the fix for this is a ways off, would it be
> feasible to temporarily add an option (off by default and perhaps featuring
> a warning) to turn off the minimum width restriction for the sidebar so that
> users like me can rely on it as a mitigation for the issue of excessive
> minimum width?

I like the idea of an expert option. Would you mind to file a new ticket, ideally with reference to this one? 

c16 and c22 make it clear why we have a minimum width, thus resolution here is WF.

I was also thinking of a way out of the dilemma. Appreciating the argument of leaving symbols together which belong together, one might consider the alternative of a vertical instead of horizontal arrangement. The user has this option for most of the symbol bars. The present one would neatly fit below the vertical bar which comes along with the styles (five symbols: settings, properties, page, templates, gallery). The bar at issue might be separated from this one by a separator. As a result, the user would see together what belongs together, would see separated what must be separated, and could adjust the templates panel to the width desired.

Thanks for the reply, Heiko. Here is the new ticket I submitted: https://bugs.documentfoundation.org/show_bug.cgi?id=140360

setting back to the agreed resolved wontfix.

See also bug 140360 in place for an expert configuration toggle to enable a "slide to collapse" for all Sidebar Decks to supplement the fixed "minimum" width assignments they now have (corresponding to fully displaying their controls).

*** Bug 141961 has been marked as a duplicate of this bug. ***

*** Bug 141952 has been marked as a duplicate of this bug. ***

*** Bug 140214 has been marked as a duplicate of this bug. ***

I don't understand the comment No 43. There are no such preferences in Expert configuration - slide to collapse. I would be thankful for more detailed instructions. I'm tired from this ugly sidebar.

Can't imagine who could consider this as an improvement.

(In reply to andis.lazdins from comment #47)
> I don't understand the comment No 43. There are no such preferences in
> Expert configuration - slide to collapse.

That's right. And therefore we have enhancement request in bug 140360.

HI there. Thanks for your work so far. i'm just a random user who has been bored with this limitation, and opened a similar bug report, that lead to this one as a duplicate... 

I explain my point of to complete some of the previous users' request (such debate as programmer vs. "real" user) : i was used to almost collapsed side bar before V7 (as ("shrink with hidden icons", that i knew they were hidden but no need to use them) so i could navigate through text titles hierarchy (in navigator) and click on styles (on the other side's panel) while displaying a large readable document's text on small screen, or even working on two parallel documents windows tiled alongside in the same screen after buying new laptop. This was very practical, functional at least, and allowed to work quickly and efficiently in complex long hierarchised documents.
Yes it is possible to display as a separated floating element, but ergonomy is really different. Thus, pressing F5/F11 each time is another boring routine.

i have lots of other "comfort of use in routine" comments, but they should take part in some other bugs. Mainly, this side panels  are real great useful principles, just need some tweaking possibilities.

new UI design is great when thinking about 99% most common users perception, and "state of the art", but most of comments shows that previous "bad behaviour" hacks in the UI were very useful.

i suggest that user could display or not the panels icons ribbon as a separate collapsing sub-element (make me think about photoshop small windows management). vertical. Icon ribbon and main panel display (mainly navigator and styles list) are not always to be uses in the same routine. For instance i use a lot the main display, but never use the icons in panels.

(In reply to bentusiii@yahoo.fr from comment #49)
> ... i was used to almost collapsed side
> bar before V7 (as ("shrink with hidden icons", that i knew they were hidden
> ...

Yes that is understood, and as noted comment 22 shift to fixed minimum width per deck was by design and actually made the erratic behavior consistent.

Likewise per comment 40, bug 140360 is an enhancement to toggle prior behavior allowing deck to "reduce width to collapse", but consistently for all decks and LO modes.

Issue here remains WONTFIX