On Dec 11, 2003, at 10:14 AM, bulia byak wrote:

...

Well... I just checked in some changes for the color selector. It needs a little more polish (mode, CMYK types, and the popup to select subsets of possible pickers) but should be ready for some initial testing and use.

Thanks! My initial impressions:

• Do the slider strips have to be so wide (i.e. tall)? I'd like to see

them take less vertical space.

Legacy behavior. I think all I need to do is tweak the layout to get that change. I was thinking about it myself, and since at least one other person cares, I'll go ahead and do that.

• Before, the slider strips expanded horizontally when you resized the

fill&stroke dialog. This was nice as it allowed to get a better resolution at the expense of screen space. Now they stay the same length no matter how you resize the window.

Minor change. Should be easy. I just need to do the layout for the notebook a little differently.

• RGB, CMYK, and HSV are all familiar abbreviations to a designer. But

"GTK+" is confusing. Is this a new color model? Better call it by what it shows, e.g. "Wheel".

Could be. :-) Or we could just use small icons, like the Gimp does. Or we could have nice names and icons and have a preference for which to show. I like the latter.

• The sliders are always black and therefore are invisible on dark

areas of the strip (this was the problem with the old picker too). They need to be made either e.g. black interior with white outline, or some pseudo 3D, or (as in Gimp) pairs of black triangle at top and white at bottom, or automatically inverting when going from light to dark and back (as is the pointer on the GTK+ wheel).

Reason it was a problem with the old picker too is that the sliders *are* the old picker. :-)

I've done Karaoke products before. You get the same basic problems there. I'll tweak that up.

• The GTK+ selector is shakey: when you move the small circle inside

the triangle, the triangle shakes and jitters. I think this is because the color itself produces HSV, but its position is determined by the RGB, and the conversion/rounding errors when the color goes to RGB and back make it unsteady. Can you ensure that the color wheen is connected to the HSV value? Also, when you move the circle to the black or white corners, the triangle snaps to the red, i.e. loses its current hue value. I think this will also be fixed if you make it reflect the HSV value, not RGB.

Guess what? Don't bug me about this one. ;-)

Actually... it is just the standard GTK+ color selector. My code only creates one and then listens for changes. All those details are handled by the GTK+ version you're running.

Although it could be a bit of feed-back loop. I'll check to make sure that's minimized.

• BTW when you resize the window, it's the color wheen in the GTK+ tab

that must be made larger so you can pick colors with better precision.

The fix of the notebook should take care of that.

• When the fill&stroke dialog has focus, the GTK+ triangle has some

ugly non-antialiased one-pixel black border. Without focus, it looks OK, no border.

This might be out in GTK+ itself.

• In Gimp, a similar GTK+ color wheel also has a small palette where

you can remember colors (in the bottom right area). Can we have it, too?

Gee, you want everything, don't you? ;-)

Actually "color palettes" were something I was going to add. For the GTK+ wheel, I just need to feed an array of colors for the palettes.

So we might need "color palettes", "color schemes" and "swatches". I think details of this would be best hashed out on jabber and on the Wiki.

• "Color name" should really be "Hex" or something like that. Besides,

it's redundant as we have the RGBA field below.

True... but it's built into the GTK+ widget. It does not have alpha (the one difference). Of course, a simple work-around is to just hide the bottom entry area when the color picker has one. Would that work better or be distracting?

• The "previously selected color" in the GTK selector is always black.

It must reflect the color we got from the program or from preferences; i.e. for "apply to selected objects", when I select a new object, both halves of the color swatch must show the same color, and then the left side should stay the same while the right one is changing.

Yeah. I have to go through and add the "previous" concept in the rest of Inkscape to make things correct. At the least the color should be the same, as you mentioned.

• The "Mode" switch at the top seems redundant (and incomplete), now

that we have the multi-tab interface for different pickers.

Aha!!! You caught me.

That's one point that I didn't finish.

It turns out that in effect that "Mode" switch was overloaded with two different meanings. First, it determined the colorspace (RGB or CMYK) that Sodipodi would use for the color. Second, it chose which version of the color picker you'd get.

I've split the second notion off into the notebook with tabs. Thus the "Mode" switch should change to only determine the colorspace to use. I was planing on "RGB", "CMYK" and "Any", with "Any" being the default. Later we might also add "Spot".

Of course, I was thinking that I should research SVG colorspace URIs and such a little more before implementing the changes to the 'generic' color selector API and the UI.

• The bottom right button that allows you to select which pickers are

shown is also redundant, IMHO. Instead, the color selector must remember (both within and across sessions) the last picker used and show it when activated. With this, removing pickers is not necessary and frees no extra space.

Well, first of all I should move alignment around so that it's not hanging off, but takes a little space from the RGBA entry area. Then no extra space would be taken up.

Persisting the state of the choses pickers is one other thing that should be done, but I delayed on. I was initially going to have two sets of choices: one for "full" areas like color dialogs, the other for "brief" areas like embedded pickers.

But... I was just thinking the other day that another approach might help. If we did named "color picker sets" then the user could change the set named "full" and the set named "brief". They could also create new sets and use them per location, or just stay with the default sets. I was thinking that this has the benefit of being simple for beginning/normal users, yet allow full customization for power users. And the coding would not be too different than for a two-state enum'ed or boolean'ed set.

In either case, hooking the color selections up to the new overall preferences setting dialog would be handy.