In calc the sidebar width is different in properties, navigator, functions, ... in writer and the other apps it look like the width is always the same.
don't confirm in Version: 6.2.1.2 Build ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71 CPU threads: 4; OS: Linux 5.0; UI render: default; VCL: kde5; Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US Calc: threaded Sidebar's width is the same for any sections
Created attachment 151031 [details] Different Calc Sidebar width See attached functions has smaller width Version: 6.3.0.0.alpha0+ Build ID: 08c529c6c146c09a33c175225866aa7a97653cf4 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: de-AT (de_AT); UI-Language: en-US Calc: threaded https://gerrit.libreoffice.org/plugins/gitiles/core/+log/08c529c6c146c09a33c175225866aa7a97653cf4
Not reproducible for me with Version: 6.3.0.0.alpha0+ Build ID: f7453b956bcf83ec13c805d243f20cb209289179 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Ubuntu_18.04_x86-64 Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded built at home under Ubuntu 18.04 x86-64 What is your OS and your DE if Linux ? Status set to NEEDINFO, please set it back to UNCONFIRMED once requested informations are provided. Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #3) > > > What is your OS and your DE if Linux ? > > Status set to NEEDINFO, please set it back to UNCONFIRMED once requested > informations are provided. > Sorry didn't read comment #2 carefully enough. Set status back to unconfirmed and OS to Windows. Bes regards. JBF
Thank you for reporting the bug. I cannot reproduce this bug in Version: 6.3.0.0.alpha0+ Build ID: b6b28931435e44aca92b8c0e1659f701e3ed1a87 CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-01-30_06:57:04 Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Andreas, please try delete/rename user profile and retest this
(In reply to Roman Kuznetsov from comment #6) > Andreas, please try delete/rename user profile and retest this I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present
1. The original problem report is not clear. 2. If the "problem" is that the sidebar in Calc can have different widths, then wasn't that the intended design? It works that way for me. 3. Have reported an enhancement for Writer (bug #128180) to allow each deck to "keep" its width (as set), and not to change its width to the current width of the shown deck. 4. Have tested the same problems reported in #128180 with Calc and can report similar characteristics. That is: a. Styles and Gallery Decks can be made with 0-width decks. (The other decks -- Properties, Navigator, Functions -- have a certain minimum width they will accept) b. Example of how width stays the same across decks. i. Make the Gallery (or Function) Deck very narrow. ii. Switch to Property Deck iii. Switch back to the (previously narrow) Gallery (or Function) deck iv. See that the width of the Gallery deck changes now to the width of Property. Maybe this "bug" should be changed to an "enhancement" request for Calc to allow Decks to keep their width? Version: 6.3.3.1 (x64) Build ID: f41f4c7f9507aeca13cb9df51f34d80e8ba30a99 CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; Locale: en-US (en_DK); UI-Language: en-US Calc: threaded
I think there should be a general HIG for the sidebar Option 1: defined sidebar default size (where all decks will work with) Option 2: each deck can have there defined default size In general I'm for Option 1 cause it's easier to develop and test for an specific default size.
[Automated Action] NeedInfo-To-Unconfirmed
This request is not clear to me. Do you want one size for all sidebar tabs (terminology at https://wiki.documentfoundation.org/Design/Guidelines/SideBar) or an individual minimum/maximum size?
One width per application which is defined so that if you do ui work you have the definition width. In addition it didn't look professional when the sidebar jump between gallery, property, styles, ...
*** This bug has been marked as a duplicate of bug 90374 ***