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. ***
