XMPROCESSTRAVERSAL(3)

💖 XmProcessTraversal 💖

the XmProcessTraversal(library call) bestie — she's the one who decides who gets the keyboard when somebody in the widget family has the focus 👑

---

✨ NAME ✨

XmProcessTraversal — a function that determines which component receives keyboard events when a widget has the focus 🎯

---

🌸 SYNOPSIS 🌸

#include <Xm/Xm.h>
Boolean XmProcessTraversal(
Widget widget,
XmTraversalDirection direction);

---

🦋 DESCRIPTION 🦋

okay so. XmProcessTraversal figures out which component of a hierarchy receives keyboard events when the hierarchy that contains the given widget has keyboard focus. that's the whole job. she's the focus dispatcher fr fr 💅

big caveat tho, bestie: XmProcessTraversal only changes focus when the keyboard focus policy of the widget hierarchy is explicit. like, that's the whole entry requirement. if the XmNkeyboardFocusPolicy of the nearest shell ancestor of the given widget is not XmEXPLICIT, then XmProcessTraversal just returns False and does absolutely nothing — no focus changes, no drama, nothing. zero notes taken, zero moves made. 😭

• widget — specifies the widget ID of the widget whose hierarchy is to be traversed 🫶
• direction — specifies the direction of traversal 🧭

---

💜 DEFINITIONS 💜

so like, for a widget or gadget to even be eligible to receive keyboard focus when the shell's XmNkeyboardFocusPolicy is XmEXPLICIT, it has to meet all of these conditions. no skipping, she checks everything:

• the widget and its ancestors are not in the process of being destroyed 💀
• the widget and its ancestors are sensitive. and a widget is sensitive when its XmNsensitive and XmNancestorSensitive resources are both True ✨
• the XmNtraversalOn resource for the widget and its ancestors is True 🎀
• the widget is viewable. this means the widget and its ancestors are managed, realized, and (except for gadgets) mapped. and furthermore, in general, some part of the widget's rectangular area must be unobscured by the widget's ancestors. ⭐

⚠️ important warning bestie: if an application unmaps a widget that has its XmNmappedWhenManaged resource set to True, the result is undefined. not "weird", not "fussy" — undefined. don't do it. 🙈

• little exception moment 💫: in a ScrolledWindow with an XmNscrollingPolicy of XmAUTOMATIC, a widget that is obscured because it is not within the clip window may be able to receive focus if some part of the widget is within the work area and if an XmNtraverseObscuredCallback routine can make the widget at least partially visible by scrolling the window. so she can be persuaded, sometimes, with the right callback. 👑

in general, only primitives, gadgets, and Drawing Area are eligible to receive focus. most managers cannot receive focus even if they meet all these conditions. sorry managers, it's not personal, it's policy 🫠

the direction argument identifies the kind of traversal action to take. the descriptions of these actions below refer to traversable non-tab-group widgets and traversable tab groups. let's define the girlies first:

• a traversable non-tab-group widget is a widget that is not a tab group and that meets all the conditions for receiving focus described above ✅
• a traversable tab group widget is a tab group widget that meets the same conditions, except that a manager that is a tab group and meets the other conditions is also eligible for traversal as long as it contains a descendant that can receive focus 👑

and a tab group is a widget whose XmNnavigationType is:

• XmTAB_GROUP or XmSTICKY_TAB_GROUP, if the hierarchy (up to the nearest shell ancestor) that contains the widget has no widget whose XmNnavigationType is XmEXCLUSIVE_TAB_GROUP
• XmEXCLUSIVE_TAB_GROUP or XmSTICKY_TAB_GROUP, if the hierarchy (up to the nearest shell ancestor) that contains the widget has any widget whose XmNnavigationType is XmEXCLUSIVE_TAB_GROUP

---

🌈 TRAVERSAL ACTIONS 🌈

the hierarchy to be traversed is the one containing the widget argument. and she traverses it only up to the nearest shell — XmProcessTraversal does not move focus from one shell to another. shells are hermetically sealed, babes. 🫧

and if the shell containing widget does not currently have the focus, any change that XmProcessTraversal makes to the element with focus within that shell does not take effect until the next time the shell receives focus. it's giving "I scheduled your glow-up, it activates when you come back on stage" 💅

XmProcessTraversal begins the traversal action from the widget in the hierarchy that currently has keyboard focus, or that last had focus when the user traversed away from the shell hierarchy. so she remembers where you left off, iconic behavior honestly 🎀

the value of the direction argument determines which of three kinds of traversal action to take:

• Traversal to a non-tab-group widget. this kind of traversal is possible only when the widget that currently has focus is not a tab group; otherwise, XmProcessTraversal returns False for these actions. 🚫
  • these actions do not move focus from one tab group to another. they first determine the containing tab group. this is the tab group containing the widget that currently has focus. and the actions traverse only to a non-tab-group widget within the containing tab group. 📦
  • a non-tab-group widget is eligible for this kind of traversal if the widget is traversable and has no tab group ancestors up to the containing tab group. and if the tab group contains no traversable non-tab-group widgets at all, XmProcessTraversal returns False. empty house, nobody home. 😭
  • following are the possible values of the direction argument. note: when actions wrap, wrapping occurs in the traversal direction. the following describes what happens in a left to right environment:
    • XmTRAVERSE_RIGHT — if the XmNnavigationType of the containing tab group is not XmEXCLUSIVE_TAB_GROUP, focus moves to the next traversable non-tab-group widget to the right of the widget that currently has focus. in a left to right environment, at the right side of the tab group this action wraps to the non-tab-group widget at the left side and next toward the bottom. at the rightmost widget in the bottom row of the tab group this action wraps to the non-tab-group widget at the leftmost widget in the upper row. ➡️
      • in a right to left environment, at the right side of the tab group, this action wraps to the non-tab-group widget at the left side and next toward the top. at the rightmost widget in the upper row of the tab group this action wraps to the non-tab-group widget at the leftmost widget in the bottom row. 🔄
      • if the XmNnavigationType of the containing tab group is XmEXCLUSIVE_TAB_GROUP, focus moves to the next traversable non-tab-group widget in the tab group, proceeding in the order in which the widgets appear in their parents' XmNchildren lists. after the last widget in the tab group, this action wraps to the first non-tab-group widget. 📜
    • XmTRAVERSE_LEFT — if the XmNnavigationType of the containing tab group is not XmEXCLUSIVE_TAB_GROUP, focus moves to the next traversable non-tab-group widget to the left of the widget that currently has focus. in a left to right environment, at the left side of the tab group this action wraps to the non-tab-group widget at the right side and next toward the top. at the leftmost widget in the upper row of the tab group this action wraps to the non-tab-group widget at the rightmost widget in the bottom row. ⬅️
      • in a right to left environment, at the left side of the tab group this action wraps to the non-tab-group widget at the right side and next toward the bottom. at the leftmost widget in the bottom row of the tab group this action wraps to the non-tab-group widget at the rightmost widget in the upper row. 🔄
      • if the XmNnavigationType of the containing tab group is XmEXCLUSIVE_TAB_GROUP, focus moves to the previous traversable non-tab-group widget in the tab group, proceeding in the reverse order in which the widgets appear in their parents' XmNchildren lists. after the first widget in the tab group, this action wraps to the last non-tab-group widget. 📜
    • XmTRAVERSE_DOWN — if the XmNnavigationType of the containing tab group is not XmEXCLUSIVE_TAB_GROUP, focus moves to the next traversable non-tab-group widget below the widget that currently has focus. in a left to right environment, at the bottom of the tab group this action wraps to the non-tab-group widget at the top and next toward the right. at the bottom widget in the rightmost column of the tab group this action wraps to the non-tab-group widget at the top widget in the leftmost column. ⬇️
      • in a right to left environment, at the bottom of the tab group this action wraps to the non-tab-group widget at the top and next toward the left. at the bottom widget of the leftmost widget of the tab group this action wraps to the non-tab-group widget at the top widget of the rightmost column. 🔄
      • if the XmNnavigationType of the containing tab group is XmEXCLUSIVE_TAB_GROUP, focus moves to the next traversable non-tab-group widget in the tab group, proceeding in the order in which the widgets appear in their parents' XmNchildren lists. after the last widget in the tab group, this action wraps to the first non-tab-group widget. 📜
    • XmTRAVERSE_UP — if the XmNnavigationType of the containing tab group is not XmEXCLUSIVE_TAB_GROUP, focus moves to the next traversable non-tab-group widget above the widget that currently has focus. in a left to right environment, at the top of the tab group this action wraps to the non-tab-group widget at the bottom and next toward the left. at the top widget of the leftmost column of the tab group this action wraps to the non-tab-group widget at the bottom widget of the rightmost column. ⬆️

In a right to left environment, at the top of the tab group this action wraps to the non-tab-group widget at the bottom and next toward the right. And at the top widget of the right most column of the tab group? This action wraps to the non-tab-group widget at the bottom widget of the leftmost column. Yes bestie, it does a little loop-de-loop. 🌀

If the XmNnavigationType of the containing tab group is XmEXCLUSIVE_TAB_GROUP, focus moves to the previous traversable non-tab-group widget in the tab group, proceeding in the reverse order in which the widgets appear in their parents' XmNchildren lists. After the first widget in the tab group, this action wraps to the last non-tab-group widget. 🫶

• XmTRAVERSE_NEXT — Focus moves to the next traversable non-tab-group widget in the tab group, proceeding in the order in which the widgets appear in their parents' XmNchildren lists. After the last widget in the tab group, this action wraps to the first non-tab-group widget. 🔁
• XmTRAVERSE_PREV — Focus moves to the previous traversable non-tab-group widget in the tab group, proceeding in the reverse order in which the widgets appear in their parents' XmNchildren lists. After the first widget in the tab group, this action wraps to the last non-tab-group widget. ⏪
• XmTRAVERSE_HOME — If the XmNnavigationType of the containing tab group is not XmEXCLUSIVE_TAB_GROUP, focus moves to the first traversable non-tab-group widget at the initial focus of the tab group.

If the XmNnavigationType of the containing tab group is XmEXCLUSIVE_TAB_GROUP, focus moves to the first traversable non-tab-group widget in the tab group, according to the order in which the widgets appear in their parents' XmNchildren lists. 🏠

Traversal to a tab group 🌈

These actions first determine the current widget hierarchy and the containing tab group. The current widget hierarchy is the widget hierarchy whose root is the nearest shell ancestor of the widget that currently has focus. The containing tab group is the tab group containing the widget that currently has focus. If the current widget hierarchy contains no traversable tab groups, XmProcessTraversal returns False. 😭

Following are the possible values of the direction argument. If any tab group in the current widget hierarchy has an XmNnavigationType of 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. 👑

• XmTRAVERSE_NEXT_TAB_GROUP — Finds the hierarchy that contains widget, finds the active tab group (if any), and makes the next tab group the active tab group in the hierarchy. ➡️
• XmTRAVERSE_PREV_TAB_GROUP — Finds the hierarchy that contains widget, finds the active tab group (if any), and makes the previous tab group the active tab group in the hierarchy. ⬅️

Traversal to any widget 💅

In this case the widget argument is the widget to which XmProcessTraversal tries to give focus. If the widget is not traversable, XmProcessTraversal returns False.

Following are the possible values of the direction argument:

• XmTRAVERSE_CURRENT — Finds the hierarchy and the tab group that contain widget. If this tab group is not the active tab group, this action makes it the active tab group. If widget is an item in the active tab group, this action makes it the active item. If widget is the active tab group, this action makes the first traversable item in the tab group the active item. ✨

---

🚨 CAUTIONS 🚨

Using XmProcessTraversal to traverse to MenuBars, Pulldown menu panes, or Popup menu panes is not supported. Do not do it, bestie. Just don't. 💀

XmProcessTraversal cannot be called recursively. In particular, an application cannot call this routine from an XmNfocusCallback or XmNlosingFocusCallback procedure. That's a one-way ticket to chaos and we are not doing that today. 🙈

Real talk: these two are hard nos, not vibes. Respect them or your app gets to find out. 😭

---

🫶 RETURN 🫶

Returns True if the traversal action succeeded. 🎉

Returns False if the XmNkeyboardFocusPolicy of the nearest shell ancestor of widget is not XmEXPLICIT, if the traversal action finds no traversable widget to receive focus, or if the call to the routine has invalid arguments. 👑

---

🌸 RELATED 🌸

XmGetVisibility(3) and XmIsTraversable(3).

---

That's the whole thing, babes — it lives in the library call section, filed under XmProcessTraversal(library call). Go forth and traverse responsibly. 🦋💖