GNOME Bugzilla – Bug 383083
A "quick palette" for temporary color storage...
Last modified: 2006-12-08 10:30:55 UTC
I was looking for a "quick" way to save colors temporarily. One method I use is to just set the fg or bg color to the color I want to save and just use the opposite until I need to switch back. This way is very quick but it is limited to two colors... The other method is to create a palette to use temporarily, and just delete it when I'm finished - This works but it is not really that quick. (It's really a pain to do when your only working with three or four colors) What would be really nice is a combination of the two methods. I would like to suggest adding a single row of boxes to one side of the color selector just for the purpose of storing color temporarily. (This row would be there no matter which color selector you were using) How it could work: - If you left clicked on one of the boxes, it would set the foreground color to that color. - If you left clicked with a modifier key (ctrl or whatever) it would set the background color to that color. - If you right clicked on a box, it would take the current foreground color and store it in the box. Ctrl+Right-Click would store the background color... This would be just a temporary storage area - basically a visual clipboard for color... It would reset once the program was restarted... although there could be a menu entry added to the color dialog that would allow the user to save all of the colors as a palette...
Created attachment 77841 [details] Quick Palette Possible Layout...
There's a color history in the standard colors dialog for exactly this purpose.
Closing as INVALID because the feature exists for quite a while already.
The issue is usability, it's not efficient. In the current CVS, that standard dialog is not even easy to find anymore... New users will not be able to find it easily, and those who do may not choose to use it because it's not efficient...
Well, then you should probably open a new bug report and suggest how to improve the discoverability of the color history. Your proposal from comment #1 is not going to be accepted because it takes up too much space. The Colors tab must not grow any larger. We have put a lot of effort into shrinking it down to the minimal size it has now. We should even try to reduce it further.