Listing all color names

[perdido]

OK, here is my prototype for a yad color picker with save capability.

Easy for a simpleton like myself. Looks good
I have added up to 15 colors in the save window (program will do more)


.

[MochiMoppel]

@perdido: I like your EnvyGreen. Reminds me of my IKEA coasters.

I have updated my script and my explanations. I removed the demo code as it seemed to cause some confusion.

Speaking of green brings me back to my thread topic. My focus are X11 color names, not W3C color names used in web pages. Both color schemes are largely the same, but there are still differences, which makes it all the more important not to confuse them or mix them in the same palette. Sometimes different names are used for the same color (e.g. cyan vs. aqua), sometimes the same name is used for different colors, e.g. green:

This is the W3C color named "green", chosen from the "Font colour" dropdown box in this forum software:
██████
The hex value is #008000 which makes is relatively dark

This is the X11 color named "green", usable in commands like gxmessage -bg green "Hello World"
██████
The hex value is #00FF00

[MochiMoppel]

Forum member step kindly informed me that recent yad versions don't ignore invalid options anymore, a "feature" I deliberately exploited in my yad script. I therefore applied his fix and updated the script. Should work now with all yad versions.

[Colonel Panic]

Here's a web page that you might find useful;

http://sedition.com/perl/rgb.html

[Argolance]

Bonjour,
Thanks MochiMoppel for this very useful script.
To use it easily and make it more handly, I made a little script named "yadcolmgr" (create, manage and load color palettes) I would like to share with anyone who might be interested. Your script is in the PET under the name "yadcol", with small changes so that the configuration files are stored persistently in /root/.config/yadcol and no longer temporarily in /tmp.
I also provide a script that I made for my own use a long time ago and that allows to extract colors from the current JWM theme. The colors can be dragged and dropped directly into the Yadcol window and a palette can be created this way.
[EDIT 200513]: New version, please see the post below.

Cordialement.

[MochiMoppel]

Bonjour Argolance. Sorry for the late response. I tried your scripts but didn't spend much time with them. That may be the reason why I couldn't really figure out how they work. Basically I like the idea of a central place to manage various color palelettes

Your script is in the PET under the name "yadcol", with small changes so that the configuration files are stored persistently in /root/.config/yadcol

Only if the user runs yadcolmgr first where directory /root/.config/yadcol is created.

yadcolmgr expects the user to edit the raw color text files. Not everyone's cup of tea. Maybe it would be easier for the user to integrate your yadcolmgr into yadcol. Selecting a palette from your dropdown box could automatically populate the color picker and allow instant editing without the need for text files. Haven't tried and don't know if feasible.

I also provide a script that I made for my own use a long time ago and that allows to extract colors from the current JWM theme. The colors can be dragged and dropped directly into the Yadcol window and a palette can be created this way.

Can't say much about it as it wouldn't work for me. I think it is hard coded to read /root/.jwm/jwmrc-theme, a file I don't use. My theme settings are in /root/jwmrc.

Salut

[Argolance]

Bonjour,

@MochiMoppel

Sorry for the late response.

Thanks for your comment: better late than never!

I tried your scripts but didn't spend much time with them. That may be the reason why I couldn't really figure out how they work

May be indeed...

Selecting a palette from your dropdown box could automatically populate the color picker and allow instant editing without the need for text files.

I don't know if I understood you correctly, but it seems to me that's exactly what yadcolmgr does: Create, manage and instantly load selected palette using your script yadcol (please, see the picture below). Of course, user can also, if it is useful, edit the palette of his choice in the text editor to remove duplicate colors, for example, or rename them, or convert a standard palette into a GIMP palette, as well as browse to the palettes directory to rename them, but these are additional conveniences... Maybe I should change the text in the tooltip to make it clearer?
[EDIT 200513]: I finally made a separate, more detailed help file instead of the tool-tip and took the opportunity to improve my script significantly:[lis3t]- Moved the palettes directory to the subdirectory /root/.config/yadcol/palettes
- Warning (that works properly now!) when a created palette color file already exists or when user wants to delete one.
- Multiple simultaneous instances of YadCol from a single of YadColMgr allowed
- fr translation[/list]

Can't say much about it as it wouldn't work for me. I think it is hard coded to read /root/.jwm/jwmrc-theme, a file I don't use. My theme settings are in /root/jwmrc.

What strange kind of Puppy do you use? Is there any, using JWM that doesn't have its hidden /root/.jwm folder where its themes are stored?

[EDIT 200519]: Note that if the previous version of yadcolmgr has been installed, the /root/.config/yadcol/palettes folder should be created manually and the palette files moved to it.

Cordialement.

[MochiMoppel]

I don't know if I understood you correctly, but it seems to me that's exactly what yadcolmgr does

No, that's not what I meant. My idea was to have the dropdown and the whole managing stuff in the original yad script, so there would be no need for a separate managing tool. I'm a simple minded single script guy My yad skills are getting rusty but I'll see if I can produce a demo. May take a couple of days. I understand that your solution works for you and certainly for many other users, so please don't pay too much attention to my views. Diversity is always good and my personal preferences don't matter much.

On a related subject: 3 days ago I dusted off my old mini-tower machine, which is loud but 64bit capable and tried Bionicpup64. Nice experience. However I noticed that bionicpup includes a file /root/.rgb.txt , symlinked to /usr/share/X11/rgb.txt . This makes no sense. I know that musher0 ventilated this idea earlier in this thread, but at this time it was fair for me to assume that he doesn't know how gcolor2 is supposed to work. But now it appears in bionicpub
Digging deaper I found that it has been in woof-CE since 2015 at the request of musher0. I don't blame him for not knowing better, but the guys at woof-CE should. Would dimkr be so kind and remove it? Gcolor2 needs no symlink to the X11 colors since it displays them by default. The only problem is that in woof-CE the directory /usr/share/X11 is not the place where gcolor2 would look for the rgb.txt file. This is what needs to be fixed. The file /root/.rgb.txt should not be preinstalled and in no case symlinked to the X11 colors.

[EDIT] I see little chance to have woof-CE's dimkr (a.k.a forum member Iguleder) remove the symlink. His last postdates from Dec 2015. Maybe someone else from the woof-CE team can do it?

[Argolance]

Bonjour,

Diversity is always good and my personal preferences don't matter much.

Without diversity, this world would be hell itself! Uniformity is the enemy of humans, that's why I don't like so much the world we are building. That's why, among other things much more fundamental, I like our little Puppy .
So, if I've made you want to add features your script, I'm really glad

Cordialement.

[MochiMoppel]

With rgb.txt being such an unreliable source for color names I wonder if we should continue to rely on it.

Getting the names of 752 color names from Xorg, the real source, is very fast and easy:

Code: Select all

busybox strings -n3 $(type -p Xorg) | grep -m1 -A751 alice

Extracting also the corresponding hex values from the binary Xorg file would be more complicated. Haven't done it yet.
What is easy though is an adaption of the gtkdialog script of the initial post. Meanwhile I figured out what causes the segmentation fault when trying to display all colors: The vbox that contains the colorbuttons can't handle 700+ widgets, so I have to split the widgets into 2 vboxes:

Code: Select all

busybox strings -n3 $(type -p Xorg) | grep -m1 -A751 alice |awk 'BEGIN {
print "<window title=\"Color Names as per Xorg\"><vbox><vbox  width=\"250\" height=\"400\" scrollable=\"true\"><vbox>"} 
++i==400 {print "</vbox><vbox>"}	#start 400th item in new vbox to avoid segmentation fault
{print "<hbox><colorbutton><variable>\""$0"\"</variable><default>"$0"</default></colorbutton><entry><input>echo \" "$0"\"</input></entry></hbox>"} 
END {print "</vbox></vbox><button></button></vbox></window>"}' | gtkdialog -s 

When pushing the OK button the output of gtkdialog can be used as the source for any further processing/conversion:

Code: Select all

AliceBlue="#f0f8ff"
AntiqueWhite="#faebd7"
AntiqueWhite1="#ffefdb"
AntiqueWhite2="#eedfcc"
AntiqueWhite3="#cdc0b0"
AntiqueWhite4="#8b8378"
alice blue="#f0f8ff"
antique white="#faebd7"
aquamarine="#7fffd4"
aquamarine1="#7fffd4"
aquamarine2="#76eec6"
aquamarine3="#66cdaa"
aquamarine4="#458b74"
azure="#f0ffff"
[...]

[EDIT] Code needs some refinement. Number of colors may vary. Bionicpup64 knows 782 colors, 30 more than its included rgb.txt file. Xorg may also be a mere wrapper script without color names, so the binary Xorg has to be found first.

[Argolance]

Bonjour,
Nice!

With rgb.txt being such an unreliable source for color names I wonder if we should continue to rely on it.

Yes, it's reasonable to wonder...

Cordialement.

[some1]

rgb.txt:
In the old days X relied on/kept the colorVALUE-colorNAME -listing in rgb.txt.
Later/nowadays the listing became hardcoded
in the source - and X no longer need the file.
The rgb.txt present in a distro will likely
just be a copy of the ancient rgb.txt-file.
Hardcoding the listing in the source came
with some extra pairs added to the list.

Try to extract the list from the binary in Tahr32(or another puppy with a not too old Xorg)..
My hunch is that there will be 782 items -like in Bionic -and 30 more pairs than in rgb.txt.
(awk may be an alternative to strings|grep|...)

[MochiMoppel]

Yes, rgb.txt is less essential than it used to be and AFAIK some distros have ditched it altogether, but as long as Puppy keeps a copy and as long as some applications use it, it should be accurate, shouldn't it? Keeping an outdated copy that was created 20 years ago (acc, to its header) in modern Puppies like bionicpub just makes no sense to me. But apart from the content there is another issue that needs fixing:

Location of rgb.txt

Puppy default
the usual path to the file in Puppies is /usr/share/X11/rgb.txt, a location where no application I know would expect it.

netpbm utilities
The netpbm utilities expect rgb.txt to be in any of these locations:
/usr/lib/X11/rgb.txt
/usr/openwin/lib/rgb.txt
/usr/X11R6/lib/X11/rgb.txt

For reasons I don't know the devs didn't solve this issue by putting a symlink to /usr/share/X11/rgb.txt into one of these locations. Instead they tried to fix it with an entry in /etc/profile:

Code: Select all

#w468 netpbm utilities need to be told where rgb.txt is...
[ -f /usr/share/X11/rgb.txt ] && export RGBDEF=/usr/share/X11/rgb.txt

yad
For yad the default path is
/etc/X11/rgb.txt
With a symlink in this location the command

Code: Select all

yad --color --palette

would create a yad dialog with rgb.txt as its palette.

gcolor2
Like yad gcolor2 shows rgb.txt by default, but searches in additional locations:
/usr/X11R6/lib/X11/rgb.txt
/usr/lib/X11/rgb.txt
/etc/X11/rgb.txt
/usr/openwin/lib/X11/rgb.txt
Unlike yad gcolor2 does not allow user defined alternative paths, hence woof-CE's strange decision to allow the misuse of /root/.rgb.txt for this purpose. A simple symlink in one of the paths known to gcolor2 would enable gcolor2 to function as intended.

Bottomline
A few symlinks would rectify all issues associated with the current location

[rockedge]

Hello MochiMoppel!

As usual supplied us with some really good information. I am adjusting my systems to incorporate the new symlinks

Thank you. Stay well.

[misko_2083]

Yad list can be used to display color. Either with@fore@ or @back@ column or with this trick with the pango markup:

Code: Select all

printf '<span background="%s">\t\t</span>\n' "$col"  | yad --list --column=color 

https://developer.gnome.org/pygtk/stabl ... color.html
nut the color doesn't have to be taken from rgb.txt file it can be in rgb form.
https://developer.gnome.org/pygtk/stabl ... color.html
e.g.

Code: Select all

printf '<span background="%s">\t\t</span>\n' "#000"  | yad --list --column=color

In combination with the color dialog in a paned dialog.
But only the eyedropper tool can be used to select the color from a list in the second pane.

Code: Select all

#!/bin/bash

COLORS="$(busybox strings -n3 $(type -p Xorg) | grep -m1 -A751 alice)"

yadkey="$((${RANDOM} * $$))"

yad --color --plug=${yadkey} --tabnum=1 --gtk-palette --expand-palette --palette=/usr/share/X11/rgb.txt &

OIFS=$IFS
IFS=$'\n'

for col in $COLORS
do
   printf '<span background="%s">\t\t</span>\n' "$col"
   echo "$col"
done |  yad --plug=${yadkey} --tabnum=2 --list --column=X11color --column=name --print-column=2  &

IFS=$OIFS

yad --paned --key="${yadkey}" \
    --title="Color" --width=500 --height=700

[MochiMoppel]

Yad list can be used to display color. Either with@fore@ or @back@ column or with this trick with the pango markup

Nice trick. I like the clean look of the yad list. Unfortunately the use of pango can lead to unexpected results. I tried to use --dclick-action

Code: Select all

--dclick-action='bash -c "gxmessage %s"'

With color names containing spaces yad crashes. Unspaced color names work fine. Doesn't seem to be a quotation issue.

[misko_2083]

Yad list can be used to display color. Either with@fore@ or @back@ column or with this trick with the pango markup

Nice trick. I like the clean look of the yad list. Unfortunately the use of pango can lead to unexpected results. I tried to use --dclick-action

Code: Select all

--dclick-action='bash -c "gxmessage %s"'

With color names containing spaces yad crashes. Unspaced color names work fine. Doesn't seem to be a quotation issue.

What happens when you replace regular spaces with one of those from Unicode?
\u2002 or \u2003 https://en.m.wikipedia.org/wiki/Whitespace_character
The idea is to replace the space in the color names with spaces and use them in the list.
If yad doesn't crash on dclick action, the color name can be switched back to the regular whitespace character in the exported function.
echo -e "Red\u2002Moon" | yad ...

[MochiMoppel]

What happens when you replace regular spaces with one of those from Unicode?

A barrage of yad warnings ("perhaps you used an invalid character in an attribute name") and with such invalid color names not surprisingly a failure to display colors. At least yad doesn't crash ...

[step]

Fatdog's yad doesn't crash with dclick action on 'alice blue'. However the shell prints a parse error:

blue> ' 'alice blue': -c: line 0: unexpected EOF while looking for matching `''
blue> ' 'alice blue': -c: line 1: syntax error: unexpected end of file

I think going through the shell isn't necessary. With --dclick-action=gxmessage and nothing else it works for 'alice blue' and AliceBlue alike.

[misko_2083]

Definitely a quoting issue.
%s returns the entire row with all the pango markup
<span background='slate gray'> </span> slate gray

What works for me is --dclick-action='bash -c "gxmessage \"%s\""'
also single quotes around background markup
printf "<span background='%s'>\t\t</span>\n" "slate gray"

Code: Select all

function ehoyad () { yad --width=600 --title="$@"; }
export -f ehoyad

printf "<span background='%s'>\t\t</span>\n%s\n" "slate gray" "slate gray" | yad --list --column=color --column=name --dclick-action='bash -c "ehoyad \"%s\""'