Description: 1. The decks in the sidebar have different behaviors about how minimal their width can be. (Request for smaller minimums) 2. The width of one deck will be carried over when another deck is selected (request: each deck keep its own width). Steps to Reproduce: Version: 6.3.3.1 (x64) Build ID: f41f4c7f9507aeca13cb9df51f34d80e8ba30a99 CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; Actual Results: A. (Observed) Styles and Gallery decks can be adjusted to width zero. The other decks can only be adjusted to a certain (different) minimum. B. (Observed) Width of one deck affects the width of another, when switching between decks. Example: 1. Make width of Properties deck as small as possible. 2. Choose Page style or Navigator deck 3. Width of sidebar increases. 4. Choose Properties deck again. (width has now increased to same as Page or Navigator deck) Expected Results: A. Expected (requested): The width of each deck can be adjusted to any size. B. Expected (or requested) (for example): The Properties deck should keep its own width. Expected (or requested) (in general): Each deck should keep its own width. Reproducible: Always User Profile Reset: No Additional Info: Probably there are other variations, but maybe examples are enough to illustrate the issue.
It seems a wide field for improvements. See also bug 90374, bug 124991, bug 115981.
> Expected Results: > A. Expected (requested): The width of each deck can be adjusted to any size. Has been discussed extensively in the past. Minimal width for some has been chosen. > B. Expected (or requested) (for example): The Properties deck should keep > its own width. That means that the width changes if another deck is chosen? Doesn't looks nice I think.
(In reply to Cor Nouws from comment #2) > Has been discussed extensively in the past. For example here https://wiki.documentfoundation.org/Design/Meetings/2016-02-05 with the request to increase the maximum size. General decision was to have as much freedom as possible for extensions developers. In bug 90374 we discussed a fixed width idea. We didn't come to an agreement how the existing min and max value should be changed and resolved the ticket as WF. And we talked about this topic yesterday again. The issue is only regarding the page sidebar that needs a few pixels more depending on the content and thereby localization. So the solution for this request that I'd rename to "size the sidebar tabs equally" is to increase the default size for all other tabs. Won't work with extensions, looks bad for the gallery, and has no conceptual basis we can use for later additions. It's also not a big deal to resize the sidebar, which is kept then over all tabs. So the verdict is WF.
(In reply to Heiko Tietze from comment #3) I think there is a misunderstanding here. Please let me try again to explain. The main point is that there can be functional reasons to want to keep different deck widths. (examples given below) > In bug 90374 we discussed a fixed width idea. We didn't come to an agreement > how the existing min and max value should be changed and resolved the ticket > as WF. I understand (and agree). > And we talked about this topic yesterday again. The issue is only regarding > the page sidebar that needs a few pixels more depending on the content and > thereby localization. So the solution for this request that I'd rename to > "size the sidebar tabs equally" is to increase the default size for all > other tabs. I am not requesting a change in default size. > It's also not a big deal to resize the sidebar, which is kept then over all tabs. But this is exactly the problem. Why can't the sidebar keep different values for each deck? Here are some points. 1. No point in having different minimums because at present, every deck will be forced back to the largest minimum. Examples: a. Styles can be made very "thin" (down to zero) -- but it will be forced back to the width of other decks (e.g., Properties, or Navigator) -- so one would have to keep resetting it thinner, if that was desired. b. Similarly, making Properties a minimum has no advantage, if Navigator is also used, because Navigator seems to have a larger minimum than Properties, so switching from (minimum) Properties to Navigator and back will increase the width of Properties to the Navigator minimum. 2. In term of "functionality", the decks have different practical functions, and there can be good reasons to prefer different widths for different decks. a. As one practical example, I sometimes make Navigator very wide (because of long bookmark names), where I don't mind that the sidebar is covering some of the document text while navigating. But in switching to other decks (e.g., Properties) then these other decks are also forced to that the broad Navigator width (where now it is a problem that it is covering some of the document text.) b. Furthermore, if I make one of these decks (e.g., Properties) more narrow (so that I can work on the document text), then when I switch back to the Navigator deck, then I have to make it broad again (because its width has been changed to the value of the Property deck). In short, if there are practical reasons (such as described here) to want different width decks, then these settings are constantly lost in changing decks (i.e., this suggestion comes from practical experience/frustration with using the Sidebar, not hypothetical "what if" thinking). Therefore the suggestion to allow users to set (and keep) widths that fit their needs. 3. (Would it be hard to add this flexibility as a "customization" option?) Thanks for consideration.
Okay, you convinced me. User-input must not be overridden and it's also not a big deal (hopefully) to make the tabs independent from each other. So while keeping the basic rule with minimum defined by content and maximum by value the proposal is to remember the resized panel width independently.
@devs, with code pointers regards the Sidebar decks' framework and its linkage to user profile configurations could this be EasyHack'able at the Interesting level? Or, anyone with interest and cycles to poke at it?
(In reply to sdc.blanco from comment #4) > (In reply to Heiko Tietze from comment #3) > b. Furthermore, if I make one of these decks (e.g., Properties) more narrow (so > that I can work on the document text), then when I switch back to the Navigator > deck, then I have to make it broad again (because its width has been changed to > the value of the Property deck). I understood you, but I'm against an jumping UI cause the sidebar width is jumping all the time. Do someone know any software where an sidebar will have different sizes all the time? I'm for closing all this sidebar width bugs.
(In reply to andreas_k from comment #7) > I understood you, but I'm against an jumping UI cause the sidebar width is > jumping all the time. Agree.
We discussed the sidebar topic in the design meeting. Minutes: => initial width should be defined by the controls of all decks so the largest deck is responsible for the initial width => minimum width is defined by the individual deck so users can change the deck to be smaller than other decks => width of decks should be stored per deck => if no control is placed on the deck the minimum width has to be defined as absolute value + minimize beyond the minimum shows a blue arrow that indicates that the sidebar is going to automatically collapse => maximum width is defined (AI: defined in svx?) => sidebar optimum width should not exceed 10 toolbar buttons at large icon size => undocking sidebars for the first time should expand to the docked width; users should be able to resize as when docked (see above) In a nutshell: Jumping UIs should be avoided, of course. So the initial state of all decks should be defined by the deck with the maximum width. But there is no good reason to not let users resize to the minimum, for example only one thumbnail at the gallery. Therefore the minimum width is defined per deck. And last but not least we have to store the individual deck width (also per module, see also bug 95347).
Bug 105131 notes that ”Restore Default” does not work (in terms of which Decks are shown). Would customizing users expect ”Restore Default” to also ”restore default widths”? Or should a ”Default Widths” menu item be added to the Customization context menu for Sidebar?
(In reply to sdc.blanco from comment #10) > Bug 105131 notes that ”Restore Default” does not work... Commented there; the command is supposed to restore the check box settings (all on)
*** Bug 149431 has been marked as a duplicate of this bug. ***