Bug 124418 - 'Pick a Color' dialog: Give option to add a color to the custom palette
Summary: 'Pick a Color' dialog: Give option to add a color to the custom palette
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 129811 (view as bug list)
Depends on:
Blocks: Color-Picker-Dialog
  Show dependency treegraph
 
Reported: 2019-03-29 09:10 UTC by Dieter
Modified: 2020-01-05 17:16 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Mockup (43.50 KB, image/png)
2019-04-02 07:54 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dieter 2019-03-29 09:10:59 UTC
It is possible to add a custom color with an own name to the custom palette via Format => Page => Area => Color. I think tis possibility is not known very well. It would be great, if this option would also be available via the "Pick a Color"-dialog.
Comment 1 Heiko Tietze 2019-03-29 09:35:05 UTC
We should keep the color picker simple, i wouldn't add more functions there. The color tab is not only shown on Format > Page but all property dialogs and should be not too hard to find.

My take > WFM.
Comment 2 V Stuart Foote 2019-03-29 14:07:15 UTC
This is a needed enhancment.

Advantage to including the "Add" 'a named color' to custom palette via the "Pick a Color" dialog directly would be efficiency.

Most work flows benefit when a named color, rather than its RGB hex value, is  available for reuse. 

Beleive our mechanism for this is "only" available on the Area dialog's Color mode.

The common use color picker can only set a RGB color to be assigned to any object's color attribute (for points, lines, polygons) and color then appears as a recent. But you must now go back through the Area dialog to capture that color for persistent reuse via user profile. The Add button creates CustomColor and  CustomColorName stanzas in registrymodifications.xcu

Addition of the single Add button for the dialog, perhaps named "Capture" or even "Custom", to the picker is reasonable expenditure of GUI space to support better management of user colors. Button action would have to complete the color pick, and then launch the colorname dialog.
Comment 3 Heiko Tietze 2019-04-02 07:54:06 UTC
Created attachment 150475 [details]
Mockup

Okay, adding the button to the "Pick a Color" dialog doesn't affect the floating picker widget and makes sense. Let's put it underneath the parameters.
Comment 4 Thomas Lendo 2019-09-24 19:54:41 UTC
Adding such a button to the 'Pick a Color' dialog is a good idea. But the dialog already is very high. Can we add the button without making the dialog bigger?

I like the button name in your mockup, Heiko, as it describes what the command does. A short 'Capture' or 'Add' will not be understood. After clicking on that, the 'Name' dialog opens as it does when adding a custom color via the Area color tab?
Comment 5 Heiko Tietze 2019-09-25 06:05:04 UTC
(In reply to Thomas Lendo from comment #4)
> But the dialog already is very high.

We could kill the pointless radio buttons and place the spinners in one row

RGB:
[  0]  [255]  [  0]
HEX#:
[        000FFF000]
HSB
[100]  [ 20]  [ 50]
CMYK
[ 0] [100 [100 [23]

-> Add to Custom Color Palette
(as input controls lack on labels, not a big deal here, we should show it per tooltip)

> After clicking on that, the 'Name' dialog opens as it does when adding a custom
> color via the Area color tab?

Yes, the usual behavior.
Comment 6 V Stuart Foote 2019-09-25 13:28:26 UTC
Heiko, (In reply to Heiko Tietze from comment #5)
> We could kill the pointless radio buttons and place the spinners in one row
> 

Why do you call them pointless? They control the palette layout for using the GUI rather the spin boxes or slider.

Have noticed clips of your GUI do not show the actual picker, are you clipping it out of your snips or is it suppressed on your os/DE

On Windows builds it is always present and the selection disk of the tool will be positioned on the palette blend depending on the layout made by radio button.
Comment 7 Heiko Tietze 2019-09-25 14:49:12 UTC
(In reply to V Stuart Foote from comment #6)
> Why do you call them pointless? They control the palette layout for using
> the GUI rather the spin boxes or slider.

You are right, radio buttons are handy when pointing on the area. They are not when playing with the spinners.
Comment 8 Mike Kaganski 2020-01-05 17:16:22 UTC
*** Bug 129811 has been marked as a duplicate of this bug. ***