New issue 69 by 00a...@gmail.com: Provide a means to replace destination
color
http://code.google.com/p/gpick/issues/detail?id=69
.. when dragging from the swatch to the palette.
I find a common usage pattern is:
1. Doubleclick on a color in a color ramp to edit it
2. Make changes; decide to replace original color with this color.
3. Drag from the swatch color into place, maybe rename to match original
item, then delete original item.
IMO the tediousness of step 3 discourages giving colors useful names. I
think Step 3 can and should be a simple operation that just replaces the
old color with the new one, keeping the name.
I currently favor implementing this via a set of keyboard shortcuts (and a
swatch context menu item) which are complementary to the current 1-6 keys --
Shift+1-6 to replace the currently selected palette color with the color in
swatch slot N, leaving the name as it is. If there is a multiple selection,
do nothing except report "Color replacement works only on individual
colors, not multiple selections" in the statusbar.
All needed functions to allow implementation of this has been added in
revision 5e97934d5f1b (call palette_list_forfirst_selected, update color
and return PALETTE_LIST_CALLBACK_UPDATE_ROW from the callback).
Colors dropped on top of palette items now replace the color and leave the
name untouched.
Your cooperative attitude impresses me :)
I'll implement the remaining part of this later today. After trying the DnD
(which is pretty helpful when you do want to replace colors), I'd like to
put that on a modifier key (Ctrl) if possible, since my experiments seem to
indicate it's fairly easy to accidentally overwrite a color this way when
you were just trying to insert it.. so I'll have a go at that too.
(IOW it's probably most usable to do the 'replace-color' action only when
dropped with Ctrl pressed)
Addressed in revision 8c5c5a82e9de -- but not closed. I need to get
CTRL+Drag working properly.. so far, I haven't found where in the source we
tell GTK+ that CTRL means one kind of drag, SHIFT means another kind, and
<no modifier key> means yet another kind.
IMO, 'color replacement' probably means GDK_ACTION_PRIVATE -- but I still
have to figure out how to tell GTK that CTRL-Dragging should trigger it.
Actually, there may be technical issues with DnD of this style, no matter
how it's implemented. For example, try generating a gradient of 16 colors,
selecting them all, and drag-and-dropping them onto one of the colors in
that gradient. Colors fold away each time you do this, and eventually it
causes a crash.
For now, I think it's wise to switch DnD back to the previous behaviour.
Unfortunately the new additions to the d&d functionality has nothing to do
with the bug that you have found. The crash most probably happens because
the reference color item (the item on which new items are dropped) gets
removed from the palette, and its iterator becomes invalid. I will add a
new issue report and investigate this further.
Ctrl key d&d implemented in revision 360be2852f99.