Created attachment 128962 [details]
Screenshot

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

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?

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

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

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

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

(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

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

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

(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

I see Roman tested with OpenGL activated. Any difference with it deactivated?

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

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

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