Issue 108 in gpick: drag and drop in palette-editor; why copy as default and shift+drag is move

[gp...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 108 by johannne...@googlemail.com: drag and drop in
palette-editor; why copy as default and shift+drag is move
http://code.google.com/p/gpick/issues/detail?id=108

Hi,
First of all. awesome tool for color-palette-generation. much more better
than the build-in features in Gimp or Krita.

My only question is: why does drag and drop in the palette-editor copy the
swatch.
I have to press shift to move only.

in my opinion it'll be more intuitive, if dragging a color would move and
in example ctrl+drag would copy the swatch.

maybe there are reasons, but in my case this behavior interrupts my work
flow a bit.
of course the priority is very low.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[gp...@googlecode.com]

Comment #1 on issue 108 by fintic...@gmail.com: drag and drop in

palette-editor; why copy as default and shift+drag is move
http://code.google.com/p/gpick/issues/detail?id=108

I can see your point. I'll have a look at implementing an option that
reverses the meaning of Shift in this context (so that Shift+drag copies,
and plain drag moves), although I'd like to run this idea past Albertas
before committing such a change.

Note that the situation is slightly more complex than you mention, because
we also use Shift and Control for multiple selection.
This would mean that [click, shift+click and drag] would copy that set of
colors, whereas currently, [click, shift+click and drag] moves that set of
colors. To move the set of colors, you would need to [click, shift+click
(and hold), release shift, drag]; which is currently the action you need to
take if you want to copy a set of colors.

[gp...@googlecode.com]

Comment #2 on issue 108 by fintic...@gmail.com: drag and drop in

palette-editor; why copy as default and shift+drag is move
http://code.google.com/p/gpick/issues/detail?id=108

Here's a very simple patch that implements this behaviour (normal drag ==
move; shift+Drag == copy). I have yet to hook it up to a user-visible
option.

Attachments:
movecopy.diff 1015 bytes

[gp...@googlecode.com]

Comment #3 on issue 108 by fintic...@gmail.com: drag and drop in

palette-editor; why copy as default and shift+drag is move
http://code.google.com/p/gpick/issues/detail?id=108

Here's a 'proper' patch, which creates a checkbox inside a new 'Drag and
Drop' subsection in the Main section of the Preferences.

I have tested this patch and it seems to work well. I will still hold off
from committing it until I have Albertas' input. In particular I wonder
whether the checkbox text "Drag moves, Shift+Drag copies" could be more
descriptive. It currently doesn't imply that 'if this option isn't on, then
Drag copies and Shift+Drag moves'.

(Note to self: If I do end up committing this, then I will need to update
the wiki accordingly.)

Attachments:
current_movecopy_v2.diff 3.1 KB

[gp...@googlecode.com]

Updates:
Status: Started

Comment #4 on issue 108 by thezbyg: drag and drop in palette-editor; why

copy as default and shift+drag is move
http://code.google.com/p/gpick/issues/detail?id=108

A couple of changes to the patch:
Moved drag&drop behavior test and logic into drag_motion function, which is
responsible for setting the preferred drag action.
Set default value of "gpick.main.dragging_moves" to true (we should prefer
standard behaviors).
Changed checkbox label to "Drag moves, Ctrl+Drag copies", because Ctrl+Drag
is the standard way of drag-copying things.

I think that radio buttons would make the selection more understandable,
for example:

Default drag&drop action:
* Move
* Copy


Attachments:
current_movecopy_v3.diff 4.2 KB

[gp...@googlecode.com]

Comment #5 on issue 108 by fintic...@gmail.com: drag and drop in

palette-editor; why copy as default and shift+drag is move
http://code.google.com/p/gpick/issues/detail?id=108

Thanks for responding so promptly :)
Interesting, I didn't know Ctrl+Drag was the standard way of drag-copying.

I agree that radio buttons would clarify things, I'll implement that using
your patch as a base.

[gp...@googlecode.com]

Comment #6 on issue 108 by fintic...@gmail.com: drag and drop in

palette-editor; why copy as default and shift+drag is move
http://code.google.com/p/gpick/issues/detail?id=108

After testing your updated patch, I noticed:

* when dragging_moves is off. Drag copies, but Ctrl+drag does not move, it
too copies. Shift+drag moves.
* When dragging_moves is on, Drag moves, and Ctrl+drag copies. Shift+drag
also moves.

I admit I don't understand DnD very well, so I left it alone.
Attached: Updated patch implementing radio buttons. I also fixed an
inconsistent default value (seen on line 95 of your patch).

The case of Ctrl+drag copying instead of moving, when dragging_moves is
off, is the only remaining problem I know of.



Attachments:
current_movecopy_v4.diff 5.1 KB

[gp...@googlecode.com]

Comment #7 on issue 108 by 00a...@gmail.com: drag and drop in

palette-editor; why copy as default and shift+drag is move
http://code.google.com/p/gpick/issues/detail?id=108

I guess it is okay to commit this, since the default behaviour works fine.

Patch committed in Rev c921becc2175