XMOBJECTATPOINT(3)
β¨ XmObjectAtPoint β¨
okay bestie, gather round, because today we're talking about XmObjectAtPoint β a lil library call from the Xm toolkit that figures out which child intersects or comes closest to a specified point. yes she's a detective. yes she ate. π
πΈ SYNOPSIS πΈ
#include <Xm/Xm.h>
Widget XmObjectAtPoint(
Widget widget,
Position x,
Position y);
π¦ DESCRIPTION π¦
so XmObjectAtPoint goes snooping through the child list of the manager widget you hand it, and returns the child that's most closely associated with the x,y coordinate pair you gave it. literally her whole job. iconic behavior honestly. β¨
for the typical Motif manager widget, XmObjectAtPoint uses these rules to decide which object comes back:
- if one child intersects
x,y,XmObjectAtPointreturns the widget ID of that child. slay, no competition. π - if more than one child intersects
x,y,XmObjectAtPointreturns the widget ID of the visible child. main character energy only. π - if no child intersects
x,y,XmObjectAtPointreturnsNULL. bestie is empty-handed, it's giving nothing. π
β οΈ okay so important: those rules are only general. in fact, each manager widget is free to define "most closely associated" as it desires. for example, if no child intersectsx,y, a manager might return the child closest tox,y. so don't come for me if your manager has its own opinions, k? each one gets to pick its own vibe. π§
now the parameters, bestie, one by one, no skipping:
widgetβ specifies a manager widget. (the one we're snooping inside, obvs π΅οΈβοΈ)xβ specifies the x-coordinate about which you are seeking child information. the x-coordinate must be specified in pixels, relative to the left side of manager. pixels, babe, not vibes. πyβ specifies the y-coordinate about which you are seeking child information. the y-coordinate must be specified in pixels, relative to the top side of manager. same deal, top not bottom. π«Ά
π RETURN π
returns the child of manager most closely associated with x,y. π₯° and if none of its children are sufficiently associated with x,y, returns NULL. it's giving "no thoughts, head empty" and that's valid. π
π RELATED π
XmManager(3). go read her next, iykyk. β
and that's the whole page, bestie!! this lil write-up is XmObjectAtPoint(library call) β yes, same name as the title, she's consistent like that β straight out of the library call section of the manual. mwah. πππ¦πΈβ¨
π sign-off from your favorite Unix girlie: XmObjectAtPoint(library call) β library call, periodt. go forth and find your children. π
π¦ where this page comes from
- alpine 3.24: motif-doc 2.5.2-r0 Β· LGPL-2.1-or-later
- arch rolling: openmotif 2.3.8-4 Β· LGPL-2.1-or-later
- centos-stream 9: motif-devel 2.3.4-32.el9 Β· LGPLv2+
- centos-stream 9: motif-devel 2.3.4-32.el9 Β· LGPLv2+
- epel 10: motif-devel 2.3.8-2.el10_2 Β· LicenseRef-Callaway-LGPLv2+
- fedora 43: motif-devel 2.3.8-1.fc43 Β· LicenseRef-Callaway-LGPLv2+
- fedora 43: motif-devel 2.3.8-1.fc43 Β· LicenseRef-Callaway-LGPLv2+
- fedora 43: motif-devel 2.3.8-2.fc43 Β· LicenseRef-Callaway-LGPLv2+
- fedora 43: motif-devel 2.3.8-2.fc43 Β· LicenseRef-Callaway-LGPLv2+
- fedora 44: motif-devel 2.3.8-3.fc44 Β· LicenseRef-Callaway-LGPLv2+
- fedora 44: motif-devel 2.3.8-3.fc44 Β· LicenseRef-Callaway-LGPLv2+
- nixos 26.05: motif 2.3.8
- nixpkgs unstable: motif 2.3.8
- opensuse-leap 16.0: motif-devel 2.3.8-bp160.1.1 Β· LGPL-2.1-or-later
- opensuse-leap 16.0: motif-devel 2.3.8-bp160.1.1 Β· LGPL-2.1-or-later
- opensuse-leap 16.0: motif-devel 2.3.8-bp160.1.1 Β· LGPL-2.1-or-later
- opensuse-leap 16.0: motif-devel 2.3.8-bp160.1.1 Β· LGPL-2.1-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms