Description: Preferences is too narrow and some fields of options some fields become unreadable until resized. Steps to Reproduce: 1. Clic Tools menu 2. Clic on Preferences option Actual Results: The width of the dialog causes the fields to not fit well and appear too crowded. Expected Results: Wider width Reproducible: Always User Profile Reset: Yes Additional Info: Reproducible in several versions. Tryed in: Versión: 6.4.4.2 (x64) Id. de compilación: 3d775be2011f3886db32dfd395a6a6d1ca2630ff Subprocs. CPU: 8; SO: Windows 10.0 Build 19041; Repres. IU: predet.; VCL: win; Configuración regional: es-AR (es_AR); Idioma de IU: es-ES Calc: CL
Created attachment 162531 [details] The View option is the most affected
not sure whether it's on purpose having the narrow screens on mind... Anyway, adding the UX team
No issue on macOS with 6.4 and 7.1 (neither with Linux in a VM though). Caolan, what do you think? Looks like Windows doesn't resize controls depending on the content.
I use Windows 10 2004, but in the previous version the same thing happened. It should be clarified that seeing more detail, the width of the dialog adjusts to the content of most of the options except in View.
Unlike every other dialog, the options dialog (because it has so many possible pages) cannot pre-calculate the optimum size for the dialog so it will always have the size set by OfaTreeOptionsDialog::InitWidgets rather than be sized to fit the largest page contents. wrt this particular page since the 6-4 version of the screenshot, the longest text (base english "use opengl for rendering") doesn't appear in the 7-0 version
Created attachment 162552 [details] Linux/gtk3 But why are the dropdowns properly sized on Linux and macOS but not Windows? Version: 7.1.0.0.alpha0+ Build ID: 21c0deb19890703a9eaf24403e60c4c7546a0bfe CPU threads: 8; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
have you tried debugging it to find out
(In reply to Caolán McNamara from comment #7) > have you tried debugging it to find out Don't run Windows; thought you have an idea.
As a workaround for this issue, I’ve shortened the “Menu icons” and “Toolbar” strings, both in source and in the Spanish translation (it now says “Barra de htas.”, abbreviated).
Created attachment 162603 [details] How it looks in LibreOffice 7.1 (win) Not reproduced in Version: 7.1.0.0.alpha0+ (x64) Build ID: acbe57481e0a10be287aad59201873a0799a94f0 CPU threads: 16; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: threaded
I tried some languages where the field labels could be wider than in English and this is the result: English: Not reproducible. Spanish: Reproducible. Russian: Reproducible. German: Not reproducible Portuguese: Reproducible Ukranian: Partially reproducible because some texts are in English. Romanian: Partially reproducible because some texts are in English. Polish: Reproducible
English, German, Spanish - all fine for me. (surprisingly the main menu is not translated in ES) Version: 7.1.0.0.alpha0+ Build ID: 1c7d792ae27d2a899244d30a9c3cd3c04b5755ae Subprocs. CPU: 8; SO: Linux 5.7; Repres. IU: predet.; VCL: gtk3 Locale: de-DE (en_US.UTF-8); Interfaz: es-ES Calc: threaded
In Spanish they have used an abbreviation that, while correct, is confusing and not very intuitive. This abbreviation managed to improve the width of the field but does not solve the problem.
*** Bug 136029 has been marked as a duplicate of this bug. ***
Lessened the issue a teeny-tiny bit with commit 9f16c3b5ac3ae1c9d24fe137ff48b67f54e4899b (trunk/towards 7.4)
Dear Leandro Martín Drudi, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
It has improved substantially for version 24.2. What remains is simply a matter of personal preference regarding whether one wants it wider. Nothing that warrants keeping this report open. Thank you very much!