Bug 134407 - Too narrow preferences dialog
Summary: Too narrow preferences dialog
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected) release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
Keywords: bibisectRequest, possibleRegression
: 136029 (view as bug list)
Depends on:
Reported: 2020-06-30 02:53 UTC by Leandro Martín Drudi
Modified: 2022-01-26 04:09 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:

The View option is the most affected (35.71 KB, image/png)
2020-06-30 02:55 UTC, Leandro Martín Drudi
Linux/gtk3 (72.64 KB, image/png)
2020-07-01 09:58 UTC, Heiko Tietze
How it looks in LibreOffice 7.1 (win) (15.49 KB, image/png)
2020-07-03 09:29 UTC, Xisco Faulí

Note You need to log in before you can comment on or make changes to this bug.
Description Leandro Martín Drudi 2020-06-30 02:53:27 UTC
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: (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
Comment 1 Leandro Martín Drudi 2020-06-30 02:55:16 UTC
Created attachment 162531 [details]
The View option is the most affected
Comment 2 Xisco Faulí 2020-06-30 10:14:26 UTC
not sure whether it's on purpose having the narrow screens on mind... Anyway, adding the UX team
Comment 3 Heiko Tietze 2020-06-30 10:40:12 UTC
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.
Comment 4 Leandro Martín Drudi 2020-06-30 10:45:04 UTC
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.
Comment 5 Caolán McNamara 2020-07-01 08:54:15 UTC
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
Comment 6 Heiko Tietze 2020-07-01 09:58:16 UTC
Created attachment 162552 [details]

But why are the dropdowns properly sized on Linux and macOS but not Windows?

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
Comment 7 Caolán McNamara 2020-07-01 10:36:54 UTC Comment hidden (obsolete)
Comment 8 Heiko Tietze 2020-07-02 15:18:08 UTC
(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.
Comment 9 Adolfo Jayme Barrientos 2020-07-02 22:20:20 UTC
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).
Comment 10 Xisco Faulí 2020-07-03 09:29:47 UTC
Created attachment 162603 [details]
How it looks in LibreOffice 7.1 (win)

Not reproduced in

Version: (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
Comment 11 Leandro Martín Drudi 2020-07-03 10:52:10 UTC
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
Comment 12 Heiko Tietze 2020-07-03 20:34:47 UTC
English, German, Spanish - all fine for me.
(surprisingly the main menu is not translated in ES)

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
Comment 13 Leandro Martín Drudi 2020-07-30 21:03:06 UTC
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.
Comment 14 Xisco Faulí 2020-09-17 14:06:27 UTC
*** Bug 136029 has been marked as a duplicate of this bug. ***
Comment 15 Adolfo Jayme Barrientos 2022-01-26 04:09:20 UTC
Lessened the issue a teeny-tiny bit with commit 9f16c3b5ac3ae1c9d24fe137ff48b67f54e4899b (trunk/towards 7.4)