I believe having a fixed width for the sidebar will give us a defined area to work within and will reduce bugs appearing with controls being cropped (e.g. bug 79758, bug 87809) and similar type issues. Having it resizable doesnt have a benefit when all that is happening is that controls are being stretched to fit the new size or space is being added between the controls.
@Jay, IMHO do not agree *at all*. A fixed Sidebar Deck area locks us into a fixed Sidebar layout. Stretching and shrinking the Sidebar is needed to accommodate dynamic use of the Sidebar as any future content panels are implemented, or users roll their own content panels. This suggestion is 100% opposite of bug 83526#c5 - "Deck not adjusted for content panel size when switching content panels" Adjustments to the Sidebar should be a simple and convenient as currently available to customize Toolbars, they are not (some annoyances listed below). The Sidebar deck and user preferences should be stateful and user configured, and work on bug 85905 - "Allow undocking of Sidebar decks" pursued to allow the Sidebar to become fully functional. =-Sidebar annoyances-= bug 33223 - Sidebar: as container for toolbars, ability to add functions missing from Sidebar bug 65351 - Sidebar: open pane that was active when last used bug 67230 - Sidebar does not keep state of Content View in Navigator bug 67770 - Sidebar customization settings not remembered after reopening
Stuart, (In reply to V Stuart Foote from comment #1) > IMHO do not agree *at all*. A fixed Sidebar Deck area locks us into a fixed > Sidebar layout. Stretching and shrinking the Sidebar is needed to > accommodate dynamic use of the Sidebar as any future content panels are > implemented, or users roll their own content panels. If in the future there are content panels that go beyond a fixed width that was set, a new fixed size could be implemented. Users rolling their own content panels is something that sounds nice but is never going to be implemented. Do you know of any other applications that allow users to change sidebar content panels, as i've never seen any. > Adjustments to the Sidebar should be a simple and convenient as currently > available to customize Toolbars, they are not (some annoyances listed below). If the sidebar was simply a list of buttons that were easily saved into an XML file, then it would be simple and convenient to customize, but it isnt. The panels are designed in glade (i'm assuming) and function with dev code running behind it.
Setting it to NEW as its ux-advise and await other people's feedback.
I think we should keep minimum width in mind, but not make the width fixed. In some cases making it wider because of styles dialog names, especially when using larger UI font, or because of the font dropdown to fit longer names is extremely useful and would outweight possible slightly odd look.
This is like going back to the previous .src-based dialogs, with their hardcoded sizes and issues with localizations. Just don’t.
So is a minimum width agreeable.
Created attachment 115092 [details] indicator when drag resizing Deck is about to collapse closed (In reply to Jay Philips from comment #6) > So is a minimum width agreeable. Behavior now is that while we drag the Deck's width narrower at a point the GUI switches to a close action for the Deck--a Right pointing arrow appears--and release of the drag colapses the deck. This complements action of a click on the current Tabbar button which collapses the deck for the current content panel(s), or if a different Tabbar button will toggle the Deck to that tab's content panels(s). The full collapse of the Deck with a click on its Tabbar button seems correct UI/UX. A drag resize to minimum size -> then collapse (looks to transition when last widget of the specific content panel(s) open has been obscured) also seems correct -- reopening of deck to that same content panel opens it to a "minimum width", for that content panel. And changing the Deck to one of the other Content panel(s) with a Tabbar click retains the prior "minimum width". The Navigator and Manage Changes content panels seem to incorrectly not allow resize of the deck to point of colapse, but they do honor the "minimum width" if set from another content panel active in the Deck. All that being said, the current configuration of allowing both a "minimum width" (e.g. last fully exposed widget) prior to collapse of the Deck, and a "maximum width" independently for each Content panel continues to make sense. Especially if we are able to improve function of the Sidebar with per-user customization of bug 67770, and the other issues of comment 1. So NO, would not agree to a single minimum width applied to Decks of "all" content panels--but that said, there is room to improve how each decks minimum width (prior to collapse) is determined.
Created attachment 115094 [details] sidebar tabs cropped (In reply to V Stuart Foote from comment #7) > Created attachment 115092 [details] > indicator when drag resizing Deck is about to collapse closed > > Behavior now is that while we drag the Deck's width narrower at a point the > GUI switches to a close action for the Deck--a Right pointing arrow > appears--and release of the drag colapses the deck. That behaviour doesnt happen for the Properties or Manage Changes tabs. > This complements action of a click on the current Tabbar button which > collapses the deck for the current content panel(s), or if a different > Tabbar button will toggle the Deck to that tab's content panels(s). Dont forget the 'X' button in the title bar. :D > The full collapse of the Deck with a click on its Tabbar button seems > correct UI/UX. > > A drag resize to minimum size -> then collapse (looks to transition when > last widget of the specific content panel(s) open has been obscured) also > seems correct -- reopening of deck to that same content panel opens it to a > "minimum width", for that content panel. And changing the Deck to one of the > other Content panel(s) with a Tabbar click retains the prior "minimum width". Is there a point to be able to shrinking down the width of a tab so that the controls start to disappear, similar to the attached image. > The Navigator and Manage Changes content panels seem to incorrectly not > allow resize of the deck to point of colapse, but they do honor the "minimum > width" if set from another content panel active in the Deck. I was able to resize Navigator to the point of collapse. I find the resize of the deck to point of collapse to be quite useless. Other office suites that implement sidebars dont have such functionality (calligra, iworks, wps/kingsoft). > All that being said, the current configuration of allowing both a "minimum > width" (e.g. last fully exposed widget) prior to collapse of the Deck, and a > "maximum width" independently for each Content panel continues to make > sense. Especially if we are able to improve function of the Sidebar with > per-user customization of bug 67770, and the other issues of comment 1. > > So NO, would not agree to a single minimum width applied to Decks of "all" > content panels--but that said, there is room to improve how each decks > minimum width (prior to collapse) is determined. So you wouldnt agree to a single minimum width for all but you'd agree to having independent minimum widths per deck, right?
(In reply to Jay Philips from comment #8) > Is there a point to be able to shrinking down the width of a tab so that the > controls start to disappear, similar to the attached image. > Sure, you can precisely set the exposed content panel to a width that still fits with a document at a particular zoom level--the Content panel is available to work with, rather than hidden. > I was able to resize Navigator to the point of collapse. I find the resize > of the deck to point of collapse to be quite useless. Other office suites > that implement sidebars dont have such functionality (calligra, iworks, > wps/kingsoft). > We *don't* care about other suites! And allowing resize to point of collapse allows the deck and the content panel to be reopened at that width. Again, useful when trying to hold the document at a particular zoom. > > So NO, would not agree to a single minimum width applied to Decks of "all" > > content panels--but that said, there is room to improve how each decks > > minimum width (prior to collapse) is determined. > > So you wouldnt agree to a single minimum width for all but you'd agree to > having independent minimum widths per deck, right? Correct, your stated goal was that "having a fixed width for the sidebar will give us a defined area to work within..." I flatly reject the need for that across all Content panels. Rather, there is utility to allowing each active content panel to reduce to some minimum. Either as detected by the GUI widgets present on the active Content panel--or to some predefined minimum assigned per content panel. So long as the Deck independently responds to the active content panel--the method for the minimum width can be determined either way. Just not set to one minimum width for all content panels. We did similar for the Start center, where we allow it to shrink to the width of the Welcome message of the selected UI language, or to the minimum width of one thumbnail view if any are present.
Resizing sidebars allows to adopt to different content over tools but not within. As a user I have no benefit from resizing (exaggerated spoken). On the other hand, Eve [1] might want to have more individualization since sidebars take a lot of vertical space, too much on 4:3 displays. So it make sense to change the content of the sidebar on resizing. For instance by hiding captions or in general replacing text by icons. Another idea would be to have some kind of alignment that leads to rearranged/wrapped controls depending on the width. [1] Eve is our persona for expert users. It will be added to the wiki soon.
The Sidebar deck already provides for contextual adjustments to active Content Panels. GtkGrid holds widgets pinned right or pinned left. Dropdowns and spinners resize (with or without minimum). Scroll bars are exposed. Even speciifc content, e.g. Gallery thumbnails respond to resize. There is a lack of consistency in the implementation between content panels, and between modules.
Believe arguments are well formed that neither fixed minimum or fixed maximum width is acceptable behavior for current, or future enhanced function of the Sidebar. Closing Wontfix.
*** Bug 91915 has been marked as a duplicate of this bug. ***
vstuart, I'm reopening this as 1) There are multiple users requesting this feature. 2) We already implement this feature in the main properties sidebar 3) Some of your counter bug examples have been resolved, while others do not directly conflict with this request such as Bug 67770 I feel Yousuf adequately addressed all the other concerns you had with this feature. This is also the best solution to Bug 92317. Every panel needs a minimum width to be functional. We either need a global minimum as discussed here or a per panel minimum discussed there. A global minimum has the advantage of not needing to dynamically resize the panel when switching between panels of different min width. I use several application with side panel UIs. LibreOffice is the only one where I often find myself resizing it to fix inaccessible controls. No matter how you spin it, that's a bug not a feature.
Sure I'm fine with reopening. But my position remains as in comment 9 -- individually set minimums are reasonable, but *no* to setting a global fixed minimum width for any content panel active in the Sidebar deck. As the content of each panel is different--its dimensions should be different: fully extended, or shrunk to colapse. Otherwise, as Adolfo notes a global minimum width would be like a reversion to prior .SRC based dialogs. When issues from 67770/69534 "Sidebar customization settings not remembered after reopening" -- see https://bugs.documentfoundation.org/show_bug.cgi?id=67770#c4 -- are being implemented a fixed global minimum width would be counter productive to their resolution. Fixed minimum would not be needed--so don't implement it that way.
V Stuart, Bug 67770 is about the sidebar -> customization option being remembered. Where do you get the idea it's about remembering sidebar widths? If so, that's a terrible idea. You do not want the sidebar constantly re-sizing as you click on different objects in your document. Bug 69534 is about the modules remembering if the sidebar is open or closed. Again unrelated to the min/max width of the sidebar. As a sidebar user, the only state I care to manage is open or closed, open to focus on properties or closed to focus on content. I do NOT want to micromanage the size of the sidebar like I do now because controls get hidden. And I do not want it dynamically re-sizing as I move though my document.
(In reply to Luke from comment #16) > As a sidebar user, the only state I care to manage is open or closed, open > to focus on properties or closed to focus on content. I do NOT want to > micromanage the size of the sidebar like I do now because controls get > hidden. And I do not want it dynamically re-sizing as I move though my > document. Absolutely! And that is the granularity of Sidebar customization that we need to provide users. We closed this issue as described in its summary because fixed widths (min/max) are not a route to customization and a full implementation of the Sidebar. See bug 33223 and the various issues in the meta bug 65138. bug 67770 is about customizations being remembered, widths are just one facet of customizations. As you'd like the widths static--great that is your customization. Others will prefer to have their mix of button widgets and positions and widths remembered. Some of that comes with the new Sidebar API so folks can roll their own content panels. bug 69534 was resolved by Caolán's work to "cook up a scheme to allow windows to have per-module settings" it gave us ability to record state of the Sidebar per module--on or off in that limited case, but the basis for supporting further customization. Now, that said--I'd move to close this issue again WONTFIX.
(In reply to V Stuart Foote from comment #17) > Absolutely! And that is the granularity of Sidebar customization that we > need to provide users. We closed this issue as described in its summary > because fixed widths (min/max) are not a route to customization and a full > implementation of the Sidebar. See bug 33223 and the various issues in the > meta bug 65138. > So what is the solution? To me, a min/max for the sidebar is not a way of "personalization" is a way to add consistency to the contents of the sidebar -as a whole-. How strange it would be that each tab on the sidebar, had its own width min/max. Actually, at some point he proposed the existence of a minimum and maximum width for the sidebar (not all users have a wide screen), but really the best solution is the existence of a single width for side, consistent bar and It would save time showing and hiding the content (not adjust the width to view the content of some tabs!). If competition is analyzed, that seems to be the rule. Cheers
(In reply to Bastián Díaz from comment #18) > So what is the solution? > > To me, a min/max for the sidebar is not a way of "personalization" is a way > to add consistency to the contents of the sidebar -as a whole-. > > How strange it would be that each tab on the sidebar, had its own width > min/max. > Actually, at some point he proposed the existence of a minimum and maximum > width for the sidebar (not all users have a wide screen), but really the > best solution is the existence of a single width for side, consistent bar > and It would save time showing and hiding the content (not adjust the width > to view the content of some tabs!). Sure, if the Sidebar were a static UI element we could make a case for fixed static structure. However, we quickly migrated it from .src to GTK .UI based widgets making it dynamic by nature. Building on that we have "enhancements" in queue to do some neat things like splitting out content panels into independent decks--detaching them as .UI based analogs to legacy dialogs--ref bug 85905 The limitation at the moment is that we implement the Sidebar with its Tabbar and just one Deck holding Content Panels, displayed docked or undocked. From a UI design and development perspective that is constraining--and leads to wrong headed ideas that static and fixed is better UI and improve the user experience. Fortunately once over that development hurdle the Sidebar gains tremendous flexibility. For example ability to undock a custom content panel and drag your favorite UNO widgets into it--closing the rest of the Sidebar, or shifting to "Single" mode of bug 92220 and bug 92218 We support those longer range features now by ensuring the ability of the user to fully customize their content panels and to retain those customizations within a session and within their profile, with an ability to recover or transfer their customizations to a new profile. That all comes from supporting a design that nurtures dynamic layout and customization.
(In reply to V Stuart Foote from comment #19) > Sure, if the Sidebar were a static UI element we could make a case for fixed > static structure. However, we quickly migrated it from .src to GTK .UI based > widgets making it dynamic by nature. Building on that we have > "enhancements" in queue to do some neat things like splitting out content > panels into independent decks--detaching them as .UI based analogs to legacy > dialogs--ref bug 85905 > Yes, I've read a little about it, but the design elements must adapt to the tools to create interfaces or vice versa? For example, inkscape panels maintain their own proportions (width min/max) when anchored as sidebar, and for me the user experience is horrible. To move the panels out of the sidebar in LO and that these have their own proportions, it seems useful and good (I have seen other people have a workflow that way), but I think while they are attached as tabs on the sidebar should be consistent. > and leads to wrong headed ideas that static and fixed is > better UI and improve the user experience. > OK. Maybe not the best UI, but it works best for me and "other potential users." > Fortunately once over that development hurdle the Sidebar gains tremendous > flexibility. For example ability to undock a custom content panel and drag > your favorite UNO widgets into it--closing the rest of the Sidebar, or > shifting to "Single" mode of bug 92220 and bug 92218 > > We support those longer range features now by ensuring the ability of the > user to fully customize their content panels and to retain those > customizations within a session and within their profile, with an ability to > recover or transfer their customizations to a new profile. That all comes > from supporting a design that nurtures dynamic layout and customization. Yes, I think that's good then ... you think you could add a configuration option to keep the width of the sidebar static ... For some users we only matters show/hide the contents of the sidebar, unfortunately to do that, there must be a "consistent width to allow properly display elements of each tab in the sidebar". I understand the enthusiasm of developers deliver a better user experience, but I think it can be done without dramatically change the workflow of many users. Cheers
V Stuart, You talk about all of these great UI features that we give the users like detaching the pane as if they are somehow in conflict with this feature. They are NOT. Once the pane is detached, the sidebar is no longer a sidebar. It's not at all related to this topic. Width limits on them are separate issue all together. Finally you fail to address the key issues here: 1) What good are the "dynamic GTK .UI based widgets" when they cannot accessed by the user? 2) Why do we want to a system where the user is constantly tweaking the width instead of providing one that just works? I never find myself resizing the toolbar because a large icon doesn't fit. The toolbar doesn't require constant adjustment to be functional. When I use the LibreOffice sidebar, sometime the controls that I'm looking for have been resized off the pane. So I have to resize the sidebar to make them fit. This is a bug. It's not a feature. You are not giving the user anything, just making it harder for them to do their work. There is no benefit. It's ugly. I use several applications with side panes and LibreOffice is the only one forces me to make adjustments to make it usable.
(In reply to Luke from comment #21) > ... Once the pane is detached, the sidebar is no longer a sidebar. > It's not at all related to this topic. Width limits on them are separate > issue all together. > Hmm, they really are still the same issue--the underlaying code is still a Sidebar Deck and Tabbar--they're just in an undocked state. Of course they could receive min/max width attributes while docked and a set while undocked. And of course as more docking sites are defined that has to be recorded as well. > 1) What good are the "dynamic GTK .UI based widgets" when they cannot > accessed by the user? In fact they currently can be, as extension or macro. What is currently missing is Drag & Drop GUI, or Customization GUI as with Toolbars. > 2) Why do we want to a system where the user is constantly tweaking the > width instead of providing one that just works? There is nothing wrong with giving the users that flexibility. It sucks now because nothing is retained. But that will get fixed, and then what? Moving beyond current implementation is better served by keeping things flexible--not by locking it down.
(In reply to V Stuart Foote from comment #22) > There is nothing wrong with giving the users that flexibility. It sucks now > because nothing is retained. But that will get fixed, and then what? Moving > beyond current implementation is better served by keeping things > flexible--not by locking it down. Then we change some concepts and not talk to retain or limit, but handing consistent user experience when the contents are docked to the sidebar. For me the idea of the sidebar, is a way to manage a set of tools in a coherent and orderly, not a set of different elements working in the same place (or it appears to be ...). This would also help users / developers to be careful when creating new widgets or macros to run docked to the sidebar, and not find widget cut or overlapping. I think that also provides flexibility, whereas somewhat flexible does not necessarily mean something unlimited. Cheers
> It sucks now because nothing is retained. But that will get fixed, and then what? Moving beyond current implementation is better served by keeping things flexible--not by locking it down. So basically you're advocating to keep the broken UI, because you hope it might be useful when things are more customizable. The current default UI without any user customizations is broken. This should be fixed now. How you imagine a future UI may or may not work, it not relevant to this issue. Let's discuss that in a separate bug report.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
I'm against any fix width of the sidebar. For comparison: Also in MSO Word 2013 the user can freely choose the width of sidebars like Search and Styles. That fulfills the requirements of many users. From a UX point of view, what's necessary is 1) a good default width per locale to avoid cropped UI elements and strings and 2) the width that is set by the user must be remembered. If that's realized this request isn't necessary.
(In reply to Thomas Lendo from comment #26) > I'm against any fix width of the sidebar. For comparison: Also in MSO Word > 2013 the user can freely choose the width of sidebars Thomas, No one is asking for a fixed width. This report is about a fixed MINIMUM width. What we want is the sidebar to behave like Calligra, iWorks, WPS Office, and yes, like Word too. All of them prevent you from resizing the sidebar/panel to a point where controls get hidden. Like MSO Word 2013, the users will still be able to freely choose the width of sidebars after this bug is fixed.
So the question is: do we allow users to pull the side bar width below a size where widgets become dis functional, or should we set a minimum (per deck) so that an arrow appears indicating that continuing with decreasing width will result in closing of the side bar. My first reaction is: don't care. My second: if there is a different minimum for each deck, don't do it. It might interact when I have the side bar set smallish and click on another deck, that it closes.
Created attachment 139329 [details] Minimum width of navigation/search sidebar and styles floating window in MSOW2013 (In reply to Luke from comment #27) > This report is about a fixed MINIMUM > width. What we want is the sidebar to behave like Calligra, iWorks, WPS > Office, and yes, like Word too. All of them prevent you from resizing the > sidebar/panel to a point where controls get hidden. Ok, but not a single value for all sidebar decks at once. The Properties, Page, Navigator (in Writer + Calc), Functions, Manage Changes (experimental in Writer) and Design (experimental in Writer) decks of the sidebar already have a minimum width. But Styles (formerly Styles and Formatting), Slide Transition, Animation, Master Slide, Gallery and Navigator (in Impress + Draw) decks and the Elements pane in Math are resizable to a width where most controls, texts and graphics are unusable. The minimum width seems to be very wide for some decks (also in comparison to what MSO Word 2013 allows, see my attached screenshot) now. That's because the sidebar is very unflexible in general. Properties deck has a wide min. width, Functions deck has a smaller, nicer min. width (the reason for the difference doesn't matter, I only speak from UX' standpoint). (In reply to V Stuart Foote from comment #7) > So NO, would not agree to a single minimum width applied to Decks of "all" > content panels--but that said, there is room to improve how each decks > minimum width (prior to collapse) is determined. I support this. (In reply to Yousuf Philips (jay) from comment #8) > (In reply to V Stuart Foote from comment #7) > > The Navigator and Manage Changes content panels seem to incorrectly not > > allow resize of the deck to point of colapse, but they do honor the "minimum > > width" if set from another content panel active in the Deck. > I was able to resize Navigator to the point of collapse. I find the resize > of the deck to point of collapse to be quite useless. I can't resize Navigator and Manage Changes in 6.0.0.2 for example to a point where it collapses. If you reach the minimum width nothing more happens when moving the mouse towards the sidebar's tab bar. I want avoid that generally and suggest the following: I like fluent design without a strong fixed point -- I mean that when reaching the minimum width point the sidebar width should snap to it. If the user drags it further towards the tab bar then the sidebar should visibly collapse so that the user has a visual feedback. That happens already today for sidebar decks without a minimum width at about 1 cm before tab bar. Locking: Maybe also a setting to lock the width given from the user can be introduced to prevent unwanted changes of the width afterwards, similar to the "Lock Toolbar Position" setting for toolbars. (This shouldn't prevent closing the sidebar deck with a click on the tab icon.) (In reply to Bastián Díaz from comment #18) > (In reply to V Stuart Foote from comment #17) > > Absolutely! And that is the granularity of Sidebar customization that we > > need to provide users. We closed this issue as described in its summary > > because fixed widths (min/max) are not a route to customization and a full > > implementation of the Sidebar. See bug 33223 and the various issues in the > > meta bug 65138. > How strange it would be that each tab on the sidebar, had its own width > min/max. This isn't an issue today because all decks/tabs of the sidebar in a LO component have the same width. Current given sidebar width doesn't differ between the decks of this sidebar. (In reply to Cor Nouws from comment #28) > if there is a different minimum for each deck, don't do it. It > might interact when I have the side bar set smallish and click on another > deck, that it closes. A good default sidebar width per locale (as said in comment 26) would avoid cropped UI elements and strings in any of its decks. If the user only uses the Styles sidebar, why should he/she be urged to use a wide sidebar only because the Properties deck needs that width? With a minimum sidebar width of all sidebar decks at once I see a plenty of follow-up bug reports coming. Better to enhance the current handling here and there.
(In reply to Thomas Lendo from comment #29) > A good default sidebar width per locale (as said in comment 26) would avoid > cropped UI elements and strings in any of its decks. If the user only uses Maybe I just want to slide if a bit to the side to look at something. If I want to use it and slide so much that some of the widgets don't work, it is more than obvious to me why that happens. And I would blame it on me.
Looks to me as we have a min and max width today. And although it makes no sense to me we obviously do not come to an agreement to change it. So keeping the current status.
*** Bug 115981 has been marked as a duplicate of this bug. ***
*** Bug 92317 has been marked as a duplicate of this bug. ***
*** Bug 83526 has been marked as a duplicate of this bug. ***
*** Bug 135498 has been marked as a duplicate of this bug. ***
I'm still not quite happy with the sidebar dynamics. And I get they feeling there is some kind of misunderstanding... Or the whole discussion has ended in some binary option, while there multiple irregularity's. Stretching and shrinking the Sidebar is needed to accommodate dynamic use of the Sidebar -> I'm not against Stretching and shrinking the sidebar in principle The main problem. A) Every deck has a minimum width. The minim width of the Manage changes is the largest and the minim width of the Style Inspector the smallest (there is non). B) The size of the deck is depended how small you make the deck & the minimum size. Shrink the Inspector Deck to a small bar, and switch to Manage changes deck (Deck expands). Go back to the Inspector Deck, size of the Manage changes deck will be inherited. So large it is I personally don't see any objection against a shared minimum size of all decks, set to the minimum size of the 'Navigator deck". The only deck which can be made substantial smaller is the Gallery Deck. For the other decks it barely matters. Because you hit minimum size for the decks separately pretty quick. If the current minimum size of the gallery deck is utmost important, fine, but don't inherited this size to other decks. If you reduce the inspector deck to very small setting. Click on Track Changes deck (expands). And Back to the Inspector Deck it will be large again. Start storing the size for every deck separately About maximum size. Looks like all the decks share the same maximum value. Their are two options. Or shared as currently the case, so if you expand the gallery deck & switch to Properties deck, the properties deck will have the same width as the gallery deck. Or if you want to set the maximum size individually you end again up with storing the size for every deck separately. Switching between tabs will rather ugly if every deck has separate (individually stored) size and harder to configure too (if you don't care being able to set it individually). Or even dislike the visual experience of having different deck sizes.
*** Bug 124991 has been marked as a duplicate of this bug. ***
I am all for one global default size which will improve the work on .UI files a lot, cause design e.g. galleries was horrible before I define myself that the gallery sidebar will have 3 column's. Same for other stuff. Without default width it's very difficult to design something. My idea is that the text sidebar define the default size, cause px didn't work cause of the different backend (gtk3).
(In reply to Telesto from comment #36) > I'm still not quite happy with the sidebar dynamics. And I get they feeling > there is some kind of misunderstanding... Or the whole discussion has ended > in some binary option, while there multiple irregularity's. Agree with all 3 points. (In reply to Thomas Lendo from comment #26) > From a UX point of view, what's necessary is 1) a good default width per > locale to avoid cropped UI elements and strings and 2) the width that is set > by the user must be remembered. Sounds good. (In reply to andreas_k from comment #38) > I am all for one global default size which will improve the work on .UI Isn't this point 1 in Thomas Lendo's description? And maybe for precision, important to formulate as "default minimum width for all decks" But what about point 2 in the description: "width set by user is remembered" @andreas_k, does "global default size" also mean: "maintain a standard universal width (i.e., for all decks) (between the common/universal minimum and maximum for all decks), whenever the user changes width for one deck"? In this connection, a few complain about "jumping" UI -- but these arguments seem to be "in principle". But what about in practice? How often do you switch between decks and how many different ones? If you have set the widths (and they are maintained. as proposed), then you will know why it has happened -- and why you have set the widths as you have.
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) Summary: No fixed width, users should always be able to resize the sidebar to the deck's minimum (defined by the controls so nothing is cropped). However, the initial state should be set by the largest deck so we have no jumping UI by default. Let's continue the work on bug 128180.