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
I can confirm with LO 4.4.2, win7 Jay, with Writer is the same problem - component LibreOffice?
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.
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.
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.
(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.
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.
It might be a good idea if these colors weren't hardcoded and a user is able to modify this default.
Migrating Whiteboard tags to Keywords: (needsDevEval, topicUI) [NinjaEdit]
Adding keyword 'bibisectRequest'.
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.