Bug Hunting Session
Bug 90721 - TOOLBAR: Line color button has black as its initial color
Summary: TOOLBAR: Line color button has black as its initial color
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.3.6.2 release
Hardware: Other All
: medium normal
Assignee: Maxim Monastirsky
URL:
Whiteboard: target:5.3.0
Keywords: bibisectRequest, needsDevEval, regression, topicUI
Depends on:
Blocks: ImpressDraw-Toolbars
  Show dependency treegraph
 
Reported: 2015-04-19 21:04 UTC by Yousuf Philips (jay) (retired)
Modified: 2016-09-12 19:35 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
drawing toolbar in draw (25.23 KB, image/png)
2015-04-21 20:41 UTC, Yousuf Philips (jay) (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2015-04-19 21:04:15 UTC
Steps:
1) Open Impress or Draw
2) Look at the line color split button in the toolbar and it is set to black
3) Draw a shape and the line color will be blue

LibO 4.2 and prior had a drop down menu for line color and it was correctly set. Opening the split line color button will correctly show that blue is selected in the palette, so this issue is only of the color filled over the line color button.

I guess this could be considered a regression, so i'm setting it in the keywords, but if others disagree, please remove it.

Version: 5.0.0.0.alpha0+
Build ID: 211c12b9c64facd1c12f637a5229bd6a6feb032a
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-04-18_00:37:15
Comment 1 raal 2015-04-21 09:24:07 UTC
I can confirm with LO 4.4.2, win7

Jay, with Writer is the same problem -  component LibreOffice?
Comment 2 Yousuf Philips (jay) (retired) 2015-04-21 12:20:28 UTC
Yes the problem is also visible by default in Impress, so changing component.

In Writer, if you open the 'Drawing Objects Properties' toolbar it shows the same, though most people wouldnt notice it as that toolbar is contextual and opens up only after drawing a shape.

@Matthew: Not sure if this needs bibisecting, but i'll leave it up to you to decide.

@Qubit: I would consider this a MAB, as it shows users incorrect information and a regression because of the change of the control from a drop down list to a button.
Comment 3 Maxim Monastirsky 2015-04-21 14:11:16 UTC
Well, it was done by me on purpose. It's much like the font color button has a red color by default, while the default text color is black. Otherwise (i.e. having blue as default, while the default line color is also blue), the first clicking on that button would have no visible effect.
Comment 4 Yousuf Philips (jay) (retired) 2015-04-21 14:44:27 UTC
The problem with the black in that .uno:XLineColor acts differently to Fill Color (.uno:FillColor) and Area Style/Filling (.uno:FillStyle) which show the current insert behaviour and that is the most important thing to show.

We default highlighting you yellow as that is the most likely color going to be used for highlight. Defaulting to red for font color is likely something from that is just used from olden days rather than it having some stats behind it to show that is the most popular color to change text to.
Comment 5 Maxim Monastirsky 2015-04-21 15:46:05 UTC
(In reply to Jay Philips from comment #4)
> The problem with the black in that .uno:XLineColor acts differently to Fill
> Color (.uno:FillColor)
While it seems so, in reality it's not the case. .uno:FillColor has blue hardcoded inside it, the same way .uno:XLineColor has black. None of them are showing the actual color (Assuming you are talking about .uno:FillColor when it's placed on a toolbar, not about the sidebar variation). So you're free to propose a different color for .uno:FillColor too.

> and Area Style/Filling (.uno:FillStyle) which show
> the current insert behaviour and that is the most important thing to show.
So you don't want the line color button to be a split button? Back in 2012 UX guys filled bugs to convert all color buttons to split buttons - see the meta-bug at Bug 45671, and that's what I did.

> We default highlighting you yellow as that is the most likely color going to
> be used for highlight. Defaulting to red for font color is likely something
> from that is just used from olden days rather than it having some stats
> behind it to show that is the most popular color to change text to.
Sure, I'm not defending the red color (nor the black), I'm just referring it as an example that illustrates how split buttons work. And IIRC there were requests to remember the last used color between sessions (for other color buttons too), and in that case the initial color will be different anyway.
Comment 6 Yousuf Philips (jay) (retired) 2015-04-21 20:41:50 UTC
Created attachment 114995 [details]
drawing toolbar in draw

(In reply to Maxim Monastirsky from comment #5)
> While it seems so, in reality it's not the case. .uno:FillColor has blue
> hardcoded inside it, the same way .uno:XLineColor has black. None of them
> are showing the actual color (Assuming you are talking about .uno:FillColor
> when it's placed on a toolbar, not about the sidebar variation). So you're
> free to propose a different color for .uno:FillColor too.

Though blue maybe hardcoded in .uno:FillColor, it is the same blue fill color (#729fcf) that appears when you draw a shape.

> So you don't want the line color button to be a split button? Back in 2012
> UX guys filled bugs to convert all color buttons to split buttons - see the
> meta-bug at Bug 45671, and that's what I did.

No i would like .uno:XLineColor to show the default border color that appears when you draw a shape.

> Sure, I'm not defending the red color (nor the black), I'm just referring it
> as an example that illustrates how split buttons work. And IIRC there were
> requests to remember the last used color between sessions (for other color
> buttons too), and in that case the initial color will be different anyway.

Well if it does remember the last used color between sessions, then line color should show whatever that color is.

You can see in the attached screenshot the drawing toolbar in draw that i wish to implement. It is to contain line color and fill color buttons that display the color that will appear when you draw a new shape, like what most drawing apps have. But if line color appears in black when its actually coloring the shape border with dark blue, the purpose of such a button would be useless as it doesnt show what is being drawn.
Comment 7 Yousuf Philips (jay) (retired) 2015-05-01 09:41:07 UTC
It might be a good idea if these colors weren't hardcoded and a user is able to modify this default.
Comment 8 Robinson Tryon (qubit) 2015-12-13 11:24:16 UTC Comment hidden (obsolete)
Comment 9 Xisco Faulí 2016-09-12 12:32:54 UTC
Adding keyword 'bibisectRequest'.
Comment 10 Commit Notification 2016-09-12 19:35:09 UTC
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c4b520160cc1e3caac836cc2ad64df10d93a6dbc

tdf#90721 Line color initial behavior similar to fill color

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.