Bug 104130 - SIDEBAR: Line and arrow style labels appearing in comboboxes of Line content panel
Summary: SIDEBAR: Line and arrow style labels appearing in comboboxes of Line content ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha0+
Hardware: All Windows (All)
: medium trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Sidebar-Properties-Line Arrow_Style
  Show dependency treegraph
 
Reported: 2016-11-23 15:11 UTC by Telesto
Modified: 2024-04-13 03:14 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot (6.79 KB, image/png)
2016-11-23 15:12 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2016-11-23 15:11:44 UTC
Description:
The explaining text within the combobox in the line content panel is cut off. 

Steps to Reproduce:
1.Open Draw
2.Insert a shape
3.Select the shape
4.Look "Line' content panel within the properties deck

Actual Results:  
There is a explaining text within the combobox which option is selected, but is just partly visible

Expected Results:
The explaining text which option is selected should be removed


Reproducible: Always

User Profile Reset: YES

Additional Info:
Version: 5.3.0.0.alpha1+
Build ID: 02ec51c7e0bf9320b32ec73233ecaaf160448776
CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-20_23:12:18
Locale: nl-NL (nl_NL); Calc: CL


User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Comment 1 Telesto 2016-11-23 15:12:25 UTC
Created attachment 128962 [details]
Screenshot
Comment 2 Buovjaga 2016-11-28 20:31:01 UTC
Confirmed on Win, but not on Linux. On Linux, no text is visible. Tested kde4 and gtk3 backends.

Win 10 64-bit
Version: 5.3.0.0.alpha1+
Build ID: 395295a40c24a49c12415ec803860a888d734515
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-11-18_01:30:57
Locale: fi-FI (fi_FI); Calc: group

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha0+
Build ID: 368de904974b18dc5a8d237e046c0ed005f7c85d
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; Layout Engine: new; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on November 26th 2016

Arch Linux 64-bit, KDE Plasma 5
Version: 5.2.3.3
Build ID: 5.2.3-1
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Comment 3 Yousuf Philips (jay) (retired) 2017-01-19 14:25:56 UTC
This doesnt seem to be a problem to me as the preview is visible and the text is beneficial when the drop down menu is open and not crucial when it is closed.

So WFM. @Heiko, @Stuart, @Cor: Whats your take?
Comment 4 Heiko Tietze 2017-01-19 14:48:33 UTC
(In reply to Yousuf Philips (jay) from comment #3)
> @Heiko...: Whats your take?

In fact rather than showing all text (the middle dropdown has also labels) we would better go with graphics only, if those were something that can be separated from the label. But likely it isn't, so WONTFIX anyway.
Comment 5 V Stuart Foote 2017-01-19 15:35:14 UTC
Those are not descriptions, rather they are ODF compliant names for the style exposed to the UI.

On Windows 10 Pro 64-bit en-US with
Version: 5.3.0.2 (x64)
Build ID: 5ad7b2889021c491af62f7930a4b1cb631392f16
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

Having the style name visible on the droplist is helpful, and seems to fit the with "Line with Fine Dots" style the widest in en-US. 

Believe it is correct to retain the naming of the style in the drop list, as opening the more options Line dialog exposes the Line Styles and Arrow Styles elements in the ODF. The applied styles can be modified, and additional styles added--but the actual _name) is significant and should probably be shown in full--or possibly be provided as tooltips on mouseover of elements in the drop list(s).
Comment 6 Heiko Tietze 2017-01-20 09:39:33 UTC
(In reply to V Stuart Foote from comment #5)
> ...the actual _name) is significant and should
> probably be shown in full--or possibly be provided as tooltips on mouseover
> of elements in the drop list(s).

Are you talking about to show the names when dropdowns are closed or if they are expanded? The latter is unquestioned, I hope.
Comment 7 V Stuart Foote 2017-01-20 14:28:58 UTC
(In reply to Heiko Tietze from comment #6)
> (In reply to V Stuart Foote from comment #5)
> > ...the actual _name) is significant and should
> > probably be shown in full--or possibly be provided as tooltips on mouseover
> > of elements in the drop list(s).
> 
> Are you talking about to show the names when dropdowns are closed or if they
> are expanded? The latter is unquestioned, I hope.

When droplist is closed, the graphical representation is somewhat generic (not accurately representing the style) and as noted in this issue the applied style _NAME_ is only partially visible in the closed combobox GUI.  

I would say need to improve the graphical "preview" and remove the style NAME (both collapsed and when drop list is open) but must then implement a tooltip based on the style NAME.

And of course for those that prefer just text, the org.openoffice.Office.Common StylesAndFormatting "Preview" toggle property in expert configuration might need to be extended to include styles of the graphical objects.
Comment 8 Cor Nouws 2017-01-20 18:16:13 UTC
(In reply to Yousuf Philips (jay) from comment #3)
> This doesnt seem to be a problem to me as the preview is visible and the
> text is beneficial when the drop down menu is open and not crucial when it
> is closed.
> 
> So WFM. @Heiko, @Stuart, @Cor: Whats your take?

Agree. However, it looks nicer on Linux:
only preview is visible if the list is collapsed, and the open list is aligned on the right side of the box, showing preview and text
Comment 9 Yousuf Philips (jay) (retired) 2017-02-04 13:56:30 UTC
(In reply to V > When droplist is closed, the graphical representation is somewhat generic
> (not accurately representing the style) and as noted in this issue the
> applied style _NAME_ is only partially visible in the closed combobox GUI.  

Yes the label is partially visible on windows and that needs to be fixed as it shouldnt be visible, as it isnt on linux, and how it was intended to be from the redesign.

> I would say need to improve the graphical "preview" and remove the style
> NAME (both collapsed and when drop list is open) but must then implement a
> tooltip based on the style NAME.

I would be for improving the preview, but against the removal of the name, especially as its important to a11y (bug 101886) and believe even a11y would benefit from it.

(In reply to Cor Nouws from comment #8)
> Agree. However, it looks nicer on Linux:
> only preview is visible if the list is collapsed, and the open list is
> aligned on the right side of the box, showing preview and text

Yep this is what this bug should fix.
Comment 10 QA Administrators 2018-02-05 03:27:37 UTC Comment hidden (obsolete)
Comment 11 Roman Kuznetsov 2019-03-15 20:59:33 UTC
don't repro in

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 13a260f59e421f3e67845f8f2eb22b8f0f8fcaf0
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-11_02:46:09
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded

Status->WFM
Comment 12 Telesto 2019-03-15 22:53:48 UTC
(In reply to Roman Kuznetsov from comment #11)
> don't repro in
> 
> Version: 6.3.0.0.alpha0+ (x64)
> Build ID: 13a260f59e421f3e67845f8f2eb22b8f0f8fcaf0
> CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
> TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-11_02:46:09
> Locale: ru-RU (ru_RU); UI-Language: en-US
> Calc: threaded
> 
> Status->WFM


Weird, still the same for me
Version: 6.3.0.0.alpha0+
Build ID: bbf9b65f91e8136fa1a2e17960944b8720f5d58e
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-03-15_09:56:33
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: threaded
Comment 13 Buovjaga 2019-03-16 07:18:07 UTC
I see Roman tested with OpenGL activated. Any difference with it deactivated?
Comment 14 Cor Nouws 2019-03-16 13:56:20 UTC
no labels visible at all beside the line preview in the combo boxes with 

Version: 6.3.0.0.alpha0+
Build ID: 17b25fd3df237a64d6a28fbc57b869e080963193
CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-03-13_20:42:25
Locale: nl-NL (nl_NL.UTF-8); UI-Language: en-US
Calc: threaded

Setting openGL to forced in advanced options, makes no difference
Comment 15 Xisco Faulí 2019-03-22 12:22:37 UTC
@Telesto,
Do you see the label in the drawing object toolbar if you insert a line in writer ?
To me, this is not a bug...
Comment 16 QA Administrators 2021-03-22 04:19:09 UTC Comment hidden (obsolete)
Comment 17 QA Administrators 2024-04-13 03:14:54 UTC
Dear Telesto,

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