- 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.
Yes, that seems to be a feedback problem. I commented out the last
gtk_signal_emit (GTK_OBJECT (csel), cs_signals[CHANGED]);
in sp_color_gtkselector_gtk_changed(), and jittering is gone, although the object color is not updated. So you just need to make sure this signal you emit is caught by the right listeners (i.e. the canvas objects) and not the color widget itself. Maybe encosing the emit into a pair of block/unblock functions might help.
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.
Of course we need a separate color palette widget, ideally dockable to the document window, but for now a small palette inside the picker would be nice too.
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.
Yes, and a current color widget too (see wiki).
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?
I don't like that option too. Would be ideal to find a way to tweak the standard GTK widget.
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".
Then it must be named more descriptively, e.g. "Store color as:", but then "Any" sounds kind of funny.
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.
Maybe, although I don't feel a need for this. Maybe just me. I think the GTK color wheel can be the default picker most people use, and the others are just "for completeness" and for special purposes. The wheel makes it possible to enter RGB values anyway, and it's not that you'll want to move RGB sliders very often, because HSV is much more natural to an artist.
In either case, hooking the color selections up to the new overall preferences setting dialog would be handy.
Yes, that's where it belongs IMHO, without cluttering the actual picker interface. Please add that to the PreferencesDialog wiki page.
_________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2f...