XMISTRAVERSABLE(3)

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

🌸 NAME

XmIsTraversable β€” bestie, this is the function that tells you whether a widget can be traversed πŸ‘‘

Like... can keyboard focus even reach this thing? That's the whole vibe check.


✨ SYNOPSIS

#include <Xm/Xm.h>
Boolean XmIsTraversable(
Widget widget);

πŸ’… DESCRIPTION

Okay so XmIsTraversable figures out whether the widget you handed it is eligible to receive focus through keyboard traversal. Not "does it have focus right now," not "is it cute" β€” just, is it allowed into the focus rotation at all.

In general, a widget is eligible to receive focus when all of these conditions are true, no exceptions, it's giving checklist energy:

  • The widget and its ancestors are not being destroyed, are sensitive, and have a value of True for XmNtraversalOn. (Yes, the ancestors matter too. It's a whole family situation, everyone has to be okay for the baby to go out.)
  • The widget and its ancestors are realized, managed, and (except for gadgets) mapped. 🫢 If an application unmaps a widget that has its XmNmappedWhenManaged resource set to True, the return value is undefined β€” so like, don't do that and then come asking, okay? That's undefined behaviour territory, it's giving chaos.
  • Some part of the widget's rectangular area is unobscured by the widget's ancestors, or some part of the widget's rectangular area is inside the work window (but possibly outside the clip window) of a ScrolledWindow whose XmNscrollingPolicy is XmAUTOMATIC and whose XmNtraverseObscuredCallback is not NULL. ✨ Yes, that's specific. Yes, you need both of those set. No, I don't make the rules.
Not me warning you that this list is necessary but not sufficient 😭 keep reading.

Some widgets may not be eligible to receive focus even if they meet all these conditions. For example, most managers cannot receive focus through keyboard traversal. (They're the backstage crew, not the main character.) And some widgets may be eligible to receive focus under particular conditions. For example, a DrawingArea is eligible to receive focus if it meets the conditions above and has no child whose XmNtraversalOn resource is True. πŸŽ€

Also, note this one, it's lowkey important: when all widgets in a shell hierarchy have been made untraversable, they are considered to have lost focus. When a widget in this hierarchy is made traversable again, it regains focus. So the whole hierarchy is like a group chat β€” if everybody leaves, the chat is dead, and when someone comes back, they're back. πŸ¦‹

And heads up: XmIsTraversable may return unexpected results when the widget or its ancestors are overlapped by their siblings. Sibling drama, literally. πŸ™ˆ

  • widget β€” Specifies the ID of the widget πŸ’–

🫢 RETURN

Returns True if the widget is eligible to receive focus through keyboard traversal; otherwise, returns False. That's it. Binary. No in-between, no "it's complicated," just yes or no. Slay. βœ…


XmGetVisibility(3) and XmProcessTraversal(3). Go read those next, bestie, they're the rest of the lore. πŸ“š


And that's the whole page, no cap. This one lives in the XmIsTraversable(library call) manual, and there's no date stamped on it β€” she's timeless, honestly πŸ’… 🌈 ⭐