This is a followup to Bug 90374 which was a mess of different ideas. This is dealing with a specific problem in our UI. Steps to Reproduce: 1. Resize the 'Properties' panel 2. Note how how it has a minimum allowable width 3. Switch to 'Style' or "Galley" 4. Reduce width by +50% 5. Switch back to 'Properties' panel in the sidebar Note the properties panel is now in an invalid state. Controls are hidden and inaccessible. There is no way to scroll to reach the hidden elements. Other suites like Calligra, iWorks, WPS Office, and MS Office do not let you reduce panel size to a point where the UI elements are broken. When you switch to a panel that had a defined min value, the panel should be resized to meet those constraints.
And it is a trivial and consistent action to swipe the Deck size inward (to left) to open it past minimal width and swipe outward (to right) to drop it back to the decks minimum. I do prefer to be able to shrink all the decks past their minimum (I use Style or Gallery deck which allow shrink to collapse). Allowing me to give up exposure of some of the controls to be able to hold the document canvas at a set scale with fixed width. And I want my "customization" to profile to included these settings. As was noted on the the other WF issue, having the Sidbar deck expand and contract to a set minimum would be annoying as it would impact the canvas (obscure it or resize it depending on mode). The width controls for the decks are fine as the are, beleive Heiko had an idea of providing a "double hash" to indicate Content Panel controls hidden--and on click to expose (by drop list, or wrapped toolbar) the additional controls--or even fully expand to minimum width the deck.
IMHO => NAB, Sidebar Decks can be expanded from any collapsed state. But worth some additional dev work to implement a reasonable "minimum" for each deck (based on width of the widgets present on any deck) to snap open to--via a button action. But also should restore ability to shrink to collapse for _all_ decks. The UI already remembers the deck width--content panel to content panel--so this is likely better dev choice anyhow. And, there is the other facet of working polyglot. Changing local will expand contract the "minimum" widths depending on the string lengths for many of the list widgets and control labels.
(In reply to V Stuart Foote from comment #2) > But worth some additional dev work to implement a reasonable "minimum" for > each deck (based on width of the widgets present on any deck) to snap open > to--via a button action. That was what we agreed on, more or less. Otherwise we would have to show a horizontal scrollbar to indicate that controls are hidden.
Isn't this a duplicate of Bug 92317 or Bug 83526?
*** This bug has been marked as a duplicate of bug 90374 ***
Actually they all are dupes of bug 90374--Luke and Jay continue to be out voted, so => WF
No, this is not a dupes of bug 90374. That is an enhancement about having "a fixed width across ALL tabs". This is about tabs that already have a defined MINIMUM width. The minimum width can be circumvented by following the steps above. This is a bug.
This is in essence a dupe of bug 90374; it describes the same issue. If the issue is present as problem (bug 90374) or solution (enhancement, comment 7) doesn't matter. I personally agree with Luke, it's a bug. A minor one though. Different minimum sizes is unexpected and counter-intuitive for the basic - regular? - user (surprise effect). -- Some basic question in advance (which someone should answer first) * Why are there minimum deck size? -> * Why a the minimum/maximum sizes of the decks a shared setting? -> Visual consistency? -- Personal opinion: -> It's illogical: if we acknowledge the need for minimum sizes, then we should respect them in any case. No circumventions.. -> It's Inconsequent (no unity): All decks look the same, some should behave the same -> It's unfunctional: I would expect a deck to be functional when switching decks -> It's visually annoying if every deck had a own size setting. A small size will render some decks unusable, a larger size doesn't hurt. Based on consistency I would like a global default minimum size, where all the decks are fully functional. I understand that there are some user cases, for shrinking the deck below the "global" minimum. Which sounds a bit like special user needs (my opinion; no workflow expert). A possible solution would be to 'set a default minimum size' which can be bypassed. Something like CTRL+DRAG for people who really want that to happen...
Yes, as I've been saying. I have little trouble that a deck or content panels can shrink/open at less that its minimum width (i.e. a sum of widths of widgets and labels) and have widgets hidden. That is a helpful feature of the Sidebar, which by the way is exactly the behavior of Toolbars. What still needs to be implemented for Sidebar is a button control on the Title bar of each Deck to snap that deck to its calculated minimum, while allowing the _all_ decks to expand/contract (and holding that width while switching Deck to Deck) to a users preferred width while working on a document, and make the GUI consistent. As implemented Gallery, Styles, Transitions, Animations, Decks/Content Panels are correct! They each resize fully until collapse. A number other decks modified with enforced minimums--e.g. Properties, Page, Navigator (in Writer)--have all been _broken_ during implementation as they can not be reduced in width to collapse. They are inconsistent and break the UI/UX. To move this forward, suggest we: 1) set a dynamic minimum (widgets + labeling width--localized) for each deck 2) provide a button control on the Deck Title bar to snap to that width 3) restore the drag width to collapse for all decks to make the UI consistent
(In reply to V Stuart Foote from comment #9) > What still needs to be implemented for Sidebar ... > allowing the _all_ decks to expand/contract (and holding that width while > switching Deck to Deck) to a users preferred width while working on a > document. This is the kind of enhancement requested in bug #128180. (As a practical illustration -- to justify this capability -- I sometimes keep the Navigator Deck wide (to use bookmarks), but do not want Properties and Styles to be so wide (when switching to them -- it takes up too much screen space)
Shouldn't be an issue anymore, see also bug 104632 and bug 79758.