there are different sidebars but at least the specific sidebars didn't fit into the width of Style/Font/Paragraph so the user has to have always change the sidebar width depend on the content sidebar. This width change also give visual glitches.
can there be an default sidebar width all sidebars has to (perfect) fit. I'm thinking of the width of the default sidebar elements (Style, Font, Paragraph for writer). At least in english language.
Created attachment 157290 [details]
Default visible sidebar in writer
this can be the size of all sidebar's, at least you would get no visual issues
Created attachment 157291 [details]
if an sidebar didn't fit the default size
Created attachment 157292 [details]
how MSO make the sidebar
you can change the size at MSO but in the default width all elements fit's in addition they use always the same layout and the same widget's.
I also would like to make the gallery sidebar 3 collum width, which would be a bit larger than now. Change to that width could help the other sidebar widgets.
This has been covered in depth. And only resolved facet is that the Sidebar decks will not revert to the 'fixed' widths of the legacy .src based GUI.
It is directly the opposite of bug 128180
IMHO => WF
(In reply to andreas_k from comment #4)
> I also would like to make the gallery sidebar 3 collum width, which would
> be a bit larger than now. Change to that width could help the other sidebar
No objection to that (a default opening of the content panel with icons sized to fit 3 columns) but as implemented--as the content panel is made wider or narrower the icons will respond and resize--and, at some icon maximum, the column count will shift. Increasing with width to max or 4 or decrease with width to 1, before the deck will collapse.
The tiles holding the icons as the Gallery is resized will shrink, but have an issue open that it does so only in the x-axis, keeping a minimum y-axis height that makes the tiles look weird prior to the deck's collapse. Could not find that BZ id just now.
An evergreen... opinions in addition to what Stuart said?
The default sidebar should be that size where all sidebars fit. In addition the user can change the size of the sidebar depends on there need but it should be an additional thing.
(In reply to andreas_k from comment #7)
> The default sidebar should be that size where all sidebars fit. In addition
> the user can change the size of the sidebar depends on there need but it
> should be an additional thing.
If you mean that all sidebar decks open to the same "master" width with a default user profile, I don't have too much heartburn over that provided all user configurations and last used state for each of the decks then get recorded back into user profile.
But then calculating what that "master" width would be seems challenging. Would have to be done by os/de and os locale setting--because GTK packing changes by os/de, as does width of labeling and droplist content by localization.
for consistent UX I would rather have a consistent set of rules:
1. drag expand to some reasonable maximum by os/de & locale
2. drag collapse to some reasonable minimum, before full collapse of the deck by os/de & locale
3. any width set per deck becomes the value for that deck for that LO module--in the current session
4. on save/close option to make those session last used values, new user defaults per module per deck, recorded to profile for next launch.
(1&2 as done in the Gallery deck now)
(In reply to V Stuart Foote from comment #8)
> If you mean that all sidebar decks open to the same "master" width with a
> default user profile, I don't have too much heartburn over that provided all
> user configurations and last used state for each of the decks then get
> recorded back into user profile.
That's the idea of this bug report.
> But then calculating what that "master" width would be seems challenging.
> Would have to be done by os/de and os locale setting--because GTK packing
> changes by os/de, as does width of labeling and droplist content by
That's one of the problem
Created attachment 157391 [details]
> (1&2 as done in the Gallery deck now)
the gallery deck show now only one image per row it doesn't look like it's so usefull see attachment
Created attachment 157393 [details]
writer sidebar width of the different decks
this may show the big issues. you can "fix" this bug with make the sidebar elements size smaler, but in the end it would be easier if there is an default width where all items fit's.
- Backends (GTK3/QT/...)
- Layouts (ui files)
anyway maybe we can define an maximal width depend on the 4 items so that everything fit's well.
As now the sidebar width is the MINIMUM of the first visual UI elements.
I don't think that an MINIMUM is the best decision for the default, would it be possible to use MINIMUM + 20% as default.
Optimum = Minimum * 1,20
That would solve a lot of issues if other translation stuff is a bit longer than the default widgets.
Sidebar max width was discussed in some meetings, among others in (1) or (2), culminated in a survey which results are presented in (3) and the guideline (4). One point is "Do not crop controls. Define one minimum width depending on the content of all tabs." In bug 128180 a smaller minimum was requested and we decided to resolve as WF, likewise we did in bug 90374 about a fixed width across all tabs.
So the initial request to have one fix width is a WF. As Stuart said in comment 8 we should focus on better positioning of controls, IMHO also a stricter selection of what is shown, labels for accessibility etc. Should it be done on this ticket, or at all? Probably not unless the topic receives more attention.
(In reply to andreas_k from comment #3)
> you can change the size at MSO but in the default width all elements fit's
> in addition they use always the same layout and the same widget's.
Using one control per row results in a clean layout, no question. And it also has the advantage of (accessible) labels everywhere. But keep in mind that we provide access to much more functions and attributes from the sidebar.
We discussed the topic in the design meeting and there is not much to add to comment 13. => WF
*** Bug 132041 has been marked as a duplicate of this bug. ***