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

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by johannne...@googlemail.com on 18 Nov 2013 at 8:05

[GoogleCodeExporter]

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.

Original comment by fintic...@gmail.com on 18 Dec 2013 at 10:16

[GoogleCodeExporter]

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.

Original comment by fintic...@gmail.com on 18 Dec 2013 at 11:01

Attachments:

• movecopy.diff

[GoogleCodeExporter]

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.)

Original comment by fintic...@gmail.com on 18 Dec 2013 at 11:47

Attachments:

• current_movecopy_v2.diff

[GoogleCodeExporter]

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

Original comment by thezbyg on 19 Dec 2013 at 10:17

• Changed state: Started

Attachments:

• current_movecopy_v3.diff

[GoogleCodeExporter]

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.

Original comment by fintic...@gmail.com on 19 Dec 2013 at 10:40

[GoogleCodeExporter]

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.

Original comment by fintic...@gmail.com on 20 Dec 2013 at 12:10

Attachments:

• current_movecopy_v4.diff

[GoogleCodeExporter]

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

Patch committed in Rev c921becc2175

Original comment by 00a...@gmail.com on 24 Dec 2013 at 10:40