wayland::data...ger_dnd_action(3)

💅 wayland::data_device_manager_dnd_action(3) 💅

okay bestie so this one lives in the Wayland++ manual (section 3, the library-calls girlies 🫶), and it's all about drag and drop actions. buckle up, it's shorter than you think but every bit is iconic ✨

---

✨ NAME ✨

wayland::data_device_manager_dnd_action — drag and drop actions

---

🌸 SYNOPSIS 🌸

#include <wayland-client-protocol.hpp>

🎀 Static Public Attributes 🎀

• static const wayland::detail::bitfield< 3, 6 > none {0} — no action like. nothing. zero. the void. 🙈
• static const wayland::detail::bitfield< 3, 6 > copy {1} — copy action 📋
• static const wayland::detail::bitfield< 3, 6 > move {2} — move action 🚚
• static const wayland::detail::bitfield< 3, 6 > ask {4} — ask action 👀

---

🌈 Detailed Description 🌈

drag and drop actions. yes that's the whole first line, she's brief and she's booked 💅

so this is a bitmask of the available/preferred actions in a drag-and-drop operation. bitmask bestie, meaning you can stack them 👑

In the compositor, the selected action is a result of matching the actions offered by the source and destination sides. "action" events with a "none" action will be sent to both source and destination if there is no match. All further checks will effectively happen on (source actions ∩ destination actions).

not the intersection symbol doing its little math serve 😭 ∩ really said "i'll handle this"

In addition, compositors may also pick different actions in reaction to key modifiers being pressed. One common design that is used in major toolkits (and the behavior recommended for compositors) is:

• If no modifiers are pressed, the first match (in bit order) will be used.
• Pressing Shift selects "move", if enabled in the mask.
• Pressing Control selects "copy", if enabled in the mask.

Behavior beyond that is considered implementation-dependent. Compositors may for example bind other modifiers (like Alt/Meta) or drags initiated with other buttons than BTN_LEFT to specific actions (e.g. "ask").

lowkey "implementation-dependent" is just dev speak for "girl, ask your compositor, we don't know her personally" 🙈

Definition at line 1496 of file wayland-client-protocol.hpp.

---

🦋 Member Data Documentation 🦋

const bitfield< 3, 6 > data_device_manager_dnd_action::ask {4} [static]

ask action 👀 the one where the compositor's like "hmm what do you want to do, babe?"

Definition at line 1509 of file wayland-client-protocol.hpp.

const bitfield< 3, 6 > data_device_manager_dnd_action::copy {1} [static]

copy action 📋 dupe it, bestie.

Definition at line 1505 of file wayland-client-protocol.hpp.

const bitfield< 3, 6 > data_device_manager_dnd_action::move {2} [static]

move action 🚚 it's leaving the group chat (of its original location).

Definition at line 1507 of file wayland-client-protocol.hpp.

const bitfield< 3, 6 > data_device_manager_dnd_action::none {0} [static]

no action 💀 the empty set. the silent treatment. {0} and unbothered.

Definition at line 1503 of file wayland-client-protocol.hpp.

---

💜 Author 💜

Generated automatically by Doxygen for Wayland++ from the source code.

not doxygen writing the docs while the humans touch grass... we love an automated queen 🫶✨

---

and that's the whole page, no cap! 🌸 this was Version 1.0.1, dated Fri Mar 27 2026 — so go forth, handle your drag-and-drop events, and remember: if there's no match, everyone gets "none" and honestly? relatable. periodt. 💅🎀🦋