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
Created attachment 131013 [details] Comparison of cell options dialog in 5.1.4.2 and 5.3.0.3
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)
Maybe the new color palettes changes and their visual presentation in 5.3 are the cause for the changed height.
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
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.
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.
(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).
needsUXEval requires manual CC'ing to libreoffice-ux-advise@lists.freedesktop.org
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.
Created attachment 132068 [details] Small buttons in search dialog Has the button appearance problem in the attached search dialog the same cause as the menu buttons in the paragraph style dialog? It seems the buttons has the same height as the checklist entries in front of them in the same row. (screenshot made with LibO 5.3.0.3)
re #10, no
(In reply to Thomas Lendo from comment #10) > Created attachment 132068 [details] > Small buttons in search dialog It has been fixed acc. bug 105371, available in 5.4.
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?
> 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
(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
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.
(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.
Dear Thomas Lendo, 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Unchanged in Version: 6.3.2.2 (x64) Build-ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win
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
its not going to get changed unless someone changes it
Dear Thomas Lendo, 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
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
(In reply to Thomas Lendo from comment #23) > Can't reproduce on Ubuntu/Gnome anymore But still present in Windows?