Bug 105855 - Some drop-down boxes taller than others
Summary: Some drop-down boxes taller than others
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha1+
Hardware: All All
: lowest trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Color-Picker-Widget Regressions-serie-commits Button-Controls
  Show dependency treegraph
 
Reported: 2017-02-08 12:07 UTC by Thomas Lendo
Modified: 2024-06-02 04:32 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Comparison of cell options dialog in 5.1.4.2 and 5.3.0.3 (54.55 KB, image/png)
2017-02-08 12:08 UTC, Thomas Lendo
Details
Paragraph style dialog window (Ubuntu) (49.74 KB, image/png)
2017-03-02 22:09 UTC, Thomas Lendo
Details
Small buttons in search dialog (17.05 KB, image/png)
2017-03-22 12:10 UTC, Thomas Lendo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Lendo 2017-02-08 12:07:05 UTC
Description:
Some drop-down menus are higher than other drop-down menus in the same dialog window.

Steps to Reproduce:
1. Open the "cell formatting" dialog (German: "Zellen formatieren") in Calc.
2. Go to "font effect" (German: "Sschrifteffekt") tab.
3. Six drop-down menus are higher than the three "normal high" drop-down menus.

Actual Results:  
Some drop-down menus are too high.

Expected Results:
All drop-down menus and other similar features should have the same height in all products of LibreOffice.


Reproducible: Always

User Profile Reset: Yes. The test in version 5.3.0.3 was made with a new profile.

Additional Info:
[Information automatically included from LibreOffice and me]
Locale: de
Module: SpreadsheetDocument
OS version: Windows 6.2
UI render: Standard
Layout engine: neu (new)
[Information guessed from browser]
OS is 64bit: yes
Builds ID: LibreOffice 5.3.0.3


User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Comment 1 Thomas Lendo 2017-02-08 12:08:59 UTC
Created attachment 131013 [details]
Comparison of cell options dialog in 5.1.4.2 and 5.3.0.3
Comment 2 Xisco Faulí 2017-02-08 13:38:20 UTC
Confirmed in

Version: 5.4.0.0.alpha0+
Build ID: fc53cce64400430cdc21f79c959d75fb9a26d13d
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

but not in

Version: 5.2.0.0.alpha1+
Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; 
Locale: ca-ES (ca_ES.UTF-8)
Comment 3 Thomas Lendo 2017-02-08 13:43:16 UTC
Maybe the new color palettes changes and their visual presentation in 5.3 are the cause for the changed height.
Comment 4 Xisco Faulí 2017-02-08 22:36:53 UTC
Regression introduced by:

author	Caolán McNamara <caolanm@redhat.com>	2016-11-05 20:28:27 (GMT)
committer	Caolán McNamara <caolanm@redhat.com>	2016-11-07 21:04:50 (GMT)
commit 64a708cba9b954afe3331f63c58218eb53b3d0ce (patch)
tree ddc1bea3b63f32a1c6d377c1d1dd7aee0803fb70
parent f01c49c4a89ecad2376fd0023625186e5cac642e (diff)
Revert "Reverts a commit series that cripple windows ci."
with addition of...

- svxlo-SvxColorListBox
+ svxcorelo-SvxColorListBox

Adding Cc: to Caolán McNamara
Comment 5 Caolán McNamara 2017-02-09 11:05:14 UTC
Yes, they are menu buttons now, and buttons are taller than editboxes/listboxes in the generic widget rendering backend. Everything on the same row takes the height of the tallest element. But what is the perceived problem though? That the widgets on this page are not all the same height, or that buttons are taller than listboxes or that listboxes are shorter than buttons.

I'm of the opinion that editboxes are too short, but if I make them taller am I going to get another million bugs of a regression that they are not the height they used to be.
Comment 6 Thomas Lendo 2017-02-10 09:18:30 UTC
I understand your point and that there is no simple solution possible yet. (BTW thanks for your work on the palettes thing!) The cause for my bug report was 1) the different height of boxes in the UI and 2) that some boxes are taller than in former LibreOffice versions.

Cause 2) is obsolete because they are no boxes anymore but menu buttons.
Cause 1) is still valid (not all the same height) because it looks incorrect for the user (identical elements have different heights) and we should show a consistent user interface. 

For me this is a problem for the UX and visual design team.

My suggestion is that boxes and buttons need not to have the same height if they are in a row. The rule "Everything on the same row takes the height of the tallest element." should be revoked. Then the natural height of an element would be shown with alignment at the buttom of the row (or whatever UX mean that is reasonable). But I don't know what other (negative) effects to the UI that change will have.
Comment 7 Heiko Tietze 2017-02-26 20:45:47 UTC
(In reply to Thomas Lendo from comment #6)
> For me this is a problem for the UX and visual design team.

The actual appearance of controls should be defined by the theme. On Windows the dropdown controls are smaller than buttons, except your font size is different from the default. And with Breeze on Linux the dropdowns have the same height as buttons. IIRC it's also true for gtk3. 

The 5.1.4.2 UI looks correct to me, 5.3 is different for font color vs. "Betonungszeichen" (no idea how to enable this control).
Comment 8 Heiko Tietze 2017-02-26 20:46:55 UTC Comment hidden (no-value)
Comment 9 Thomas Lendo 2017-03-02 22:09:21 UTC
Created attachment 131588 [details]
Paragraph style dialog window (Ubuntu)

Heiko, the rule "Everything on the same row takes the height of the tallest element." and that dropdowns have a different height than buttons is also true on Linux with gtk3. I tested it with Ubuntu. The icon style has no impact (Breezse or Sifr or whatelse).

Overlining and Underlining menus are taller than Strikethrough and Effects menus because of the height of the Font color, Overline color and Underline color buttons.
Comment 10 Thomas Lendo 2017-03-22 12:10:28 UTC Comment hidden (no-value)
Comment 11 Caolán McNamara 2017-03-22 12:25:57 UTC Comment hidden (no-value)
Comment 12 Heiko Tietze 2017-03-22 14:24:02 UTC Comment hidden (no-value)
Comment 13 Yousuf Philips (jay) (retired) 2017-06-26 16:25:46 UTC
Its unfortunately, but many of the controls have different default heights when on a row by themselves which would cause problems if they are on the same row. Like on the Borders tab, i have 22px for the style drop down menu/listbox, 25px for the width spinbox, and 27px for the new color control. If i switch to the Hyperlink tab, the textboxes are 27px and the target frame combobox is 29px. So to me the regular drop down menu/listbox of 22px is way to small and is quite cramped, so if they can be upped to 25px like the spinboxes, that would be a great.

There were similar issues with duplicating controls from the dialog into sidebar for the Page sidebar deck/tab. Bubli: Any input on this issue?
Comment 14 Katarina Behrens (Inactive) 2017-06-26 16:37:54 UTC
> There were similar issues with duplicating controls from the dialog into
> sidebar for the Page sidebar deck/tab. 

iirc those were about their width, not their height

> Bubli: Any input on this issue?

You people should crack open a cold beer (or kale smoothie) instead of arguing about <5 px differences
Comment 15 Yousuf Philips (jay) (retired) 2017-06-26 22:01:19 UTC
(In reply to Katarina Behrens (CIB) from comment #14)
> iirc those were about their width, not their height

Yep it was the width. :D

> You people should crack open a cold beer (or kale smoothie) instead of
> arguing about <5 px differences

Well the difference between comboboxes (29px) and drop down menu/listboxes (22px) is 7px. :D

You know us UX people are design/pixel crazy. :D

Nice laugh of my old days before i joined LO.
https://forums.solydxk.com/viewtopic.php?f=72&t=3253&p=30663
Comment 16 Caolán McNamara 2017-07-05 15:03:35 UTC
I feel the right fix is to change the "generic" backend to give buttons, listboxes and so on the same height as eachother, which is what most other toolkits do. On the other hand that is a visible change which will anger someone or other.
Comment 17 Yousuf Philips (jay) (retired) 2017-07-16 18:12:19 UTC
(In reply to Caolán McNamara from comment #16)
> I feel the right fix is to change the "generic" backend to give buttons,
> listboxes and so on the same height as eachother, which is what most other
> toolkits do. On the other hand that is a visible change which will anger
> someone or other.

Not sure about buttons, but if we could get them all the ones i previously mentioned to a minimum 25px, that would be the best solution, as glade designers would then be flexible to stretch the height further if they chose.
Comment 18 QA Administrators 2019-09-28 03:05:33 UTC Comment hidden (obsolete)
Comment 19 Thomas Lendo 2019-10-12 20:09:22 UTC
Unchanged in Version: 6.3.2.2 (x64)
Build-ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win
Comment 20 Thomas Lendo 2020-07-15 09:56:55 UTC
Same in Version: 7.1.0.0.alpha0+ (x64)
Build ID: ffe503b62f9a508285ed06ef977f91604130579a
CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win
Locale: de-AT (de_AT); UI: en-US
Calc: threaded
Comment 21 Caolán McNamara 2020-07-15 10:05:18 UTC
its not going to get changed unless someone changes it
Comment 22 QA Administrators 2022-07-16 03:53:54 UTC Comment hidden (obsolete)
Comment 23 Thomas Lendo 2023-07-10 04:59:08 UTC
Can't reproduce on Ubuntu/Gnome anymore:
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 77fca616e0bd79e0b405fd0b3543cf8e94e15df3
CPU threads: 2; OS: Linux 5.8; UI render: default; VCL: gtk3
Comment 24 Dieter 2023-10-15 16:42:44 UTC
(In reply to Thomas Lendo from comment #23)
> Can't reproduce on Ubuntu/Gnome anymore

But still present in Windows?