xcb_change_window_attributes(3)

💖 xcb_change_window_attributes — bestie, we're changing window attributes 💖

okay so this is part of the XCB Requests crew (that's the manual section, iykyk) and it's literally the glow-up button for your windows. you tell the server which attributes you wanna change, you hand over the values, and boom — window makeover. let's get into it 🎀

---

✨ SYNOPSIS ✨

the include you need, no cap:

#include <xcb/xproto.h>

🫶 Request function

xcb_void_cookie_t xcb_change_window_attributes(xcb_connection_t *conn,
       xcb_window_t window, uint32_t value_mask, const
       void *value_list);

---

🌸 REQUEST ARGUMENTS 🌸

• conn — your XCB connection to X11. the whole line to the server, basically.
• window — the window you're changing. the main character in question 👑
• value_mask — a bitmask saying which attributes you're touching. it can be one of these iconic values:
  • XCB_CW_BACK_PIXMAP — overrides the default background-pixmap. lowkey important rule: the background pixmap and the window must have the same root and same depth. any size pixmap is allowed, though some sizes may be faster than others (not me saying that, the spec is 💅).
    • if XCB_BACK_PIXMAP_NONE is specified, the window has no defined background. the server may fill the contents with the previous screen contents, or with contents of its own choosing. chaotic of it, honestly.
    • if XCB_BACK_PIXMAP_PARENT_RELATIVE is specified, the parent's background is used, but the window must have the same depth as the parent (or a Match error results 😭). the parent's background is tracked, and the current version is used each time the window background is required.
  • XCB_CW_BACK_PIXEL — overrides BackPixmap. a pixmap of undefined size filled with the specified background pixel is used for the background. heads up: range-checking is not performed — the background pixel is truncated to the appropriate number of bits.
  • XCB_CW_BORDER_PIXMAP — overrides the default border-pixmap. the border pixmap and window must have the same root and the same depth. any size pixmap can be used, although some sizes may be faster than others.
    • the special value XCB_COPY_FROM_PARENT means the parent's border pixmap is copied (subsequent changes to the parent's border attribute do not affect the child), but the window must have the same depth as the parent.
  • XCB_CW_BORDER_PIXEL — overrides BorderPixmap. a pixmap of undefined size filled with the specified border pixel is used for the border. range checking is not performed on the border-pixel value, it's truncated to the appropriate number of bits.
  • XCB_CW_BIT_GRAVITY — defines which region of the window should be retained if the window is resized.
  • XCB_CW_WIN_GRAVITY — defines how the window should be repositioned if the parent is resized (see ConfigureWindow).
  • XCB_CW_BACKING_STORE — a backing-store of WhenMapped advises the server that maintaining contents of obscured regions when the window is mapped would be beneficial. a backing-store of Always advises the server that maintaining contents even when the window is unmapped would be beneficial — in this case, the server may generate an exposure event when the window is created. a value of NotUseful advises the server that maintaining contents is unnecessary, although a server may still choose to maintain contents while the window is mapped. note that if the server maintains contents, then the server should maintain complete contents, not just the region within the parent boundaries, even if the window is larger than its parent. while the server maintains contents, exposure events will not normally be generated, but the server may stop maintaining contents at any time. (the server is a flaky bestie, we accept this.)
  • XCB_CW_BACKING_PLANES — the backing-planes indicates (with bits set to 1) which bit planes of the window hold dynamic data that must be preserved in backing-stores and during save-unders.
  • XCB_CW_BACKING_PIXEL — the backing-pixel specifies what value to use in planes not covered by backing-planes. the server is free to save only the specified bit planes in the backing-store or save-under, and regenerate the remaining planes with the specified pixel value. any bits beyond the specified depth of the window in these values are simply ignored.
  • XCB_CW_OVERRIDE_REDIRECT — the override-redirect specifies whether map and configure requests on this window should override a SubstructureRedirect on the parent — typically to inform a window manager not to tamper with the window. (we're being sneaky, periodt.)
  • XCB_CW_SAVE_UNDER — if 1, the server is advised that when this window is mapped, saving the contents of windows it obscures would be beneficial.
  • XCB_CW_EVENT_MASK — the event-mask defines which events the client is interested in for this window (or for some event types, inferiors of the window).
  • XCB_CW_DONT_PROPAGATE — the do-not-propagate-mask defines which events should not be propagated to ancestor windows when no client has the event type selected in this window.
  • XCB_CW_COLORMAP — the colormap specifies the colormap that best reflects the true colors of the window. servers capable of supporting multiple hardware colormaps may use this information, and window managers may use it for InstallColormap requests. the colormap must have the same visual type and root as the window (or a Match error results). if CopyFromParent is specified, the parent's colormap is copied (subsequent changes to the parent's colormap attribute do not affect the child). However, the window must have the same visual type as the parent (or a Match error results), and the parent must not have a colormap of None (or a Match error results). for an explanation of None, see FreeColormap request. the colormap is copied by sharing the colormap object between the child and the parent, not by making a complete copy of the colormap contents. sharing is caring 🫶
  • XCB_CW_CURSOR — if a cursor is specified, it will be used whenever the pointer is in the window. if None is specified, the parent's cursor will be used when the pointer is in the window, and any change in the parent's cursor will cause an immediate change in the displayed cursor.
• value_list — the values for each of the attributes specified in the bitmask value_mask. the order has to correspond to the order of possible value_mask bits. see the example. no skipping, bestie, order matters fr fr.

---

🦋 DESCRIPTION 🦋

Changes the attributes specified by value_mask for the specified window. that's it, that's the vibe.

---

💅 RETURN VALUE 💅

returns an xcb_void_cookie_t. errors (if any) have to be handled in the event loop.

if you want to handle errors directly with xcb_request_check instead, use xcb_change_window_attributes_checked. see xcb-requests(3) for details.

---

💀 ERRORS 💀

• xcb_access_error_t — TODO: reasons?
• xcb_colormap_error_t — TODO: reasons?
• xcb_cursor_error_t — TODO: reasons?
• xcb_match_error_t — TODO: reasons?
• xcb_pixmap_error_t — TODO: reasons?
• xcb_value_error_t — TODO: reasons?
• xcb_window_error_t — The specified window does not exist. (it's giving ghosted 👻)

yes, several of those really do just say TODO: reasons? in the original. iconic documentation behavior, we don't gatekeep, we report faithfully. 😭

---

🌈 SEE ALSO 🌈

• xcb-requests(3)

---

👑 AUTHOR 👑

Generated from xproto.xml. Contact xcb@lists.freedesktop.org for corrections and improvements.

---

and that's the whole page, bestie ✨ this one shipped as part of X Version 11, libxcb 1.17.0 — so go forth, change those window attributes, and remember: the value_list order is sacred 💖🎀🦋