ScreenFinding
"$number = root_to_screen ($X, $root)"
"$hashref = root_to_screen_info ($X, $root)"
Return the screen number or screen info hash for a given root window. $root can be any XID integer
on $X. If it's not one of the root windows then the return is "undef".
"$number = default_colormap_to_screen ($X, $colormap)"
"$hashref = default_colormap_to_screen_info ($X, $colormap)"
Return the screen number or screen info hash for a given default colormap. $colormap can be any XID
integer on $X. If it's not one of the screen default colormaps then the return is "undef".
Visuals
"$bool = visual_is_dynamic ($X, $visual_id)"
"$bool = visual_class_is_dynamic ($X, $visual_class)"
Return true if the given visual is dynamic, meaning colormap entries on it can be changed to change
the colour of a given pixel value.
$visual_id is one of the visual ID numbers, ie. one of the keys in "$X->{'visuals'}". Or
$visual_class is a VisualClass string like "PseudoColor" or corresponding integer such as 3.
WindowInfo
"($width, $height) = window_size ($X, $window)"
"$visual_id = window_visual ($X, $window)"
Return the size or visual ID of a given window.
$window is an integer XID on $X. If it's one of the root windows then the return values are from the
screen info hash in $X, otherwise the server is queried with "GetGeometry()" (for the size) or
"GetWindowAttributes()" (for the visual).
These functions are handy when there's a good chance $window might be a root window and therefore not
need a server round trip.
"@atoms = get_property_atoms($X, $window, $property)"
Get from $window (integer XID) a list-of-atoms property $property (atom integer). The return is a
list of atom integers, possibly an empty list. If $property doesn't exist or is not atoms then
return an empty list.
"set_property_atoms($X, $window, $property, @atoms)"
Set on $window (integer XID) a list-of-atoms property $property (atom integer) as the given list of
@atoms (possibly empty).
ColourParsing
"($red16, $green16, $blue16) = hexstr_to_rgb($str)"
Parse a given RGB colour string like "#FF00FF" into 16-bit red, green, blue components. The return
values are always in the range 0 to 65535. The strings recognised are 1, 2, 3 or 4 digit hex.
#RGB
#RRGGBB
#RRRGGGBBB
#RRRRGGGGBBBB
If $str is unrecognised then the return is an empty list, so for instance
my @rgb = hexstr_to_rgb($str)
or die "Unrecognised colour: $str";
The digits of the 1, 2 and 3 forms are replicated as necessary to give a 16-bit range. For example
3-digit style "#321FFF000" gives return values 0x3213, 0xFFFF, 0. Or 1-digit "#F0F" is 0xFFFF, 0,
0xFFFF. Notice "F" expands to 0xFFFF so an "F", "FF" or "FFF" all mean full saturation the same as a
4-digit "FFFF".
Would it be worth recognising the Xcms style "rgb:RR/GG/BB"? Perhaps that's best left to full Xcms,
or general colour conversion modules. The X11R6 X(7) man page describes the "rgb:" form, but just
"#" is much more common.