Bug 149600 - Hue band in color picker dialog doesn't react to clicks before picking a color
Summary: Hue band in color picker dialog doesn't react to clicks before picking a color
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
5.4.3.2 release
Hardware: All All
: low trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Color-Picker-Dialog
  Show dependency treegraph
 
Reported: 2022-06-18 05:15 UTC by Aron Budea
Modified: 2022-06-27 09:15 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Screencast from GIMP (2.20 MB, image/gif)
2022-06-24 08:20 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2022-06-18 05:15:32 UTC
- 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
Comment 1 Caolán McNamara 2022-06-18 13:33:26 UTC
I imagine the problem is that the initial color is "Automatic"
Comment 2 Caolán McNamara 2022-06-18 14:09:34 UTC
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.
Comment 3 Caolán McNamara 2022-06-22 09:51:07 UTC
I'll add needsUXEval because there's its not technically broken IIUC and I'm not sure where to go here.
Comment 4 Heiko Tietze 2022-06-23 12:49:00 UTC
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?
Comment 5 Caolán McNamara 2022-06-23 13:20:21 UTC
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)
Comment 6 Heiko Tietze 2022-06-23 14:13:36 UTC
(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.
Comment 7 Aron Budea 2022-06-23 14:33:48 UTC
(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.
Comment 8 Heiko Tietze 2022-06-24 08:20:39 UTC
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?
Comment 9 Caolán McNamara 2022-06-24 09:40:20 UTC
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.
Comment 10 Heiko Tietze 2022-06-24 10:12:03 UTC
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 ;-)
Comment 11 Heiko Tietze 2022-06-27 09:15:43 UTC
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.