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.
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.
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.
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.
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?
(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.
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.
(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.
*** Bug 129811 has been marked as a duplicate of this bug. ***