TTDT_SENDER_IMPRINT_ON(3)

πŸ“¦
version 2.5.3 Β· 2 versions
, in nixos 26.05

πŸ’– NAME πŸ’–

okay so ttdt_sender_imprint_on β€” she's straight out of the library call manual β€” and her whole thing is to act like a child of the specified tool ✨. Like, your tool gets to be the baby of another tool, no cap. 🫢


🫢 SYNOPSIS 🫢

#include &<Tt/tttk.h>
Tt_status ttdt_sender_imprint_on(
const char *handler,
Tt_message contract,
char **display,
int *width,
int *height,
int *xoffset,
int *yoffset,
XtAppContext app2run,
int ms_timeout);

πŸ’… DESCRIPTION πŸ’…

ttdt_sender_imprint_on makes the calling tool act equivalently to a child of another specified tool. The calling tool adopts the other tool's X11 display, locale, and current working directory. It also learns the other tool's X11 geometry, so it can position itself appropriately. iconic behavior honestly πŸ’…

If handler is non-NULL, the requests get addressed to that procid using TT_HANDLER. If handler is NULL and contract is non-NULL, the requests get addressed to the tt_message_sender(3) of the contract, using TT_HANDLER.

The contract argument is passed to tttk_message_create(3) as the context argument.

If display is not NULL, ttdt_sender_imprint_on returns the other tool's display in *display. If display is NULL, ttdt_sender_imprint_on sets the DISPLAY environment variable to the other tool's display.

If each of the width, height, xoffset, and yoffset arguments are NULL, then ttdt_sender_imprint_on does not send the other tool a Get_Geometry request. lowkey respecting the no-geometry vibe πŸ™ˆ

ttdt_sender_imprint_on passes the app2run and ms_timeout arguments to tttk_block_while(3), blocking on the replies to the requests it sends.

If display is not NULL, ttdt_sender_imprint_on sets *display to a string that can be freed with tt_free.

If for some reason no width or height is returned by the other tool, ttdt_sender_imprint_on sets *width or *height to -1. If no positional information is returned, ttdt_sender_imprint_on sets *xoffset and *yoffset to {INT_MAX}. yes bestie, -1 and {INT_MAX} are the fallback era 😭

πŸ”₯ RETURN VALUE πŸ”₯

Upon successful completion, ttdt_sender_imprint_on returns the status of the operation as one of these Tt_status values:

  • TT_OK β€” The operation completed successfully. slay βœ…
  • TT_DESKTOP_ETIMEDOUT β€” One or more of the sent requests did not complete within ms_timeout milliseconds.
  • TT_ERR_NOMEM β€” There is insufficient memory available to perform the function.
  • TT_ERR_NOMP β€” The ttsession(1) process is not running and the ToolTalk service cannot restart it.
  • TT_ERR_OVERFLOW β€” The ToolTalk service has more active messages than it can handle. (The maximum number of active messages is implementation specific, but is at least 2000.)
  • TT_ERR_PROCID β€” The specified process identifier is out of date or invalid.

🌸 APPLICATION USAGE 🌸

If both handler and contract are zero, the requests are addressed to no tool in particular, using TT_PROCEDURE; this is not recommended. like pls don't, bestie πŸ™ˆ

πŸ¦‹ SEE ALSO πŸ¦‹


okay bye bestie, this was ttdt_sender_imprint_on from the library call manual β€” that's the source/version in the footer, and there's no date on this page, so consider this the cutest possible sign-off πŸ’‹βœ¨

πŸ“¦ where this page comes from