Tk_MaintainGeometry(3tk)
π 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 thatwindow'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 ofwindowinsidecontainer, in pixels, measured from the inside ofcontainer's left border to the outside ofwindow'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 ofwindowincontainer, in pixels, from the inside ofcontainer's top border to the outside ofwindow's top border.int width(in) β the desired width forwindow, in pixels. πint height(in) β the desired height forwindow, 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:
- The
x- andy-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. π - 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.
- 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, andheight.
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_MaintainGeometryis 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_UnmaintainGeometryis 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
- debian trixie: tk9.0-doc 9.0.1-3
- ubuntu questing: tk9.0-doc 9.0.2-1
- ubuntu resolute: tk9.0-doc 9.0.3-1
- ubuntu stonking: tk9.0-doc 9.0.4-1
- Copyright (c) 1994 The Regents of the University of California
- Copyright (c) 1994-1996 Sun Microsystems, Inc
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms