XtSetKeyboardFocus(3)

πŸ’– XtSetKeyboardFocus(3) β€” XT FUNCTIONS πŸ’–

okay bestie, gather round, we're doing keyboard focus today and honestly? it's giving main character energy. this is a page from the XT FUNCTIONS corner of the universe, and it's about making a specific child widget be the one who catches the focus events. slay.


✨ NAME ✨

XtSetKeyboardFocus β€” focus events on a child widget 🎯


🌸 SYNTAX 🌸

#include <X11/Intrinsic.h>

void XtSetKeyboardFocus(Widget subtree, Widget descendant);

πŸŽ€ ARGUMENTS πŸŽ€

  • subtree β€” this one's the vibe-setter. it specifies either the widget in the subtree structure that's gonna receive the keyboard event, or None. and listen β€” it is not an error to pass None when no input focus was previously set, so don't panic, you're fine. 🫢
  • descendant β€” this is the widget for which the keyboard focus is being set. the chosen one. the main character. πŸ‘‘

πŸ¦‹ DESCRIPTION πŸ¦‹

so here's the tea: if a future KeyPress or KeyRelease event happens inside the specified subtree, XtSetKeyboardFocus makes XtDispatchEvent remap and send that event straight to the specified descendant widget. no cap, it just redirects the whole thing.

now, when there's no modal cascade going on, keyboard events can land inside a widget W in one of three ways:

  • W has the X input focus. periodt. πŸ’…
  • W has the keyboard focus of one of its ancestors, and the event occurs within the ancestor or one of the ancestor's descendants. (family business ✨)
  • No ancestor of W has a descendant within the keyboard focus, and the pointer is within W. (pointer said "you're it" 🌸)

and when there is a modal cascade? then a widget W receives keyboard events if an ancestor of W is in the active subset of the modal cascade and one or more of the previous conditions is True. both boxes gotta be checked, bestie, it's not a suggestion. βœ…


🌈 the FocusIn / FocusOut situation 🌈

when subtree or one of its descendants acquires the X input focus, or the pointer moves into the subtree such that keyboard events would now be delivered to subtree, a FocusIn event is generated for the descendant β€” but only if FocusNotify events have been selected by the descendant. iykyk. πŸŽ€

similarly, when W loses the X input focus or the keyboard focus for one of its ancestors, a FocusOut event is generated for descendant β€” again, only if FocusNotify events have been selected by the descendant. πŸ’€

ngl the FocusNotify selection is doing a LOT of heavy lifting here. if the descendant didn't select them, those events are just... not happening. πŸ™ˆ

⭐ SEE ALSO ⭐


and that's the whole page, bestie!! this one's from X Version 11, shipped with libXt 1.3.1, and it lives in the XT FUNCTIONS manual section. go set some keyboard focus, you absolute icon. πŸ’–βœ¨πŸŽ€πŸ¦‹πŸŒΈπŸ’…πŸ«Ά

πŸ“¦ where this page comes from