Multi-color internal clipboard

[GoogleCodeExporter]

- to make it easier to move multiple colors within a palette.

After generating a gradient using 'mix colors' or a scheme using 'generate', I 
find I usually want to put it next to the original colors, but currently have 
to move one color at a time.

Considering that large numbers of colors can be generated (even as few as 16 
becomes troublesome), we could usefully have some way to move large numbers of 
colors around. Internal 'Cut/Copy/Paste' is the traditional solution. This 
would nicely round out the arrangement-of-colors functionality. 

Original issue reported on code.google.com by 00a...@gmail.com on 6 May 2011 at 4:34

[GoogleCodeExporter]

I agree that this is necessary, however this will require quite some changes in 
the code. I will take a look into this next week.

Original comment by thezbyg on 6 May 2011 at 11:39

• Changed state: Started

[GoogleCodeExporter]

So, how is this going?

Original comment by 00a...@gmail.com on 25 May 2011 at 4:18

[GoogleCodeExporter]

I implemented the multi-color drag from the palette, and today will try to 
implement the drop functionality.

Original comment by thezbyg on 26 May 2011 at 5:31

[GoogleCodeExporter]

Multi-color drag&drop functionality committed in revision ced9087746a9.
It still needs improvements (its quite hard to not select something while 
trying to initiate drag), but its usable

Original comment by thezbyg on 26 May 2011 at 4:23

[GoogleCodeExporter]

Yeah, works good :) Is the ability to shift a color rather than duplicate it 
(via holding SHIFT) new? It's great!
We definitely need to document that somehow -- working with any amount of 
colors without that ability to move rather than duplicate is fairly annoying.

Original comment by 00a...@gmail.com on 27 May 2011 at 3:57

[GoogleCodeExporter]

The ability to shift colors was as old as drag&drop functionality. Looks like I 
need to start writing a manual for Gpick as soon as possible :)

Original comment by thezbyg on 29 May 2011 at 8:55

[GoogleCodeExporter]

I've recently found that occasionally shift-dragging somehow reverses the order 
of the colors as they are inserted in the final position. Actually reliably 
reproducing this is hard.

Original comment by 00a...@gmail.com on 5 Jun 2011 at 2:17

[GoogleCodeExporter]

I have tried reproducing it, but couldn't get it to reverse the colors.

Original comment by thezbyg on 6 Jun 2011 at 5:11

[GoogleCodeExporter]

Selection issues solved in revision 85b089216430.

Original comment by thezbyg on 6 Jun 2011 at 5:44

[GoogleCodeExporter]

Color order reversing fixed in revision 9a07528f6645

Original comment by thezbyg on 10 Jul 2011 at 8:13

[GoogleCodeExporter]

This seems to be working quite well now. I did just notice an issue: although 
GPick seems to provide multiple colors in the drag object, dragging multiple 
colors between GPick instances only adds a single color in the instance that 
they are dropping on to.

Original comment by 00a...@gmail.com on 19 Aug 2011 at 1:21

[GoogleCodeExporter]

Ability to drag multiple colors between Gpick instances added in revision 
2b851bdf148c

Original comment by thezbyg on 21 Aug 2011 at 4:19

[GoogleCodeExporter]

I thought this issue was pretty much addressed, but I realized GPick doesn't 
fully understand its own output format -- that is, if I press Ctrl+C with 
multiple colors selected, GPick stores multiple lines to the clipboard; and 
then I press Ctrl+V to paste, but GPick only reads the first line on the 
clipboard, adding one color to the palette instead of 16. This restricts the 
means of getting multiple-colors-at-once into GPick to 'Drag and Drop from 
another GPick instance', even though any application can put multiple colors on 
the clipboard in a text format.

I've begun investigating how to fix this. It looks like the API of 
main_get_color_object_from_text needs to change to allow multiple output colors.

Original comment by fintic...@gmail.com on 3 May 2013 at 12:23

[GoogleCodeExporter]

I'm just now looking at this seriously. I've implemented multi-color output on 
the Lua side, and still need to implement it in Converters.cpp (and adjust 
accordingly further up the chain of dependencies.)

At the moment I'm considering that the Converters code should look at the input 
line-by-line, and send it line-by-line to the lua conversion machinery. That 
is, if multiple lines are in the input, the C++ conversion machinery should do 
the job of splitting them up, and aggregating returned colors into an array of 
ColorObjects.
If you disagree, please speak up. Thanks.

Original comment by fintic...@gmail.com on 24 Dec 2013 at 10:55