Bug 143246 - Color picker doesn't load previously-picked color
Summary: Color picker doesn't load previously-picked color
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.1.0.3 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Color-Picker-Dialog
  Show dependency treegraph
 
Reported: 2021-07-07 21:28 UTC by Ryan Johnson
Modified: 2024-01-22 12:43 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
color picker uses original color not last color (117.96 KB, image/png)
2021-07-07 21:28 UTC, Ryan Johnson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Johnson 2021-07-07 21:28:47 UTC
Created attachment 173433 [details]
color picker uses original color not last color

Steps:

Modify paragraph style.
Change font color.
Observe custom color picker loads wrong color.

It loads the color that was selected at instantiation of the Paragraph Style editor. The color that is passed to the color picker does not reflect any changes during the lifetime of the Paragraph Style window, when this would make the most sense.

The user wants to change the color, apply it to see how it looks, and then adjust the color again if it doesn't look right. They don't want to start from the original color. They want to start from the last color they picked when changing it again.
Comment 1 V Stuart Foote 2021-07-08 13:29:50 UTC
Confimring behavior on
Version: 7.1.5.1 (x64) / LibreOffice Community
Build ID: 2ca94649fd6dbdcab938c55c28b6a950a9634a34
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

I understand the work flow, making sucessive changes in text color for the paragraph style being edited.  

Something seems a bit off. A color swatch picked from the active palette, or from the bar of recents, will reset the base color for the 'Custom Color...' picker widget immediately. Yet a color pick made from the widget does not. Both show the selected color in the text preview--but base color value for the custom color widget does not get updated.

I don't think it is intentional (to be able to revert a color pick) so seems like an implementation issue.  Just not sure what the UI behavior should be mixing the colors from the active palette with the custom color picker.
Comment 2 Heiko Tietze 2021-07-09 07:04:20 UTC
And "Apply" is not taking the color into the list of recently used. But Ok does, and shows this color in the picker later. Don't know if this was done intentionally and the use case to keep the previous color so it's possible to reset after Apply is quite far-fetched. So let's treat this as a bug.

Steps again:

1. Right click a paragraph style on the Stylist
2. Change the font color to a custom color (eg from yellow to red)
3. Apply
4. Open the custom color picker again and it's initialize with the original color (yellow) not the actual (red)
Comment 3 BogdanB 2024-01-20 20:36:50 UTC
Heiko, could you test again on 24.2? I tested on Linux, and it is working well. I see this is a Windows bug, but to be sure, it was not solved meanwhile.

Version: 24.2.0.2 (X86_64) / LibreOffice Community
Build ID: b1fd3a6f0759c6f806568e15c957f97194bbec8f
CPU threads: 16; OS: Linux 6.5; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 4 V Stuart Foote 2024-01-21 15:07:15 UTC
Issue with the 'Custom color...' dialog not updating to keep the previous color pick while open continues. Maybe revisit the STR, but issue is with the custom color picker 'Pick a color' widget *while current style editing remains open*--i.e. making successive picks.

Once the style edit is closed and reopened, the last custom color pick is visible, on the recent color bar and also on the 2D 'Pick a color' mixer widget where the target "circle" shifts appropriately.

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: b8e393686c4ab6a69b091240065f440eadfff230
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 5 Heiko Tietze 2024-01-22 09:40:52 UTC
(In reply to BogdanB from comment #3)
> Heiko, could you test again on 24.2? I tested on Linux..

Edit Style > change font color > apply > escape or cancel > reopen. User-defined color is shown for both Linux and Windows.

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 91ebb47f86d91f71c3e490976ee5560d18bfb3be
CPU threads: 32; OS: Linux 6.7; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (en_US.UTF-8); UI: en-US
Calc: threaded

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d26fa6f6a27da598f0e3cfc54a46ef8d0a607570
CPU threads: 16; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win
Locale: de-DE (en_DE); UI: en-US
Calc: threaded

=> WFM (except Stuart experience something different)
Comment 6 V Stuart Foote 2024-01-22 12:43:50 UTC
(In reply to Heiko Tietze from comment #5)
> (In reply to BogdanB from comment #3)
> > Heiko, could you test again on 24.2? I tested on Linux..
> 
> Edit Style > change font color > apply > escape or cancel > reopen.
> User-defined color is shown for both Linux and Windows.

In fact I do get that same behavior with the color palette widget, i.e. update after close/reopen. Only if you complete a color pick, closing the custom color widget, does it refreshes the "Color picker" values with that pick. 

But that is *not* the bug reported by OP as shown in attachment 173433 [details]

Rather the issue of OP is with the "Custom color..." widget, that while the color is applied to a style or to DF of an object being modified--the color widget values are not updated, neither added back to the recents bar nor the starting swatch and hue for the 2D mixer. So even though the color of the style or DF is changed, until the style/DF dialog is closed, the color is unavailable to the widget.

Seems issue is with the custom color plumbing--it allows the testing additional color selections for style or DF within a session with the custom widget, but does not correctly track with nor update its values *during* the process.

It makes color adjustments with the dialog/widget a "one and done" only UX. And the the Custom Color... work flow inconsistent / our of sync.