- Open one of the apps, and open a Custom Color... color picker, eg. in Writer for the text color. - In the dialog, click inside the Hue band in various places. => The main color area isn't updated, and shows the default white/red/black range of colors. If you pick a color, the correct color will be chosen, as can be seen in the color preview in the bottom left corner. Also, from now, clicking inside the Hue band correctly updates the area. So it's only a small inconvenience, but you have to pick a color once in the dialog to have it behave properly. Observed using LO Version: 7.4.0.0.beta1+ (fe3be12afd810e17427601178b5d186364bef8de) / Ubuntu. This is a regression from the following commit in 6.0, bibisected to its 5.4 backport using repo bibisect-linux-64-5.4. Adding CC: to Caolán McNamara. https://cgit.freedesktop.org/libreoffice/core/commit/?id=6ddd8fcf5c92936de2a3f9d824b06a9f7dc5a86a author Caolán McNamara <caolanm@redhat.com> 2017-09-28 11:19:57 +0100 committer Caolán McNamara <caolanm@redhat.com> 2017-09-28 21:20:30 +0200 Resolves: tdf#112680 start color picker with currently selected color
I imagine the problem is that the initial color is "Automatic"
Now that I look at it I don't know if I can do anything useful here. The change was to take the current color rather than the previously used color in the dialog which is a sensible enough decision. And so basing the dialog on the current color vs some arbitrary color from the past. The "automatic" is seen as white (circle is visible at top left corner) so the same issue is there with a base of white, and also with a base of black (or even 0x808080) which could be another valid choice for automatic. And for those extremes with the default selection of "hue" as the thing controlled by the bar then any choice along the bar just doesn't have an impact on the final color.
I'll add needsUXEval because there's its not technically broken IIUC and I'm not sure where to go here.
Had a hard time to follow since font color from toolbar/sidebar has some default. But when starting at the character dialog > font effects the issue becomes clear: automatic is none. Can we use the true black/white colors in case of Automatic?
what actually happens is we do use white here for automatic. And so the selected color is white (circle is in top left corner) and that sort of color is the type where changing the hue has no visible effect (same would happen for black)
(In reply to Caolán McNamara from comment #5) > we do use white here for automatic ... changing the hue has no visible effect True, all works as excepted (with some background knowledge) => INV.
(In reply to Heiko Tietze from comment #6) > True, all works as excepted (with some background knowledge) => INV. I must disagree with that. I understand the code works in a certain way, but it doesn't match what a user would expect.
Created attachment 180945 [details] Screencast from GIMP The HUE angles of pure white remains white. The problem is that our HUE band misses the saturation/brightness. And the only solution is to combine the HUE band and the RGB space. But looking at the way it's implemented in GIMP I think we can do the same - and meet the user expectation. That is to apply the HUE angle at the RGB space while keeping the position at white or black. Caolan, is that much effort?
The gimp dialog totally baffles me as well, maybe we should just preselect "Red" instead of Hue as the default and then the dialog works in a way that I can at least understand, the band controls the "Red" axis and green/blue are vertical/horizontal in the pane. I can only really understand RGB and I'm probably not alone.
The exercise is to change hue with white/black - which should keep the color but takes the hue selection into the rgb space. If the dialog opens from white it's a good idea to use red as a starting value. Seems we have two problems to solve ;-)
Removing UX, the problem is clear and needs a solution. Either by setting a default and allowing to change HUE in case of white/black or by abandoning this color representation in favor of a combined color space.
figured this out finally with bug 151711 *** This bug has been marked as a duplicate of bug 151711 ***