Created attachment 157186 [details] Color Name Area fill gradient visible, Area fill color not visible If you draw an shape and open the Sidebar section with Area options there you can change the fill collor. If you have an gradient (GtkComboBox + CtkCellRendererText), than you can read which colors you selected in the drop down menu, if you have only an color (GtkMenuToolButton) there is no color information. Would it be possible to have ALWAYS the Color name available. I know you have to switch from GtkMenuToolButton to something else. If an switch is not possible, can the color text be the tooltip information of GtkMenuToolButton?
it was always like this right, not a regression ?
It was alway like this yes. I think the gradient use an "old" widget and the fillcolor the new one, but again there is enought space and you can/should show the user which color (label or code) was used.
hmm, looking in it the tooltip feature exists for the tooltip for the toolitem in the main toolbar but is explicitly disabled for the "widebutton" versions in the sidebar. I see that the current color is broadcast when the context changes, but not its *name* which is possibly why things are the way they are.
yeah, trickier than it looks. We listen to the color change events, and only get the color. So to get back to its name we have to do the same as the ColorListBox does which is to look up the color in the palette, which might be too heavy to do in the sidebar on every color change
but in gradient it work. maybe you have an good idea. In general I'm looking that the sidbar is more similar so similar layouts and similar widgets.
Or just use a ColorListBox?
(In reply to Heiko Tietze from comment #6) > Or just use a ColorListBox? No, that would be a step backward as we already have the new color pickers in place which allow palette selection or use of a new 'custom' color (so no name other than a #RGB value). It already has a nice consistent UI, with only thing missing an ability to label with Name of the selected color. If we can't find a way to label with the 'Name' of a color selection, isn't the tooltip enough? Especially as majority of palettes will have no meaningful names for the colors.
Would it be possible that the color list box will open the color picked?
Created attachment 157277 [details] GtkMenuButton + ColorPicker (In reply to andreas_k from comment #8) > Would it be possible that the color list box will open the color picked? at gradient there is the color (icon + label) and when you click on the GtkMenuButton it show the ColorPicker (where you can choose the color presets and everything. So what's the reason that we can't use this behavior not only for the gradient, also for Fill Color?
(In reply to V Stuart Foote from comment #7) > No, that would be a step backward as we already have the new color pickers... mxLbFillGradFrom/To (the two gradient dropdowns) are instantiated in AreaPropertyPanelBase as ColorListBox- and they do use the new picker appearance.
(In reply to Heiko Tietze from comment #10) > (In reply to V Stuart Foote from comment #7) > > No, that would be a step backward as we already have the new color pickers... > > mxLbFillGradFrom/To (the two gradient dropdowns) are instantiated in > AreaPropertyPanelBase as ColorListBox- and they do use the new picker > appearance. So can we go with dropdown menu with color rectangular and label? I think this would be a big step into standardize the sidebar layout AND will have the benefit to know the selected color without open an dialog.
I think I would prefer to remove the color name labeling across all the controls--and then have consistent tooltip with the 'color name' (RGB, HLC, tonal) as taken from the selected palette. I don't see too much need for the label. We show the color swatch for selected color, and can show the palette it came from. Likewise for gradient the swatch is visible, and can identify the palette it is being taken from. IIRC the gradients used to be fixed, but now we can mix and match palettes. What do we gain by shrinking the color swatch to add a textual label? Simplify the 'Gradient' fill UI to match the 'Color' fills--remove the labels! But do provide the assigned color name/RGB value in tooltip. That is replace the "Fill color", "Fill gradient from", "Fill gradient to" tooltips with the color name (or value). Obviously filter import of ODF document colors would only match color names against 'standard' palette, palette in use is not recorded into the ODF. And, this is just for labeling the color fills (Color, Gradient), the patterned fills (Hatching, Bitmap, Pattern) make sense to have the labels.
(In reply to V Stuart Foote from comment #12) > remove the color name labeling across all the controls Labels are the primary identification! How do you pick "Gray 2", for example? I'm too lazy or dumb to remember if it's the second or third right. And when it comes to reddish colors it's even harder to remember in particular when your color vision is impaired.