Multi-color internal clipboard

[thezbyg]

Original issue 36 created by thezbyg on 2011-05-06T04:34:08.000Z:

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

[thezbyg]

Comment #1 originally posted by thezbyg on 2011-05-06T11:39:04.000Z:

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.

[thezbyg]

Comment #2 originally posted by thezbyg on 2011-05-25T04:18:41.000Z:

So, how is this going?

[thezbyg]

Comment #3 originally posted by thezbyg on 2011-05-26T05:31:28.000Z:

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

[thezbyg]

Comment #4 originally posted by thezbyg on 2011-05-26T16:23:21.000Z:

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

[thezbyg]

Comment #5 originally posted by thezbyg on 2011-05-27T03:57:59.000Z:

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.

[thezbyg]

Comment #6 originally posted by thezbyg on 2011-05-29T08:55:27.000Z:

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

[thezbyg]

Comment #7 originally posted by thezbyg on 2011-06-05T14:17:01.000Z:

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.

[thezbyg]

Comment #8 originally posted by thezbyg on 2011-06-06T17:11:42.000Z:

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

[thezbyg]

Comment #9 originally posted by thezbyg on 2011-06-06T17:44:00.000Z:

Selection issues solved in revision 85b089216430.

[thezbyg]

Comment #10 originally posted by thezbyg on 2011-07-10T20:13:35.000Z:

Color order reversing fixed in revision 9a07528f6645

[thezbyg]

Comment #11 originally posted by thezbyg on 2011-08-19T01:21:36.000Z:

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.

[thezbyg]

Comment #12 originally posted by thezbyg on 2011-08-21T16:19:47.000Z:

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

[thezbyg]

Comment #13 originally posted by thezbyg on 2013-05-03T12:23:43.000Z:

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.

[thezbyg]

Comment #14 originally posted by thezbyg on 2013-12-24T22:55:28.000Z:

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.