Tk_ManageGeometry(3tk)

✨ Tk_ManageGeometry ✨

okay bestie so this is the Tk Library Procedures page for Tk_ManageGeometry 💖 and it's literally the function that lets you hand a window over to a geometry manager so somebody else handles all the "where do i go, how big am i" drama. sit down, grab a boba, we're doing this 🧋

---

🌸 NAME 🌸

Tk_ManageGeometry — arrange to handle geometry requests for a window 💅

---

✨ SYNOPSIS ✨

#include <tk.h>

Tk_ManageGeometry(tkwin, mgrPtr, clientData)

---

🎀 ARGUMENTS 🎀

• Tk_Window tkwin (in) — the token for the window you wanna manage, bestie 🪟
• const Tk_GeomMgr *mgrPtr (in) — pointer to a data structure holding the tea about the geometry manager, or NULL if you're saying "okay no more managing this window's geometry, we're done 💀". Important: the structure mgrPtr points to must be static — Tk keeps a reference to it for as long as the window stays managed. no stack shenanigans, i'm so serious 🙈
• void *clientData (in) — some arbitrary one-word value that gets passed along to the geometry manager callbacks. put whatever you want in there, it's your little secret 🍓

---

💖 DESCRIPTION 💖

Tk_ManageGeometry arranges for one specific geometry manager — described by mgrPtr — to control the geometry of a specific content window, tkwin. the way that it just… hands over the keys 🔑

if tkwin was already being managed by some other geometry manager, the old one loses control in favor of the new one. sorry not sorry, it's giving replacement era 💅. and if mgrPtr is NULL, geometry management for tkwin is cancelled. no manager, no problem.

the structure that mgrPtr points to is holding all the info about the geometry manager:

typedef struct {
    const char *name;
    Tk_GeomRequestProc *requestProc;
    Tk_GeomLostContentProc *lostContentProc;
} Tk_GeomMgr;

the name field is the textual name of the geometry manager, like pack or place. this is the value that the command winfo manager will hand back to you. it's literally the manager's whole identity, iconic ✨

requestProc is a procedure inside the geometry manager that gets invoked whenever Tk_GeometryRequest is called by the content window to change its desired geometry. basically: the window goes "hey i want to be this big now" and requestProc gets the notification 🔔. requestProc needs arguments and results matching the type Tk_GeomRequestProc:

typedef void Tk_GeomRequestProc(
        void *clientData,
        Tk_Window tkwin);

the parameters handed to requestProc will be identical to the corresponding parameters passed to Tk_ManageGeometry. and clientData usually points to a data structure holding application-specific info about how to manage tkwin's geometry. so like, your little info bag, but for geometry 👜

the lostContentProc field of mgrPtr points to another procedure in the geometry manager. Tk will invoke lostContentProc if some other manager calls Tk_ManageGeometry and claims tkwin away from the current geometry manager. it's the "they took my window 😭" callback.

but wait — lostContentProc is not invoked if Tk_ManageGeometry is called with a NULL value for mgrPtr (presumably the current geometry manager made that call itself, so it already knows the window isn't managed anymore). it's also not called if mgrPtr is the same as the window's current geometry manager. no duplicate notifications in this house 🚫

lostContentProc should have arguments and results matching this prototype:

typedef void Tk_GeomLostContentProc(
        void *clientData,
        Tk_Window tkwin);

the parameters to lostContentProc will be identical to the corresponding parameters passed to Tk_ManageGeometry. consistency is the vibe 🦋

---

👑 KEYWORDS 👑

callback, geometry, managed, request, unmanaged

---

that's the whole page bestie, go forth and manage some geometry, you got this fr fr 🫶🌈⭐

and a lil sign-off: this page is from Tk, version 4.0, and it's the Tk_ManageGeometry(3tk) manual page — stay managed, stay iconic 👑💜