XMPRIMITIVE(3)

πŸ“¦
version 2.3.8 Β· 3 versions
, in arch rolling, centos-stream 9, epel 10, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, opensuse-leap 16.0

πŸ’– XmPrimitive πŸ’–

okay so this is XmPrimitive(library call) from the Xm library, and bestie, it's literally the blueprint for a whole family of widgets. let's get into it πŸ¦‹


✨ NAME ✨

XmPrimitive β€” the Primitive widget class πŸ‘‘


🌸 SYNOPSIS 🌸

#include <Xm/Xm.h>

πŸŽ€ DESCRIPTION πŸŽ€

okay so listen. Primitive is a widget class, but it's not out here living its own life β€” it's a supporting superclass for other widget classes. it's giving backstage crew energy, and honestly? iconic for that. πŸ’…

what does it actually handle? so glad you asked:

  • border drawing and highlighting ✨
  • traversal activation and deactivation
  • and all the various callback lists that Primitive widgets need

and one more thing, no cap: Primitive and all its subclasses hold the XmQTcareParentVisual trait. it's a family trait, iykyk. 🧬


🌈 Data Transfer Behavior

okay so real talk: Primitive has no widget class conversion procedure and no destination procedure. none. zero. that's not its job, bestie. πŸ™ˆ

so who's handling it?

  • Subclasses and the XmNconvertCallback procedures are responsible for any conversion of selections.
  • Subclasses and the subclass XmNdestinationCallback procedures are responsible for any data transfers to the widget.

that's the whole vibe. it delegates. main character energy is knowing when to hand things off. πŸ’…


πŸ¦‹ Classes

Primitive inherits behavior, resources, and traits from Core. (yes, Core. the whole lineage thing is real. 🌳)

  • The class pointer is xmPrimitiveWidgetClass.
  • The class name is XmPrimitive.

⭐ New Resources

The following table defines a set of widget resources used by the programmer to specify data. The programmer can also set the resource values for the inherited classes to set attributes for this widget. To reference a resource by name or by class in a .Xdefaults file, remove the XmN or XmC prefix and use the remaining letters. To specify one of the defined values for a resource in a .Xdefaults file, remove the Xm prefix and use the remaining letters (in either lowercase or uppercase, but include any underscores between words).

okay and the access column codes? here's the key, bestie πŸ”‘:

  • C β€” can be set at creation time
  • S β€” can be set by using XtSetValues
  • G β€” can be retrieved by using XtGetValues
  • N/A β€” not applicable

now here's the XmPrimitive Resource Set in all its glory, presented as a list because we're terminal girlies and tables are lowkey not it 🌸:

  • XmNbottomShadowColor β€” Class: XmCBottomShadowColor Β· Type: Pixel Β· Default: dynamic Β· Access: CSG
  • XmNbottomShadowPixmap β€” Class: XmCBottomShadowPixmap Β· Type: Pixmap Β· Default: XmUNSPECIFIED_PIXMAP Β· Access: CSG
  • XmNconvertCallback β€” Class: XmCCallback Β· Type: XtCallbackList Β· Default: NULL Β· Access: C
  • XmNforeground β€” Class: XmCForeground Β· Type: Pixel Β· Default: dynamic Β· Access: CSG
  • XmNhelpCallback β€” Class: XmCCallback Β· Type: XtCallbackList Β· Default: NULL Β· Access: C
  • XmNhighlightColor β€” Class: XmCHighlightColor Β· Type: Pixel Β· Default: dynamic Β· Access: CSG
  • XmNhighlightOnEnter β€” Class: XmCHighlightOnEnter Β· Type: Boolean Β· Default: False Β· Access: CSG
  • XmNhighlightPixmap β€” Class: XmCHighlightPixmap Β· Type: Pixmap Β· Default: dynamic Β· Access: CSG
  • XmNhighlightThickness β€” Class: XmCHighlightThickness Β· Type: Dimension Β· Default: 2 Β· Access: CSG
  • XmNlayoutDirection β€” Class: XmCLayoutDirection Β· Type: XmDirection Β· Default: dynamic Β· Access: CG
  • XmNnavigationType β€” Class: XmCNavigationType Β· Type: XmNavigationType Β· Default: XmNONE Β· Access: CSG
  • XmNpopupHandlerCallback β€” Class: XmCCallback Β· Type: XtCallbackList Β· Default: NULL Β· Access: C
  • XmNshadowThickness β€” Class: XmCShadowThickness Β· Type: Dimension Β· Default: 2 Β· Access: CSG
  • XmNtoolTipString β€” Class: XmCToolTipString Β· Type: XmString Β· Default: NULL Β· Access: CSG
  • XmNtopShadowColor β€” Class: XmCTopShadowColor Β· Type: Pixel Β· Default: dynamic Β· Access: CSG
  • XmNtopShadowPixmap β€” Class: XmCTopShadowPixmap Β· Type: Pixmap Β· Default: dynamic Β· Access: CSG
  • XmNtraversalOn β€” Class: XmCTraversalOn Β· Type: Boolean Β· Default: True Β· Access: CSG
  • XmNunitType β€” Class: XmCUnitType Β· Type: unsigned char Β· Default: dynamic Β· Access: CSG
  • XmNuserData β€” Class: XmCUserData Β· Type: XtPointer Β· Default: NULL Β· Access: CSG

πŸ’œ XmNbottomShadowColor

Specifies the color to use to draw the bottom and right sides of the border shadow. This color is used if the XmNtopShadowPixmap resource is unspecified.

heads up bestie: that conditional is doing WORK. the color only kicks in when XmNtopShadowPixmap is unspecified. πŸ‘€

πŸ’œ XmNbottomShadowPixmap

Specifies the pixmap to use to draw the bottom and right sides of the border shadow.


okay that's part one, and we are so not done yet β€” more parts incoming, don't go anywhere πŸ’–βœ¨

  • XmNconvertCallback β€” a whole list of callbacks that fires when somebody asks your widget to convert a selection πŸ’…. The type of the structure whose address gets handed to these callbacks is XmConvertCallbackStruct, and the reason is XmCR_OK.
  • XmNforeground β€” the foreground drawing color that Primitive widgets use. That's the whole assignment, bestie. ✨
  • XmNhelpCallback β€” the list of callbacks that goes off when the help key is pressed. The reason the callback sends is XmCR_HELP. 🫢
  • XmNhighlightColor β€” the color of the highlighting rectangle. This color is used only if the highlight pixmap resource is XmUNSPECIFIED_PIXMAP.
  • XmNhighlightOnEnter β€” says whether the highlighting rectangle gets drawn when the cursor moves into the widget. Okay so it depends on the shell's focus policy, so stay with me:
    • if the shell's focus policy is XmEXPLICIT, this resource is ignored, and the widget is highlighted when it has the focus.
    • if the shell's focus policy is XmPOINTER and this resource is True, the highlighting rectangle is drawn when the cursor moves into the widget. πŸ’–
    • if the shell's focus policy is XmPOINTER and this resource is False, the highlighting rectangle is not drawn when the cursor moves into the widget.
    • the default is False.
  • XmNhighlightPixmap β€” the pixmap used to draw the highlighting rectangle. πŸŽ€
  • XmNhighlightThickness β€” how thick the highlighting rectangle is.
  • XmNlayoutDirection β€” the direction the components of the primitive (strings included, bestie) get laid out in. Values are of type XmDirection. If the widget's parent is a primitive or a shell, the value is inherited from the widget's parent. Otherwise it's inherited from the closest ancestor vendor or menu shell. Go read the XmDirection(3) reference page for the possible direction values. πŸ¦‹
  • XmNnavigationType β€” decides whether the widget is a tab group or not. The options are giving:
    • XmNONE β€” says the widget is not a tab group.
    • XmTAB_GROUP β€” says the widget is a tab group, unless the XmNnavigationType of another widget in the hierarchy is XmEXCLUSIVE_TAB_GROUP.
    • XmSTICKY_TAB_GROUP β€” says the widget is a tab group even if the XmNnavigationType of another widget in the hierarchy is XmEXCLUSIVE_TAB_GROUP. Sticky means sticky, periodt.
    • XmEXCLUSIVE_TAB_GROUP β€” says the widget is a tab group AND that widgets in the hierarchy whose XmNnavigationType is XmTAB_GROUP are not tab groups. Very main character of it.
      • When a parent widget has an XmNnavigationType of XmEXCLUSIVE_TAB_GROUP, traversal of non-tab-group widgets within the group is based on the order of those widgets in their parent's XmNchildren list.
      • When the XmNnavigationType of any widget in a hierarchy is XmEXCLUSIVE_TAB_GROUP, traversal of tab groups in the hierarchy proceeds to widgets in the order in which their XmNnavigationType resources were specified as XmEXCLUSIVE_TAB_GROUP or XmSTICKY_TAB_GROUP β€” whether that happened by creating the widgets with that value, by calling XtSetValues, or by calling XmAddTabGroup.
  • XmNpopupHandlerCallback β€” lets the application control which popup menu gets automatically posted. The reason can be either XmCR_POST or XmCR_REPOST:
    • XmCR_POST β€” says this is a regular posting request.
    • XmCR_REPOST β€” says the menu was just unposted and that this callback was invoked on a replay.

This callback uses the XmPopupHandlerCallbackStruct structure to pass information along. πŸ“¬

  • XmNshadowThickness β€” the size of the drawn border shadow.
  • XmNtoolTipString β€” the XmString to display as the toolTip. If this resource is NULL, no tip will be displayed. ToolTips are described in VendorShell(3). ✨
  • XmNtopShadowColor β€” the color used to draw the top and left sides of the border shadow. This color is used if the XmNtopShadowPixmap resource is unspecified. Heads up though: if a default top shadow pixmap exists, it needs to be removed for XmNtopShadowColor to actually take effect. πŸ™ˆ
  • XmNtopShadowPixmap β€” the pixmap used to draw the top and left sides of the border shadow. A Primitive top shadow pixmap gets created in two situations. In either of these situations, a default 50-foreground top shadow pixmap is created:
    • If the Primitive top shadow color is the same as the Core background pixel color.
    • If the depth of the screen is only one.

For example, if a widget with the same top shadow and background color is created, a default shadow pixmap is generated. Such a pixmap needs to be removed for the XmNtopShadowColor resource to take effect. πŸ’€

  • XmNtraversalOn β€” says whether traversal is activated for this widget. In CascadeButton and CascadeButtonGadget, this resource is forced to True unless the parent is an OptionMenu.
  • XmNunitType β€” provides the basic support for resolution independence. It defines the type of units a widget uses with sizing and positioning resources. If the widget's parent is a subclass of XmManager and the XmNunitType resource isn't explicitly set, it defaults to the unit type of the parent widget. If the widget's parent is not a subclass of XmManager, the resource has a default unit type of XmPIXELS.

The unit type can also be specified in resource files, with this format:

<floating value><unit>

where:

  • unit is <" ", pixels, inches, centimeters, millimeters, points, font units>
  • pixels is <pix, pixel, pixels>
  • inches is <in, inch, inches>
  • centimeter is <cm, centimeter, centimeters>
  • millimeters is <mm, millimeter, millimeters>
  • points is <pt, point, points>
  • font units is <fu, font_unit, font_units>
  • float is {"+"|"-"}{{<"0"-"9">*}.}<"0"-"9">*
    • Note that the type Dimension must always be positive.

For example,

xmfonts*XmMainWindow.height: 10.4cm
*PostIn.width: 3inches

XmNunitType can have the following values:

  • XmPIXELS β€” all values provided to the widget are treated as normal pixel values.
  • XmMILLIMETERS β€” all values provided to the widget are treated as normal millimeter values.
  • Xm100TH_MILLIMETERS β€” all values provided to the widget are treated as 1/100 of a millimeter.
  • XmCENTIMETERS β€” all values provided to the widget are treated as normal centimeter values.
  • XmINCHES β€” all values provided to the widget are treated as normal inch values.
  • Xm1000TH_INCHES β€” all values provided to the widget are treated as 1/1000 of an inch.
  • XmPOINTS β€” all values provided to the widget are treated as normal point values. A point is a unit used in text processing applications and is defined as 1/72 of an inch.
  • Xm100TH_POINTS β€” all values provided to the widget are treated as 1/100 of a point. A point is a unit used in text processing applications and is defined as 1/72 of an inch.
  • XmFONT_UNITS β€” all values provided to the widget are treated as normal font units. A font unit has horizontal and vertical components. These are the values of the XmScreen resources XmNhorizontalFontUnit and XmNverticalFontUnit.
  • Xm100TH_FONT_UNITS β€” all values provided to the widget are treated as 1/100 of a font unit. A font unit has horizontal and vertical components. These are the values of the XmScreen resources XmNhorizontalFontUnit and XmNverticalFontUnit.
  • XmNuserData β€” lets the application attach any specific data it needs to the widget. It's an internally unused resource, so it's just sitting there holding your stuff. 🫢

✨ Dynamic Color Defaults ✨

The foreground, background, top shadow, bottom shadow, and highlight color resources are dynamically defaulted. If no color data is specified, the colors are automatically generated. On a single-plane system, a black and white color scheme is generated. Otherwise, four colors are generated, and they display the correct shading for the 3-D visuals. If the background is the only color specified for a widget, the top shadow and bottom shadow colors are generated to give the 3-D appearance. Foreground and highlight colors are generated to provide sufficient contrast with the background color. 🌈

Important, bestie: colors are generated only at creation. Resetting the background through XtSetValues does not regenerate the other colors. XmChangeColor can be used to recalculate all associated colors based on a new background color. πŸ’…

🌸 Inherited Resources 🌸

Primitive inherits behavior and resources from the superclass described in the following table. For a complete description of each resource, refer to the reference page for that superclass. πŸ“š

πŸŽ€ Core Resource Set πŸŽ€

okay bestie, here's the whole resource glow-up menu for this widget. every single one of these is a thing you can set, get, or both β€” and the access column is literally telling you what you're allowed to do (set it, get it, whatever). i'm giving you all of them, no skips, no "etc." πŸ’…

  • XmNaccelerators β€” class XmCAccelerators, type XtAccelerators, default dynamic, access CSG
  • XmNancestorSensitive β€” class XmCSensitive, type Boolean, default dynamic, access G
  • XmNbackground β€” class XmCBackground, type Pixel, default dynamic, access CSG
  • XmNbackgroundPixmap β€” class XmCPixmap, type Pixmap, default XmUNSPECIFIED_PIXMAP, access CSG
  • XmNborderColor β€” class XmCBorderColor, type Pixel, default XtDefaultForeground, access CSG
  • XmNborderPixmap β€” class XmCPixmap, type Pixmap, default XmUNSPECIFIED_PIXMAP, access CSG
  • XmNborderWidth β€” class XmCBorderWidth, type Dimension, default 0, access CSG
  • XmNcolormap β€” class XmCColormap, type Colormap, default dynamic, access CG
  • XmNdepth β€” class XmCDepth, type int, default dynamic, access CG
  • XmNdestroyCallback β€” class XmCCallback, type XtCallbackList, default NULL, access C
  • XmNheight β€” class XmCHeight, type Dimension, default dynamic, access CSG
  • XmNinitialResourcesPersistent β€” class XmCInitialResourcesPersistent, type Boolean, default True, access C
  • XmNmappedWhenManaged β€” class XmCMappedWhenManaged, type Boolean, default True, access CSG
  • XmNscreen β€” class XmCScreen, type Screen *, default dynamic, access CG
  • XmNsensitive β€” class XmCSensitive, type Boolean, default True, access CSG
  • XmNtranslations β€” class XmCTranslations, type XtTranslations, default dynamic, access CSG
  • XmNwidth β€” class XmCWidth, type Dimension, default dynamic, access CSG
  • XmNx β€” class XmCPosition, type Position, default 0, access CSG
  • XmNy β€” class XmCPosition, type Position, default 0, access CSG

πŸ“ž Callback Information πŸ“ž

so when the widget hits you back, this is what shows up in your DMs. here's the tea on each callback struct, fr fr.

a pointer to this structure gets passed to every callback for XmNhelpCallback:

typedef struct
{
        int reason;
        XEvent * event;
} XmAnyCallbackStruct;
  • reason β€” spills why the callback even got invoked. for this callback, reason is set to XmCR_HELP.
  • event β€” points at the XEvent that triggered the callback.

and a pointer to this callback structure gets passed to the XmNconvertCallback procedures:

typedef struct
{
        int reason;
        XEvent *event;
        Atom selection;
        Atom target;
        XtPointer source_data;
        XtPointer location_data;
        int flags;
        XtPointer parm;
        int parm_format;
        unsigned long parm_length;
        Atom parm_type;
        int status;
        XtPointer value;
        Atom type;
        int format;
        unsigned long length;
} XmConvertCallbackStruct;
  • reason β€” tells you why the callback was invoked.
  • event β€” points at the XEvent that triggered the callback. heads up: it can be NULL.
  • selection β€” says which selection the conversion is being requested for. possible values are CLIPBOARD, PRIMARY, SECONDARY, and _MOTIF_DROP.

okay so the callback struct fields keep going like this, bestie:

  • target β€” says what the conversion target is. πŸ’…
  • source_data β€” has the tea on the selection source. When the selection is _MOTIF_DROP, source_data is the DragContext. Otherwise, it’s NULL. 🫢
  • location_data β€” has info about where the data to be converted lives. If the value is NULL, the data to be transferred is the widget’s current selection. Otherwise, the type and interpretation of the value are specific to the widget class. πŸ¦‹
  • flags β€” tells you the status of the conversion. Possible values are:
    • XmCONVERTING_NONE β€” this flag is currently unused. πŸ’€
    • XmCONVERTING_PARTIAL β€” the target widget was able to be converted, but some data was lost. 😭
    • XmCONVERTING_SAME β€” the conversion target is the source of the data to be transferred. πŸ”₯
    • XmCONVERTING_TRANSACT β€” this flag is currently unused. πŸ’€
  • parm β€” contains parameter data for this target. If no parameter data exists, the value is NULL. When selection is CLIPBOARD and target is _MOTIF_CLIPBOARD_TARGETS or _MOTIF_DEFERRED_CLIPBOARD_TARGETS, the value is the requested operation (XmCOPY, XmMOVE, or XmLINK). πŸ‘‘
  • parm_format β€” says whether the data in parm should be viewed as a list of char, short, or long quantities. Possible values are 0 (when parm is NULL), 8 (when the data in parm should be viewed as a list of chars), 16 (when the data in parm should be viewed as a list of shorts), or 32 (when the data in parm should be viewed as a list of longs). Note that parm_format symbolizes a data type, not the number of bits in each list element. For example, on some machines, a parm_format of 32 means that the data in parm should be viewed as a list of 64-bit quantities, not 32-bit quantities. 🀯
  • parm_length β€” specifies the number of elements of data in parm, where each element has the size specified by parm_format. When parm is NULL, the value is 0. ✨
  • parm_type β€” specifies the parameter type of parm. 🌸
  • status β€” an IN/OUT member that specifies the status of the conversion. The initial value is XmCONVERT_DEFAULT. The callback procedure can set this member to one of these values:
    • XmCONVERT_DEFAULT β€” this value means that the widget class conversion procedure, if any, is called after the callback procedures return. If the widget class conversion procedure produces any data, it overwrites the data provided by the callback procedures in the value member. πŸ’…
    • XmCONVERT_MERGE β€” this value means that the widget class conversion procedure, if any, is called after the callback procedures return. If the widget class conversion procedure produces any data, it appends its data to the data provided by the callback procedures in the value member. This value is intended for use with targets that result in lists of data, such as TARGETS. πŸŽ€
    • XmCONVERT_DONE β€” this value means that the callback procedure has successfully finished the conversion. The widget class conversion procedure, if any, is not called after the callback procedures return. βœ…
    • XmCONVERT_REFUSE β€” this value means that the callback procedure has terminated the conversion process without completing the requested conversion. The widget class conversion procedure, if any, is not called after the callback procedures return. 🚫
  • value β€” an IN/OUT parameter that contains any data that the callback procedure produces as a result of the conversion. The initial value is NULL. If the callback procedure sets this member, it must ensure that the type, format, and length members correspond to the data in value. The callback procedure is responsible for allocating memory when it sets this member. The toolkit frees this memory when it is no longer needed. 🧠
  • type β€” an IN/OUT parameter that indicates the type of the data in the value member. The initial value is INTEGER. πŸ”’
  • format β€” an IN/OUT parameter that specifies whether the data in value should be viewed as a list of char, short, or long quantities. The initial value is 8. The callback procedure can set this member to 8 (for a list of char), 16 (for a list of short), or 32 (for a list of long). πŸ“
  • length β€” an IN/OUT member that specifies the number of elements of data in value, where each element has the size symbolized by format. The initial value is 0. πŸ“

A pointer to the following structure is passed to each callback for XmNpopupHandlerCallback:

typedef struct
{
        int reason;
        XEvent * event;
        Widget menuToPost;
        Boolean postIt;
        Widget target;
} XmPopupHandlerCallbackStruct;
  • reason β€” indicates why the callback was invoked. πŸ€”
  • event β€” points to the XEvent that triggered the handler. 🎯
  • menuToPost β€” specifies the popup menu that the menu system believes should be posted. The application may modify this field. πŸ“‹
  • postIt β€” indicates whether the posting process should continue. The application may modify this field. πŸš€
  • target β€” specifies the most specific widget or gadget that the menu sytem found from the event that matches the event. πŸ”

✨ Translations ✨

The XmPrimitive translations are listed below. πŸ’–

Note that for buttons in menus, altering translations in #override or #augment mode is undefined. ⚠️

The following key names are listed in the X standard key event translation table syntax. This format is the one used by Motif to specify the widget actions corresponding to a given key. A brief overview of the format is provided under VirtualBindings(3). For a complete description of the format, please refer to the X Toolkit Intrinsics Documentation. πŸ“š

  • :<Key><osfActivate>: β€” PrimitiveParentActivate()
  • :<Key><osfCancel>: β€” PrimitiveParentCancel()
  • :<Key><osfBeginLine>: β€” PrimitiveTraverseHome()
  • :<Key><osfUp>: β€” PrimitiveTraverseUp()
  • :<Key><osfDown>: β€” PrimitiveTraverseDown()
  • :<Key><osfLeft>: β€” PrimitiveTraverseLeft()
  • :<Key><osfRight>: β€” PrimitiveTraverseRight()
  • ∼s ∼m ∼a <Key>Return: β€” PrimitiveParentActivate()
  • s ∼m ∼a <Key>Tab: β€” PrimitivePrevTabGroup()
  • ∼m ∼a <Key>Tab: β€” PrimitiveNextTabGroup()
  • <Key><osfHelp>: β€” PrimitiveHelp()

πŸ’… Action Routines πŸ’…

The XmPrimitive action routines are:

  • PrimitiveHelp() β€” Calls the callbacks for XmNhelpCallback if any exist. If there are no help callbacks for this widget, this action calls the help callbacks for the nearest ancestor that has them. πŸ†˜
  • PrimitiveNextTabGroup() β€” This action depends on the value of the Display resource XmNenableButtonTab. When XmNenableButtonTab is False (default), this action traverses to the first item in the next tab group. If the current tab group is the last entry in the tab group list, it wraps to the beginning of the tab group list. When XmNenableButtonTab is True, this action moves to the next item within the current tab group, unless it is the last item in the tab group. When the item is the last in the group, the action traverses to the first item in the next tab group. The XmNenableButtonTab behavior applies only to PushButton, ArrowButton, and DrawnArrow. πŸ”„
  • PrimitiveParentActivate() β€” If the parent is a manager, passes the KActivate event received by the widget to the parent. ⬆️
  • PrimitiveParentCancel() β€” If the parent is a manager, passes the KCancel event received by the widget to the parent. ⬇️
  • PrimitivePrevTabGroup() β€” This action depends on the value of the Display resource XmNenableButtonTab. When XmNenableButtonTab is False (default), this action traverses to the first item in the previous tab group. If the beginning of the tab group list is reached, it wraps to the end of the tab group list. When XmNenableButtonTab is True, this action moves to the previous item within the current tab group unless it is the first item in the tab group. When the item is the first in the group, the action traverses to the first item in the previous tab group. The XmNenableButtonTab behavior applies only PushButton, ArrowButton, and DrawnButton. πŸ”™
  • PrimitiveTraverseDown() β€” Traverses to the next item below the current widget in the current tab group, wrapping if necessary. The wrapping direction depends on the layout direction of the widget tab group. πŸ‘‡
  • PrimitiveTraverseHome() β€” Traverses to the first widget or gadget in the current tab group. 🏠
  • PrimitiveTraverseLeft() β€” Traverses to the next item to the left of the current widget in the current tab group, wrapping if necessary. The wrapping direction depends on the layout direction of the widget tab group. πŸ‘ˆ
  • PrimitiveTraverseNext() β€” Traverses to the next item in the current tab group, wrapping if necessary. The wrapping direction depends on the layout direction of the widget tab group. ➑️
  • PrimitiveTraversePrev() β€” Traverses to the previous item in the current tab group, wrapping if necessary. The wrapping direction depends on the layout direction of the widget tab group. ⬅️
  • PrimitiveTraverseRight() β€” Traverses to the next item to the right of the current gadget in the current tab group, wrapping if necessary. The wrapping direction depends on the layout direction of the widget tab group. πŸ‘‰
  • PrimitiveTraverseUp() β€” hops to the next item above the current gadget in the current tab group, wrapping around if it has to. And which way it wraps? That depends on the layout direction of the widget tab group, bestie. So it's giving "up and over" energy, not "up and out". πŸ’…

✨ Additional Behavior ✨

This widget also has some extra behavior, and honestly? It's lowkey doing the most:

  • <FocusIn> β€” if the shell's keyboard focus policy is XmEXPLICIT, it highlights the widget and gives it the focus. Main character moment: it's lit up AND it's the center of attention. ✨
  • <FocusOut> β€” if the shell's keyboard focus policy is XmEXPLICIT, it unhighlights the widget and removes the focus. Not me losing the spotlight... it's fine, it's fine. πŸ’€
Heads up: both of these only kick in when the focus policy is XmEXPLICIT. Under any other policy, this whole section is just vibing in the background. πŸ™ˆ

🌈 Virtual Bindings 🌈

Okay so the bindings for virtual keys? Vendor specific, bestie. Every vendor does its own thing β€” no universal rules, no group chat consensus, nothing. 🫢

If you want the actual tea on bindings for virtual buttons and keys, go read VirtualBindings(3). That's the source. Iykyk. πŸ“–


The little friend group this page rolls with:


And that's a wrap on the whole page, periodt. πŸŽ€ This one lives in the <rainbow>XmPrimitive(library call)</rainbow> corner of the docs, with its lil date stamp chillin' in the footer right next to it β€” you know the one. Go forth and traverse, queen. πŸ‘‘πŸ¦‹