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".
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
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
> - 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,
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
> - "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.