XMDIRECTION(3)
π XmDirection π
okay bestie so this is a library call page, meaning it's documentation for the <Xm/Xm.h> crowd β the Motif girlies. and today's main character is XmDirection, the data type for the direction of widget components. yes she's a type, not a function, and she's carrying the whole layout of your app on her back. no biggie. π
β¨ SYNOPSIS β¨
#include <Xm/Xm.h>
that's it. that's the whole synopsis. she's low maintenance like that. π
πΈ DESCRIPTION πΈ
XmDirection is the data type that says which direction the system displays subwidgets, children of widgets, or literally any other visual components that are getting laid out. and not just for looks, okay β this type also affects traversal order within tab groups. so like, the order you tab through stuff? yeah, she decides that. main character energy fr. π
here's the tea: XmDirection is implemented as an unsigned char bit mask. so the horizontal and vertical directions can be specified independent of each other β pick and choose, we love options. β¨
she ALSO specifies the precedence of the horizontal and vertical directions relative to each other. for example, a value of XmRIGHT_TO_LEFT_TOP_TO_BOTTOM lays out a component horizontally from right to left first, then vertically top to bottom. see how the name literally tells you the order? it's giving organized. it's giving i-have-my-life-together.
π§ the single bit masks
XmDirection provides the following masks, each of which corresponds to a particular bit in XmDirection:
XmRIGHT_TO_LEFT_MASKXmLEFT_TO_RIGHT_MASKXmTOP_TO_BOTTOM_MASKXmBOTTOM_TO_TOP_MASKXmPRECEDENCE_HORIZ_MASKXmPRECEDENCE_VERT_MASK
π the multiple bit masks
in addition to the preceding single bit masks, XmDirection also provides the following multiple bit masks. these ones are particularly useful as arguments to XmDirectionMatchPartial β like, that's their whole moment, that's their calling:
XmHORIZONTAL_MASKXmPRECEDENCE_MASKXmVERTICAL_MASK
π the enumerated constants
Motif also provides the following enumerated constants for specifying various combinations of directions. let's go through them one by one, no skipping, we don't do that here:
XmRIGHT_TO_LEFT_TOP_TO_BOTTOMβ specifies that the components are laid out from right to left first, then top to bottom.XmLEFT_TO_RIGHT_TOP_TO_BOTTOMβ specifies that the components are laid out from left to right first, then top to bottom.XmRIGHT_TO_LEFT_BOTTOM_TO_TOPβ specifies that the components are laid out from right to left first, then bottom to top.XmLEFT_TO_RIGHT_BOTTOM_TO_TOPβ specifies that the components are laid out from left to right first, then bottom to top.XmTOP_TO_BOTTOM_RIGHT_TO_LEFTβ specifies that the components are laid out from top to bottom first, then right to left.XmTOP_TO_BOTTOM_LEFT_TO_RIGHTβ specifies that the components are laid out from top to bottom first, then left to right.XmBOTTOM_TO_TOP_RIGHT_TO_LEFTβ specifies that the components are laid out from bottom to top first, then right to left.XmBOTTOM_TO_TOP_LEFT_TO_RIGHTβ specifies that the components are laid out from bottom to top first, then left to right.XmTOP_TO_BOTTOMβ specifies that the components are laid out from top to bottom. β οΈ if horizontal direction is important, do not use this constant.XmBOTTOM_TO_TOPβ specifies that the components are laid out from bottom to top. β οΈ if horizontal direction is important, do not use this constant.XmDEFAULT_DIRECTIONβ specifies that the components are laid out according to the default direction. (this constant is primarily for widget writers, so if that's not you, it's not really your moment. π«Ά)XmLEFT_TO_RIGHTβ specifies that the components are laid out from left to right. β οΈ if vertical direction is important, do not use this constant.XmRIGHT_TO_LEFTβ specifies that the components are laid out from right to left. β οΈ if vertical direction is important, do not use this constant.
okay real talk bestie: notice howXmTOP_TO_BOTTOM,XmBOTTOM_TO_TOP,XmLEFT_TO_RIGHTandXmRIGHT_TO_LEFTall come with a "do not use this constant if the other direction is important" warning? that's not a vibe, that's a fact, so respect it. if you care about both axes, pick one of the full combination constants instead. π«
π RELATED π
she doesn't exist in a vacuum, she's got a whole friend group:
XmDirectionMatch(3)XmDirectionMatchPartial(3)XmDirectionToStringDirection(3)XmString(3)XmStringDirection(3)XmStringDirectionToDirection(3)
and that's the whole page, bestie!! π¦ you now officially understand XmDirection β the bit mask with range, the direction diva, the tab-group traversal queen. slay. periodt. π
β¨
signing off from the XmDirection library call page, <rainbow>XmDirection(library call)</rainbow>, same title energy top and bottom because symmetry is iconic. mwah. πππΈ
π¦ 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