XAllocColor(3)

💖 XAllocColor(3) — the ✨ iconic ✨ Xlib color allocation/freeing gang

okay so bestie, listen up — this is the page for XAllocColor, XAllocNamedColor, XAllocColorCells, XAllocColorPlanes, and XFreeColors. no cap, they're literally the main characters when it comes to getting colors allocated and freed in Xlib. it's giving "let me grab a color real quick" but make it dramatic. 🎨💅

---

🌈 SYNTAX 🌈

Status XAllocColor(Display *display, Colormap colormap, XColor *screen_in_out);

Status XAllocNamedColor(Display *display, Colormap colormap, _Xconst char *color_name, XColor *screen_def_return, XColor *exact_def_return);

Status XAllocColorCells(Display *display, Colormap colormap, Bool contig, unsigned long plane_masks_return[], unsigned int nplanes, unsigned long pixels_return[], unsigned int npixels);

Status XAllocColorPlanes(Display *display, Colormap colormap, Bool contig, unsigned long pixels_return[], int ncolors, int nreds, int ngreens, int nblues, unsigned long *rmask_return, unsigned long *gmask_return, unsigned long *bmask_return);

int XFreeColors(Display *display, Colormap colormap, unsigned long pixels[], int npixels, unsigned long planes);

• color_name — the color name string you're hunting for (like red) that you want the color definition structure for. say it with me: red 🍓
• colormap — the colormap. the vibes. the palette.
• contig — a Boolean value that says whether the planes gotta be contiguous. like, do they need to be besties and sit together? 👯‍♀️
• display — the connection to the X server, obviously 💁‍♀️
• exact_def_return — returns the exact RGB values. no approximations here, we're being precise. 💯
• ncolors — number of pixel values that are gonna be returned in the pixels_return array.
• npixels — number of pixels. yes, npixels. yes, it's different from ncolors. keep up bestie 📝
• nplanes — number of plane masks that are gonna be returned in the plane masks array.
• nreds, ngreens, nblues — number of red, green, and blue planes. the value you pass must be nonnegative. no negative numbers, iykyk 🚫
• pixels — an array of pixel values.
• pixels_return — returns an array of pixel values.
• plane_mask_return — returns an array of plane masks.
• planes — the planes you wanna free. say bye-bye ✌️
• rmask_return, gmask_return, bmask_return — return bit masks for the red, green, and blue planes. the RGB trifecta 💅
• screen_def_return — returns the closest RGB values the hardware can actually provide. it's giving "we tried our best" energy.
• screen_in_out — specifies and returns the values actually used in the colormap. it's a two-way street 🔁

---

🌸 DESCRIPTION 🌸

🎀 XAllocColor 🎀

XAllocColor allocates a read-only colormap entry that corresponds to the closest RGB value supported by the hardware. it literally returns the pixel value of the color closest to the specified RGB elements that the hardware can actually handle, and it returns the RGB value that was actually used. the corresponding colormap cell is read-only. periodt.

XAllocColor returns nonzero if it succeeded or zero if it failed. bestie, it's a success/fail vibe. multiple clients that request the same effective RGB value can be assigned the same read-only entry, so entries can be shared — it's giving communal energy, we love to see it. when the last client deallocates a shared cell, it's deallocated. ✨

XAllocColor does not use or affect the flags in the XColor structure. leave those flags alone, they're not part of this conversation.

⚠️ XAllocColor can generate a BadColor error. watch out for that.

🦋 XAllocNamedColor 🦋

XAllocNamedColor looks up the named color with respect to the screen that's associated with the specified colormap. it returns both the exact database definition and the closest color supported by the screen. the allocated color cell is read-only. the pixel value is returned in screen_def_return.

if the color name is not in the Host Portable Character Encoding, the result is implementation-dependent — so like, don't come for me if it does something weird, it's not on me. 🙈 use of uppercase or lowercase does not matter, so RED, Red, and red are all the same vibe. slay.

if screen_def_return and exact_def_return point to the same structure, the pixel field will be set correctly, but the color values are undefined. so like… don't do that unless you know what you're doing, okay bestie? 😭

XAllocNamedColor returns nonzero if a cell is allocated; otherwise, it returns zero.

⚠️ XAllocNamedColor can generate a BadColor error. same boat different function.

💜 XAllocColorCells 💜

XAllocColorCells allocates read/write color cells. ooooh, we're writing now, we're not just reading. number of colors must be positive and the number of planes nonnegative, or a BadValue error results. no exceptions.

if ncolors and nplanes are requested, then ncolors pixels and nplane plane masks are returned. (yes it says nplane in the original, we're keeping it.) no mask will have any bits set to 1 in common with any other mask or with any of the pixels — they're all independent, they don't share bits, it's giving healthy boundaries ✋

by ORing together each pixel with zero or more masks, ncolors * 2nplanes distinct pixels can be produced. all of these are allocated writable by the request. for GrayScale or PseudoColor, each mask has exactly one bit set to 1. for DirectColor, each has exactly three bits set to 1.

if contig is True and if all masks are ORed together, a single contiguous set of bits set to 1 will be formed for GrayScale or PseudoColor, and three contiguous sets of bits set to 1 (one within each pixel subfield) for DirectColor. the RGB values of the allocated entries are undefined. don't ask, they're just not defined, okay? 🙃

XAllocColorCells returns nonzero if it succeeded or zero if it failed.

⚠️ XAllocColorCells can generate BadColor and BadValue errors.

👑 XAllocColorPlanes 👑

the specified ncolors must be positive; and nreds, ngreens, and nblues must be nonnegative, or a BadValue error results.

if ncolors colors, nreds reds, ngreens greens, and nblues blues are requested, ncolors pixels are returned; and the masks have nreds, ngreens, and nblues bits set to 1, respectively. if contig is True, each mask will have a contiguous set of bits set to 1. no mask will have any bits set to 1 in common with any other mask or with any of the pixels.

for DirectColor, each mask will lie within the corresponding pixel subfield. by ORing together subsets of masks with each pixel value, ncolors * 2(nreds+ngreens+nblues) distinct pixel values can be produced. all of these are allocated by the request.

however — and this is the important part bestie — in the colormap, there are only ncolors * 2nreds independent red entries, ncolors * 2ngreens independent green entries, and ncolors * 2nblues independent blue entries. this is true even for PseudoColor. the way that math works is literally giving "don't question it" vibes.

when the colormap entry of a pixel value is changed (using XStoreColors, XStoreColor, or XStoreNamedColor), the pixel is decomposed according to the masks, and the corresponding independent entries are updated.

XAllocColorPlanes returns nonzero if it succeeded or zero if it failed.

⚠️ XAllocColorPlanes can generate BadColor and BadValue errors.

🫶 XFreeColors 🫶

XFreeColors frees the cells represented by pixels whose values are in the pixels array. the planes argument should not have any bits set to 1 in common with any of the pixels. the set of all pixels is produced by ORing together subsets of the planes argument with the pixels.

the request frees all of these pixels that were allocated by the client (using XAllocColor, XAllocNamedColor, XAllocColorCells, and XAllocColorPlanes).

⚠️ note that freeing an individual pixel obtained from XAllocColorPlanes may not actually allow it to be reused until all of its related pixels are also freed. similarly, a read-only entry is not actually freed until it's been freed by all clients, and if a client allocates the same read-only entry multiple times, it must free the entry that many times before the entry is actually freed. it's giving "breakups are complicated" energy. 😭

all specified pixels that are allocated by the client in the colormap are freed, even if one or more pixels produce an error. so like, we're freeing stuff regardless, it's gonna happen. if a specified pixel is not a valid index into the colormap, a BadValue error results. if a specified pixel is not allocated by the client (that is, is unallocated or is only allocated by another client) or if the colormap was created with all entries writable (by passing AllocAll to XCreateColormap), a BadAccess error results. if more than one pixel is in error, the one that gets reported is arbitrary — it's giving "pick me" energy, we don't know which one it'll be. 🙃

XFreeColors can generate BadAccess, BadColor, and BadValue errors.

---

💀 DIAGNOSTICS 💀

• BadAccess — a client attempted to free a color map entry that it did not already allocate. excuse me? you didn't allocate that, why are you freeing it? 🚫
• BadAccess — a client attempted to store into a read-only color map entry. read-only means read-only, bestie. don't try it. 📖
• BadColor — a value for a Colormap argument does not name a defined Colormap. that colormap doesn't exist, it's not real, it's giving "imaginary friend" energy. 💀
• BadValue — some numeric value falls outside the range of values accepted by the request. unless a specific range is specified for an argument, the full range defined by the argument's type is accepted. any argument defined as a set of alternatives can generate this error. so like, check your numbers before you come here with that. 🔢

---

🎀 SEE ALSO 🎀

XCreateColormap(3), XQueryColor(3), XStoreColors(3) — literally the besties of this page, go check them out 💖

Xlib - C Language X Interface — the holy grail, the sacred text, the whole vibe.

---

and that's the tea, bestie. this page is brought to you by X Version 11 and the absolutely legendary libX11 1.8.14, dated the day this manual got its glow-up. u know the vibes. 💅✨🦋