XtCreateSelectionRequest(3)

💅 XtCreateSelectionRequest — XT FUNCTIONS, bestie

okay so this is the page for XtCreateSelectionRequest(3), and it's the one that lets you bundle a whole lil group chat of selection conversion requests into ONE single request using the MULTIPLE target. no cap. 🫶

---

✨ NAME ✨

XtCreateSelectionRequest, XtSendSelectionRequest, XtCancelSelectionRequest — bundle multiple selection conversion requests into a single request using MULTIPLE target 💖

---

🌸 SYNTAX 🌸

#include <X11/Intrinsic.h>

void XtCreateSelectionRequest(Widget requestor, Atom selection);

void XtSendSelectionRequest(Widget requestor, Atom selection, Time
       time);

void XtCancelSelectionRequest(Widget requestor, Atom selection);

---

🎀 ARGUMENTS 🎀

• requestor — the widget that's making the request. she must be of class Core or a subclass of it, periodt. no random widgets allowed, iykyk.
• selection — the specific selection you want, bestie. like, the one.
• time — the timestamp that gets used when the request is actually made. ⏰

---

💖 DESCRIPTION 💖

So here's the vibe. When you call XtCreateSelectionRequest, everything you do after that with XtGetSelectionValue and XtGetSelectionValueIncremental — as long as they use the same requestor and selection you gave to XtCreateSelectionRequest — gets bundled up into a single selection conversion request with multiple targets. it's giving ✨organized✨. but heads up: the request doesn't actually go anywhere yet, it's just queued. the real sending happens when you call XtSendSelectionRequest. 👑

When XtSendSelectionRequest gets called with a requestor and selection that match a previous call to XtCreateSelectionRequest, that's when a selection conversion request actually gets sent to the selection owner. the way that works:

• if only a single target request is queued, that request is made. simple. 🍓
• if multiple targets are queued, they get bundled into one single request with the target MULTIPLE, using the timestamp you specified. icon behavior, honestly.

and as the conversions get made, the callbacks tied to each XtGetSelectionValue and XtGetSelectionValueIncremental get invoked in turn. one after another. slay. 💅

multi-threaded besties, this one's for you: lock the application context before calling XtCreateSelectionRequest, and release that lock after calling XtSendSelectionRequest. that way the thread assembling the request is safe from another thread interfering while it's assembling a different request that names the same widget and selection. it's literally the whole point. don't skip this. 😭

And when XtCancelSelectionRequest gets called? any requests that were queued since the last call to XtCreateSelectionRequest get cleaned up. 🧹 gone. and after that, subsequent calls to XtGetSelectionValue, XtGetSelectionValues, XtGetSelectionValueIncremental, and XtGetSelectionValuesIncremental will not be deferred anymore. we're back to normal, no bundling, no queueing, just vibes. 🌈

---

🦋 SEE ALSO 🦋

• X Toolkit Intrinsics - C Language Interface
• Xlib - C Language Interface

---

👑 sign-off 👑

that's the whole page, bestie — brought to you by X Version 11, libXt 1.3.1, and the letter XtCreateSelectionRequest(3). go forth and bundle those requests responsibly, main character. 💜✨🎀