Tk_MaintainGeometry(3tk)

πŸ“¦
version 9.0.4 Β· 2 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– Tk_MaintainGeometry β€” bestie edition πŸ’–

okay so this is a page from the Tk Library Procedures manual, and it's about the two little functions that keep one window's geometry glued to another window. Tk_MaintainGeometry and Tk_UnmaintainGeometry, they're a duo. πŸ‘―β€β™€οΈ no cap.


✨ NAME ✨

Tk_MaintainGeometry, Tk_UnmaintainGeometry β€” keep the geometry of one window relative to another one. it's giving "i will hold your hand and never let go" energy fr fr 🫢


🌸 SYNOPSIS 🌸

#include <tk.h>

Tk_MaintainGeometry(window, container, x, y, width, height)

Tk_UnmaintainGeometry(window, container)

πŸŽ€ ARGUMENTS πŸŽ€

  • Tk_Window window (in) β€” the window whose geometry is getting controlled. the main character, basically. πŸ‘‘
  • Tk_Window container (in) β€” the window that window's geometry is measured relative to. the reference point, the anchor, the "i'm not like other windows".
  • int x (in) β€” the desired x-coordinate of window inside container, in pixels, measured from the inside of container's left border to the outside of window's left border. yes, inside-to-outside, that's the whole vibe, don't ask me why, that's just how it is. πŸ’…
  • int y (in) β€” same deal but vertical: the desired y-coordinate of window in container, in pixels, from the inside of container's top border to the outside of window's top border.
  • int width (in) β€” the desired width for window, in pixels. πŸ“
  • int height (in) β€” the desired height for window, in pixels. πŸ“

πŸ¦‹ DESCRIPTION πŸ¦‹

so Tk_MaintainGeometry and Tk_UnmaintainGeometry exist to make life easier for geometry managers dealing with windows whose containers are not their parents. and bestie, that situation is a whole mess. three problems show up the moment the container isn't the parent:

  1. The x- and y-position of the window has to be translated from the container's coordinate system into the parent's coordinate system before you can even position the window. like, translating between two languages, mid-conversation. 😭
  2. If the container window β€” or any of its ancestors up to the window's parent β€” gets moved, then the window has to be repositioned inside its parent so it keeps the correct position relative to the container. moving furniture and the picture frames have to follow.
  3. If the container or one of its ancestors gets mapped or unmapped, the window has to be mapped or unmapped to match. matching outfits, essentially. ✨

none of these problems exist when the parent and the container are the same window. like, for example, if the container or one of its ancestors gets unmapped, X automatically removes the window from the screen. free of charge. iconic.

Tk_MaintainGeometry handles all three of those problems for windows whose containers are not their parents β€” and it also handles the simpler case where the container is the parent. typically, a window manager calls Tk_MaintainGeometry once it's decided where a window should sit relative to its container. Tk_MaintainGeometry translates the coordinates into window's parent's coordinate system, then moves and resizes the window accordingly. and then β€” the part that's actually the serve β€” it remembers the desired position and creates event handlers to watch the container and all of its ancestors up to, but not including, the window's parent. πŸ‘€

so if any of those windows gets moved, mapped, or unmapped, the window gets adjusted so that:

  • it's mapped only when the container is mapped, and
  • its geometry relative to the container stays exactly as specified by x, y, width, and height.

when a window manager relinquishes control over a window β€” or decides it doesn't want the window on screen under any conditions β€” it calls Tk_UnmaintainGeometry. that function unmaps the window and cancels any previous calls to Tk_MaintainGeometry for that container-window pair, so the window's geometry and mapped state stop being maintained automatically. we're breaking up, respectfully. πŸ’”

heads up: a geometry manager does not need to call Tk_UnmaintainGeometry if the window, the container, or any of the container's ancestors gets destroyed β€” Tk will call it automatically. the cleanup is handled, bestie, you can rest. 😌

two more things, and these matter:

  • If Tk_MaintainGeometry is called repeatedly for the same container-window pair, the info from the most recent call supersedes any older info. newest call wins, always. periodt.
  • If Tk_UnmaintainGeometry is called for a container-window pair that is not currently managed, the call has no effect. nothing happens. no drama. πŸ™ˆ

πŸ”₯ KEYWORDS πŸ”₯

geometry manager, map, container, parent, position, window, unmap


okay that's the whole page, you ate it, you understood it, i'm so proud. πŸ₯ΉπŸ’œ

this was Tk Library Procedures, version 4.0, from the Tk source β€” so go forth and maintain some geometry, bestie. slay responsibly βœ¨πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from