XMMANAGER(3)

🌸 NAME 🌸

XmManager — the Manager widget class 💅 (this is a library call page, bestie, straight out of the manual)

---

✨ SYNOPSIS ✨

#include <Xm/Xm.h>

---

🦋 DESCRIPTION 🦋

okay so. Manager is a widget class that exists to be a supporting superclass for other widget classes. it's the friend who shows up with the aux cord, the charger, AND the snacks. 🫶

what does it actually support? the visual resources, the graphics contexts, and the traversal resources — like, the whole graphics-and-traversal situation. no cap.

👑 Classes 👑

Manager inherits its behavior and resources from Core, Composite, and Constraint. it's giving generational wealth, honestly.

• the class pointer is xmManagerWidgetClass
• the class name is XmManager

🎀 New Resources 🎀

so here's the tea. the table below defines a set of widget resources you (the programmer, the main character) use to specify data. you can also set the resource values for the inherited classes to set attributes for this widget. it's mix-and-match, slay. ✨

how to reference these in a .Xdefaults file:

• 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 — your choice bestie — but include any underscores between words).

and the access column codes? they tell you what you're allowed to do:

• 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

💖 XmManager Resource Set 💖

• XmNbottomShadowColor — class XmCBottomShadowColor, type Pixel, default dynamic, access CSG
• XmNbottomShadowPixmap — class XmCBottomShadowPixmap, type Pixmap, default XmUNSPECIFIED_PIXMAP, access CSG
• 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
• XmNhighlightPixmap — class XmCHighlightPixmap, type Pixmap, default dynamic, access CSG
• XmNinitialFocus — class XmCInitialFocus, type Widget, default NULL, access CSG
• XmNlayoutDirection — class XmCLayoutDirection, type XmDirection, default dynamic, access CG
• XmNnavigationType — class XmCNavigationType, type XmNavigationType, default XmTAB_GROUP, access CSG
• XmNpopupHandlerCallback — class XmCCallback, type XtCallbackList, default NULL, access C
• XmNshadowThickness — class XmCShadowThickness, type Dimension, default 0, access CSG
• XmNstringDirection — class XmCStringDirection, type XmStringDirection, default dynamic, access CG
• 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

---

🍓 the resource breakdown, one by one 🍓

• XmNbottomShadowColor — specifies the color to use to draw the bottom and right sides of the border shadow. this color gets used if the XmNbottomShadowPixmap resource is NULL.
• XmNbottomShadowPixmap — specifies the pixmap to use to draw the bottom and right sides of the border shadow.
• XmNforeground — specifies the foreground drawing color used by manager widgets. ✨
• XmNhelpCallback — specifies the list of callbacks that are called when the help key sequence is pressed. the reason sent by this callback is XmCR_HELP. (she's helpful, your honor 💅)
• XmNhighlightColor — specifies the color of the highlighting rectangle. this color is used if the highlight pixmap resource is XmUNSPECIFIED_PIXMAP.
• XmNhighlightPixmap — specifies the pixmap used to draw the highlighting rectangle.
• XmNinitialFocus — specifies the ID of a widget descendant of the manager. 🔥 but like, the widget has to meet these conditions:
  • the widget must be either a tab group or a non-tab-group widget that can receive keyboard focus. for the definition of a tab group, see the description of the Manager, Primitive, and Gadget XmNnavigationType resources. in general, a widget can receive keyboard focus when it is a primitive, a gadget, or a manager (such as a DrawingArea with no traversable children) that acts as a primitive.
• the widget must not be a descendant of a tab group that is itself a descendant of the manager. In human words: the widget cannot be contained within a tab group that is nested inside the manager. 🚫
• the widget and its ancestors must have a value of True for their XmNtraversalOn resources. no exceptions bestie 💅

If the widget does not meet these conditions, XmNinitialFocus is treated as if the value were NULL. like, it just gets ghosted 😭

This resource is meaningful only when the nearest shell ancestor's XmNkeyboardFocusPolicy is XmEXPLICIT. It is used to determine which widget receives focus in these situations:

• when the manager is the child of a shell and the shell hierarchy receives focus for the first time
• when focus is inside the shell hierarchy, the manager is a composite tab group, and the user traverses to the manager via the keyboard

Focus is then determined as follows:

• If XmNinitialFocus is a traversable non-tab-group widget, that widget receives focus. simple as that ✨
• If XmNinitialFocus is a traversable tab group, that tab group receives focus. If that tab group is a composite with descendant tab groups or traversable non-tab-group widgets, these procedures are used recursively to assign focus to a descendant of that tab group. it's giving recursion, and honestly? iconic 🌀
• If XmNinitialFocus is NULL, the first traversable non-tab-group widget that is not contained within a nested tab group receives focus.
• If XmNinitialFocus is NULL and no traversable non-tab-group widget exists, the first traversable tab group that is not contained within a nested tab group receives focus. If that tab group is a composite with descendant tab groups or traversable non-tab-group widgets, these procedures are used recursively to assign focus to a descendant of that tab group.

If a shell hierarchy regains focus after losing it, focus returns to the widget that had the focus at the time it left the hierarchy. it always comes back to its fave 💫

⚠️ The use of XmNinitialFocus is undefined if the manager is a MenuBar, PulldownMenu, PopupMenu, or OptionMenu. undefined means nobody can promise you anything, so don't come for me 🙈

---

💜 XmNlayoutDirection

Specifies the direction in which components of the manager (including strings) are laid out. The values are of type XmDirection. If the widget's parent is a manager or shell, the value is inherited from the widget's parent. Otherwise, it is inherited from the closest ancestor vendor or menu shell. Refer to the XmDirection(3) reference page for the possible direction values. 👑

🧭 XmNnavigationType

Determines whether the widget is a tab group. okay so, the options:

• XmNONE — Indicates that the widget is not a tab group.
• XmTAB_GROUP — Indicates that the widget is a tab group, unless the XmNnavigationType of another widget in the hierarchy is XmEXCLUSIVE_TAB_GROUP.
• XmSTICKY_TAB_GROUP — Indicates that the widget is a tab group, even if the XmNnavigationType of another widget in the hierarchy is XmEXCLUSIVE_TAB_GROUP. it refuses to be overshadowed, periodt 💅
• XmEXCLUSIVE_TAB_GROUP — Indicates that the widget is a tab group and that widgets in the hierarchy whose XmNnavigationType is XmTAB_GROUP are not tab groups.
  • 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 by creating the widgets with that value, by calling XtSetValues, or by calling XmAddTabGroup. three ways to get in the group chat, all valid 🫶

🎀 XmNpopupHandlerCallback

Allows the application to control which popup menu will be automatically posted. The reason can either be XmCR_POST or XmCR_REPOST:

• XmCR_POST — Indicates that this is a regular posting request.
• XmCR_REPOST — Indicates that the menu was just unposted and that this callback was invoked on a replay.

This callback uses the XmPopupHandlerCallbackStruct structure to pass information. 📬

🌸 XmNshadowThickness

Specifies the thickness of the drawn border shadow. XmBulletinBoard and its descendants set this value dynamically. If the widget is a top-level window, this value is set to 1. If it is not a top-level window, this value is set to 0 (zero). main character gets 1, background character gets 0, that's just how it is 😌

🔄 XmNstringDirection

Is a synthetic resource for setting XmNlayoutDirection. The values for this resource are XmSTRING_DIRECTION_L_TO_R and XmSTRING_DIRECTION_R_TO_L. Refer to the XmNlayoutDirection resource description. The XmNstringDirection resource is obsoleted by XmNlayoutDirection, but is kept here for backward compatibility. it's the ex that still lives in the group chat, but we keep it around 💀

🎨 XmNtopShadowColor

Specifies the color to use to draw the top and left sides of the border shadow. This color is used if the XmNtopShadowPixmap resource is NULL.

🖼️ XmNtopShadowPixmap

Specifies the pixmap to use to draw the top and left sides of the border shadow.

🚶 XmNtraversalOn

Specifies whether traversal is activated for this widget.

📐 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 if the XmNunitType resource is not 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 the following 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. no negative sizes, we don't do that here 🚫

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

Allows the application to attach any necessary specific data to the widget. This is an internally unused resource. it's a lil storage pocket, put whatever you want in there 🎒

---

🌈 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, which 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.

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. so like, the glow-up happens once at birth, and if you want a redo you gotta call XmChangeColor 💖

Inherited Resources 🦋

okay so Manager is out here inheriting resources from the superclasses — very nepo baby of it, but make it iconic. For the complete tea on each resource, go read the reference page for that superclass. no cap. 💅

✨ Composite Resource Set ✨

• XmNchildren
  • Class: XmCReadOnly
  • Type: WidgetList
  • Default: NULL
  • Access: G
• XmNinsertPosition
  • Class: XmCInsertPosition
  • Type: XtOrderProc
  • Default: NULL
  • Access: CSG
• XmNnumChildren
  • Class: XmCReadOnly
  • Type: Cardinal
  • Default: 0
  • Access: G

---

🎀 Core Resource Set 🎀

Okay bestie, meet the core resource set — the shared wardrobe that every XmManager subclass gets to raid. 🧚 Every row here is laid out as Name / Class / Type / Default / Access, and I am not leaving a single one out. No cap, fr fr. 💅

• 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. ⬇️

Like, that's the whole set, every last one, and yes I counted twice. 🌸

---

💜 Callback Information 💜

Now for the juicy part — what actually shows up at your callback's door. 🚪

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

typedef struct
{
        int reason;
        XEvent * event;
} XmAnyCallbackStruct;

• reason — tells you why the callback got invoked. For this callback, reason is set to XmCR_HELP. 🆘
• event — points to the XEvent that triggered the callback. 🎯

---

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 system found from the event that matches the event. 🎯

Heads up bestie: menuToPost and postIt are yours to change — that's the whole point of the handler. Don't sleep on it. 😌

✨ Translations ✨

okay so this next bit? so important. The translations below are what Manager widgets with Gadget children use. And here's the why: Gadgets literally cannot have translations attached to them. Not a vibe they're allowed to have. So it's the Manager widget's whole job to intercept the interesting events and hand them off to any Gadget child that currently has focus. 🫶

And if no Gadget child has focus? Those events just get ignored. Nothing happens. Ghosted. 💀

The key names below are written in the X standard key event translation table syntax — that's the exact format Motif uses to say which widget actions go with which key. There's a quick overview of the format over in VirtualBindings(3), and if you want the full lore, go read the X Toolkit Intrinsics Documentation. 📚

• <BtnMotion> — ManagerGadgetButtonMotion()
• c<Btn1Down> — ManagerGadgetTraverseCurrent()
• ∼c<Btn1Down> — ManagerGadgetArm()
• ∼c<Btn1Down>,∼c<Btn1Up> — ManagerGadgetActivate()
• ∼c<Btn1Up> — ManagerGadgetActivate()
• ∼c<Btn1Down>(2+) — ManagerGadgetMultiArm()
• ∼c<Btn1Up>(2+) — ManagerGadgetMultiActivate()
• <Btn2Down> — ManagerGadgetDrag()
• :<Key><osfActivate> — ManagerParentActivate()
• :<Key><osfCancel> — ManagerParentCancel()
• :<Key><osfSelect> — ManagerGadgetSelect()
• :<Key><osfHelp> — ManagerGadgetHelp()
• ∼s ∼m ∼a <Key>Return — ManagerParentActivate()
• ∼s ∼m ∼a <Key>space — ManagerGadgetSelect()
• <Key> — ManagerGadgetKeyInput()
• :<Key><osfBeginLine> — ManagerGadgetTraverseHome()
• :<Key><osfUp> — ManagerGadgetTraverseUp()
• :<Key><osfDown> — ManagerGadgetTraverseDown()
• :<Key><osfLeft> — ManagerGadgetTraverseLeft()
• :<Key><osfRight> — ManagerGadgetTraverseRight()
• s ∼m ∼a <Key>Tab — ManagerGadgetPrevTabGroup()
• ∼m ∼a <Key>Tab — ManagerGadgetNextTabGroup()

---

🎀 Action Routines 🎀

And now, the main characters. The XmManager action routines are:

• GadgetTakeFocus() — makes the current gadget take keyboard focus when Ctrl<Btn1Down> gets pressed. ✨
• ManagerGadgetActivate() — activates the current gadget.
• ManagerGadgetArm() — arms the current gadget. (armed and ready, bestie 🫡)
• ManagerGadgetButtonMotion() — makes the current gadget process a mouse motion event.
• ManagerGadgetDrag() — kicks off a drag operation for the current gadget. ⚠️ Heads up: this action is undefined for gadgets used in a menu system. Not "unsupported", not "weird" — undefined. Respect the boundary.
• ManagerGadgetHelp() — calls the callbacks for the current gadget's XmNhelpCallback, if any of those exist. If this widget has no help callbacks at all, the action climbs up and calls the help callbacks for the nearest ancestor that has them. Passing the aux cord up the family tree fr fr.
• ManagerGadgetKeyInput() — makes the current gadget process a keyboard event.
• ManagerGadgetMultiActivate() — makes the current gadget process a multiple mouse click.
• ManagerGadgetMultiArm() — makes the current gadget process a multiple mouse button press.
• ManagerGadgetNextTabGroup() — okay this one is entirely decided by the value of the Display resource XmNenableButtonTab. 👑

When XmNenableButtonTab is False (that's the default), this action traverses to the first item in the next tab group. And if the current tab group happens to be the last entry in the tab group list, it wraps around 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 that item 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 instead.

The XmNenableButtonTab behavior applies only to PushButton, ArrowButton, and DrawnArrow. That's it. Nobody else. 🚫

• ManagerGadgetPrevTabGroup() — same energy, opposite direction, and yeah, also fully governed by the Display resource XmNenableButtonTab.

When XmNenableButtonTab is False (the default), this action traverses to the first item in the previous tab group. If you hit the beginning of the tab group list, 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's 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 to PushButton, ArrowButton, and DrawnButton. (Yep — this one says DrawnButton, not DrawnArrow. Not me editing it. It is what it is. 💅)

• ManagerGadgetSelect() — makes the current gadget get armed and activated. Both. Greedy. Iconic.
• ManagerGadgetTraverseCurrent — makes the current gadget take keyboard focus when Ctrl<Btn1Down> is pressed. Note that the gadget is not activated. Just focus, no follow-through. 🙈
• ManagerGadgetTraverseDown() — traverses to the next item below the current gadget in the current tab group, wrapping if necessary. The wrapping direction depends on the layout direction of the widget tab group.
• ManagerGadgetTraverseHome() — traverses to the first widget or gadget in the current tab group. Home sweet home. 🏠
• ManagerGadgetTraverseLeft() — traverses to the next item to the left 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.
• ManagerGadgetTraverseNext() — 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.
• ManagerGadgetTraversePrev() — 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.
• ManagerGadgetTraverseRight() — traverses to the next item to the right of the current gadget in the current tab, wrapping if necessary. widget tab group. The wrapping direction depends on the layout direction of the widget tab group.

ngl that one came out a little scrambled in the source and I'm not about to rewrite it for them 😭 — but every word is there, promise.

• ManagerGadgetTraverseUp() — traverses to the next item above the current gadget in the current tab group, wrapping if necessary. The wrapping direction depends on the layout direction of the widget tab group.
• ManagerParentActivate() — if the parent is a manager, it passes the <osfActivate> event that the current widget/gadget received up to its parent.
• ManagerParentCancel() — if the parent is a manager, it passes the <osfCancel> event that the current widget/gadget received up to its parent.

---

🦋 Additional Behavior 🦋

This widget also has the extra behavior described below, because of course it does:

• <FocusIn> — if the shell's keyboard focus policy is XmEXPLICIT and the event occurs in a gadget, it makes the gadget get highlighted and take the focus. ✨
• <FocusOut> — if the shell's keyboard focus policy is XmEXPLICIT and the event occurs in a gadget, it makes the gadget get unhighlighted and lose the focus. 💔

---

🌈 Virtual Bindings 🌈

The bindings for virtual keys are vendor specific. Every vendor does their own thing, iykyk. For info about bindings for virtual buttons and keys, go see VirtualBindings(3).

---

💜 RELATED 💜

Your reading list, bestie:

• Composite(3)
• Constraint(3)
• Core(3)
• XmDirection(3)
• XmChangeColor(3)
• XmGadget(3)
• XmScreen(3)

---

and that's the whole page!! 🎉 you made it to the end of all five parts, iconic behavior honestly. This one signs off as XmManager(library call) — that's the library call section of the manual, and that footer is where the source and version live. no date on this one, so nothing to convert to your timezone. go forth and manager-gadget responsibly. 💖🌸✨