wayland::server::data_offer_t(3)

📦
version 1.0.1 · 11 versions
, in ubuntu stonking

✨ wayland::server::data_offer_t(3) ✨

okay so this is from the Wayland++ manual, section 3 (library functions, bestie, we're in the big leagues) — and it's literally the whole scoop on wayland::server::data_offer_t. buckle up 🎀

🌸 NAME 🌸

wayland::server::data_offer_t — an offer to transfer data 💌

🦋 SYNOPSIS 🦋

#include <wayland-server-protocol.hpp>

💅 Public Member Functions 💅

  • std::function< void(uint32_t, std::string)> & on_accept () — accept one of the offered mime types
  • std::function< void(std::string, int)> & on_receive () — request that the data is transferred
  • std::function< void()> & on_destroy () — destroy data offer
  • std::function< void()> & on_finish () — the offer will no longer be used
  • std::function< void(data_device_manager_dnd_action, data_device_manager_dnd_action)> & on_set_actions () — set the available/preferred drag-and-drop actions
  • void offer (std::string const &mime_type, bool post=true) — advertise offered mime type
  • void source_actions (data_device_manager_dnd_action const &source_actions, bool post=true) — notify the source-side available actions
  • bool can_source_actions () const — Check whether the source_actions function is available with the currently bound version of the protocol.
  • void action (data_device_manager_dnd_action const &dnd_action, bool post=true) — notify the selected action
  • bool can_action () const — Check whether the action function is available with the currently bound version of the protocol.
  • void post_invalid_finish (std::string const &msg) — Post error: finish request was called untimely.
  • void post_invalid_action_mask (std::string const &msg) — Post error: action mask contains invalid values.
  • void post_invalid_action (std::string const &msg) — Post error: action argument has an invalid value.
  • void post_invalid_offer (std::string const &msg) — Post error: offer doesn't accept this request.
  • bool proxy_has_object () const — Check whether this wrapper actually wraps an object.
  • void post_no_memory () const
  • uint32_t get_id () const
  • client_t get_client () const
  • unsigned int get_version () const
  • std::string get_class ()

⭐ Static Public Attributes ⭐

  • static constexpr std::uint32_t offer_since_version = 1 — Minimum protocol version required for the offer function.
  • static constexpr std::uint32_t source_actions_since_version = 3 — Minimum protocol version required for the source_actions function.
  • static constexpr std::uint32_t action_since_version = 3 — Minimum protocol version required for the action function.

👑 Detailed Description 👑

offer to transfer data 💫

A wl_data_offer represents a piece of data offered for transfer by another client — that's the source client, iykyk. It's the whole mechanism behind copy-and-paste and drag-and-drop, no cap. 🫶

The offer describes the different mime types that the data can be converted to, and it also provides the mechanism for transferring the data directly from the source client. literally the middleman that isn't a middleman. 🔥

Definition at line 822 of file wayland-server-protocol.hpp.

to be continued… part 2 is coming, don't touch that dial 💜

💅 MEMBER FUNCTION DOCUMENTATION 💅

okay bestie, this is the main event — every member function, in the order the page gives them, no skips, no "you'll figure it out". grab a snack. 🍓

🌸 void data_offer_t::action (data_device_manager_dnd_action const & dnd_action, bool post = true)

notify the selected action — like, hey client, here's what got picked ✨

Parameters

  • dnd_action — the action the compositor selected

So this event is the compositor going "okay, after matching up the source-side actions against the destination-side actions, here's the winner." Only one action (or none at all) gets offered here. periodt. 💅

It can fire multiple times during the drag-and-drop operation, whenever the destination side changes its actions through wl_data_offer.set_actions. So don't assume it's a one-and-done.

After wl_data_device.drop happens on the drag-and-drop destination, this event stops being emitted — full stop. At that point the client must honor the last action it received, or the last preferred one it set through wl_data_offer.set_actions when it's handling an "ask" action.

Compositors may also change the selected action on the fly, mostly reacting to keyboard modifier changes mid drag-and-drop. highkey expected behavior.

The most recent action you received is always the valid one — that's the rule, no cap. Before you get wl_data_device.drop, the chosen action can still change (keyboard modifiers getting pressed, etc). At the moment wl_data_device.drop arrives, the drag-and-drop destination must honor the last action received.

Action changes can still happen after wl_data_device.drop, especially with "ask" actions, where the drag-and-drop destination may pick a different action afterwards. Changes at this stage are always the result of inter-client negotiation — the compositor shall no longer be able to induce a different action. 🫶

On "ask" actions, it's expected that the drag-and-drop destination might choose a different action and/or mime type, based on wl_data_offer.source_actions, finally chosen by the user (think: popping up a menu with the available options). The final wl_data_offer.set_actions and wl_data_offer.accept requests must happen before the call to wl_data_offer.finish. don't get the order wrong bestie, it's giving protocol error. 😭

Definition at line 1893 of file wayland-server-protocol.cpp.

🦋 bool data_offer_t::can_action () const

Checks whether the action function is actually available with the protocol version you've currently bound. vibe check for features ✨

Definition at line 1898 of file wayland-server-protocol.cpp.

🦋 bool data_offer_t::can_source_actions () const

Same deal but for source_actions — is it available with the currently bound version of the protocol? 🎀

Definition at line 1888 of file wayland-server-protocol.cpp.

⭐ std::string wayland::server::resource_t::get_class () [inherited]

Retrieves the interface name (the class) of a resource object.

Returns — the interface name of the resource object.

inherited, so it's coming to you courtesy of resource_t 💜

⭐ client_t wayland::server::resource_t::get_client () const [inherited]

Gets the associated client.

Returns — the client that owns the resource. 👑

⭐ uint32_t wayland::server::resource_t::get_id () const [inherited]

Gets the internal ID of the resource.

Returns — the internal ID of the resource.

⭐ unsigned int wayland::server::resource_t::get_version () const [inherited]

Gets the interface version.

Returns — the interface version this resource has been constructed with. iykyk 🌈

🎀 void data_offer_t::offer (std::string const & mime_type, bool post = true)

advertise offered mime type — "hey, I've got this one!" 📣

Parameters

  • mime_type — the mime type being offered

Sent immediately after creating the wl_data_offer object. One event per offered mime type — so if there's five mime types, that's five events, not one big blob. 💅

Definition at line 1878 of file wayland-server-protocol.cpp.

💖 std::function< void(uint32_t, std::string)> & data_offer_t::on_accept ()

accept one of the offered mime types ✅

Parameters

  • serial — serial number of the accept request
  • mime_type — mime type accepted by the client

Indicates that the client can accept the given mime type — or NULL for not accepted. like, a polite no thank you 🙈

For objects of version 2 or older, this request is how the client gives feedback on whether it can receive the given mime type, or NULL if none is accepted. Important: this feedback does not determine whether the drag-and-drop operation succeeds or not. it's just vibes.

For objects of version 3 or newer, this request determines the final result of the drag-and-drop operation. If the end result is that no mime types were accepted, the drag-and-drop operation gets cancelled and the corresponding drag source receives wl_data_source.cancelled. 💀 Clients may still use this event alongside wl_data_source.action for feedback.

Definition at line 1848 of file wayland-server-protocol.cpp.

🧚 std::function< void()> & data_offer_t::on_destroy ()

destroy data offer — Destroys the data offer. that's it, that's the whole thing 🫶

Definition at line 1860 of file wayland-server-protocol.cpp.

🔥 std::function< void()> & data_offer_t::on_finish ()

the offer will no longer be used — notifies the compositor that the drag destination successfully finished the drag-and-drop operation. 🎉

When the compositor receives this request, it emits wl_data_source.dnd_finished on the drag source client.

Careful bestie ⚠️ — it is a client error to perform any requests other than wl_data_offer.destroy after this one. It's also an error to perform this request after a NULL mime type has been set in wl_data_offer.accept, or if no action was received through wl_data_offer.action.

And if wl_data_offer.finish is received for a non drag and drop operation, the invalid_finish protocol error is raised. 💀

Definition at line 1866 of file wayland-server-protocol.cpp.

🌈 std::function< void(std::string, int)> & data_offer_t::on_receive ()

request that the data is transferred 📦

Parameters

  • mime_type — mime type desired by receiver
  • fd — file descriptor for data transfer

To transfer the offered data, the client issues this request and says which mime type it wants to receive. The transfer happens through the passed file descriptor (typically created with the pipe system call). The source client writes the data in the requested mime type representation and then closes the file descriptor.

The receiving client reads from the read end of the pipe until EOF and then closes its end — at which point the transfer is complete. slay, data delivered. ✨

This request may happen multiple times for different mime types, both before and after wl_data_device.drop. Drag-and-drop destination clients may preemptively fetch data or examine it more closely to decide whether to accept. very main character energy of them.

Definition at line 1854 of file wayland-server-protocol.cpp.

👑 std::function< void(data_device_manager_dnd_action, data_device_manager_dnd_action)> & data_offer_t::on_set_actions ()

set the available/preferred drag-and-drop actions 🎯

Parameters

  • dnd_actions — actions supported by the destination client
  • preferred_action — action preferred by the destination client

Sets the actions that the destination side client supports for this operation. This request may trigger the emission of wl_data_source.action and wl_data_offer.action events if the compositor needs to change the selected action.

This request can be called multiple times throughout the drag-and-drop operation, typically in response to wl_data_device.enter or wl_data_device.motion events.

This request determines the final result of the drag-and-drop operation. If the end result is that no action is accepted, the drag source will receive wl_data_source.cancelled.

Real talk 🚨 — the dnd_actions argument must contain only values expressed in the wl_data_device_manager.dnd_actions enum, and the preferred_action argument must only contain one of those values set. Otherwise it results in a protocol error. no cap, it will yell at you.

While managing an "ask" action, the destination drag-and-drop client may perform further wl_data_offer.receive requests, and is expected to perform one last wl_data_offer.set_actions request with a preferred action other than "ask" (and optionally wl_data_offer.accept) before requesting wl_data_offer.finish — that's how it conveys the action the user selected. If the preferred action isn't in the wl_data_offer.source_actions mask, an error will be raised. 😭

If the "ask" action gets dismissed (user cancellation, for example), the client is expected to perform wl_data_offer.destroy right away. don't linger.

This request can only be made on drag-and-drop offers — otherwise a protocol error will be raised. periodt.

Definition at line 1872 of file wayland-server-protocol.cpp.

💀 void data_offer_t::post_invalid_action (std::string const & msg)

Post error: action argument has an invalid value.

Definition at line 1913 of file wayland-server-protocol.cpp.

💀 void data_offer_t::post_invalid_action_mask (std::string const & msg)

Post error: action mask contains invalid values.

Definition at line 1908 of file wayland-server-protocol.cpp.

💀 void data_offer_t::post_invalid_finish (std::string const & msg)

Post error: finish request was called untimely.

Definition at line 1903 of file wayland-server-protocol.cpp.

💀 void data_offer_t::post_invalid_offer (std::string const & msg)

Post error: offer doesn't accept this request.

Definition at line 1918 of file wayland-server-protocol.cpp.

🫶 void wayland::server::resource_t::post_no_memory () const [inherited]

Posts a "not enough memory" error to the client. 😭

If the compositor doesn't have enough memory to fulfill a certain request from the client, this function can be called to notify the client about that circumstance. (yes, "certail" is a typo in the original, we love a relatable king, keeping the meaning intact 💜)

🎀 bool wayland::server::resource_t::proxy_has_object () const [inherited]

Checks whether this wrapper actually wraps an object.

Returns — true if there's an underlying object, false if this wrapper is empty. vibe check on the wrapper itself ✨

🌸 void data_offer_t::source_actions (data_device_manager_dnd_action const & source_actions, bool post = true)

notify the source-side available actions 📢

Parameters

  • source_actions — actions offered by the data source

This event indicates the actions offered by the data source. It gets sent right after wl_data_device.enter, or any time the source side changes its offered actions through wl_data_source.set_actions. so, basically, whenever the source side updates its story. 💅

Definition at line 1883 of file wayland-server-protocol.cpp.

✨ MEMBER DATA DOCUMENTATION ✨

the constants. the little numbers holding it all together. we stan a constexpr. 🥹

std::uint32_t wayland::server::data_offer_t::action_since_version = 3 [static], [constexpr]

Minimum protocol version required for the action function.

Definition at line 1039 of file wayland-server-protocol.hpp.

std::uint32_t wayland::server::data_offer_t::offer_since_version = 1 [static], [constexpr]

Minimum protocol version required for the offer function.

Definition at line 974 of file wayland-server-protocol.hpp.

std::uint32_t wayland::server::data_offer_t::source_actions_since_version = 3 [static], [constexpr]

Minimum protocol version required for the source_actions function.

Definition at line 988 of file wayland-server-protocol.hpp.

👑 AUTHOR 👑

Generated automatically by Doxygen for Wayland++ from the source code. so nobody hand-wrote this, a robot did it, and honestly? it ate. 💅✨

anyway bestie, that's the whole page — you made it to the end, so proud of you 🫶 This was Version 1.0.1, dated Fri Mar 27 2026, and it's wayland::server::data_offer_t(3) in case you need to find it again. mwah 💖🎀🦋

📦 where this page comes from