Struct WlDataOffer 

pub struct WlDataOffer { /* private fields */ }

A wl_data_offer object.

See the documentation of the module for the interface description.

Implementations

impl WlDataOffer

pub fn set_handler(&self, handler: impl WlDataOfferHandler)

Sets a new handler.

pub fn set_boxed_handler(&self, handler: Box<dyn WlDataOfferHandler>)

Sets a new, already boxed handler.

impl WlDataOffer

pub const MSG__ACCEPT__SINCE: u32 = 1u32

Since when the accept message is available.

pub const MSG__RECEIVE__SINCE: u32 = 1u32

Since when the receive message is available.

pub const MSG__DESTROY__SINCE: u32 = 1u32

Since when the destroy message is available.

pub const MSG__OFFER__SINCE: u32 = 1u32

Since when the offer message is available.

pub const MSG__FINISH__SINCE: u32 = 3u32

Since when the finish message is available.

pub const MSG__SET_ACTIONS__SINCE: u32 = 3u32

Since when the set_actions message is available.

pub const MSG__SOURCE_ACTIONS__SINCE: u32 = 3u32

Since when the source_actions message is available.

pub const MSG__ACTION__SINCE: u32 = 3u32

Since when the action message is available.

pub fn try_send_accept( &self, serial: u32, mime_type: Option<&str>, ) -> Result<(), ObjectError>

accept one of the offered mime types

Indicate that the client can accept the given mime type, or NULL for not accepted.

For objects of version 2 or older, this request is used by the client to give feedback whether the client can receive the given mime type, or NULL if none is accepted; the feedback does not determine whether the drag-and-drop operation succeeds or not.

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 will be cancelled and the corresponding drag source will receive wl_data_source.cancelled. Clients may still use this event in conjunction with wl_data_source.action for feedback.

Arguments

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

pub fn send_accept(&self, serial: u32, mime_type: Option<&str>)

accept one of the offered mime types

Indicate that the client can accept the given mime type, or NULL for not accepted.

For objects of version 2 or older, this request is used by the client to give feedback whether the client can receive the given mime type, or NULL if none is accepted; the feedback does not determine whether the drag-and-drop operation succeeds or not.

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 will be cancelled and the corresponding drag source will receive wl_data_source.cancelled. Clients may still use this event in conjunction with wl_data_source.action for feedback.

Arguments

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

pub fn try_send_receive( &self, mime_type: &str, fd: &Rc<OwnedFd>, ) -> Result<(), ObjectError>

request that the data is transferred

To transfer the offered data, the client issues this request and indicates the 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 mime type representation requested 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.

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 determine acceptance.

Arguments

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

pub fn send_receive(&self, mime_type: &str, fd: &Rc<OwnedFd>)

request that the data is transferred

To transfer the offered data, the client issues this request and indicates the 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 mime type representation requested 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.

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 determine acceptance.

Arguments

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

pub fn try_send_destroy(&self) -> Result<(), ObjectError>

destroy data offer

Destroy the data offer.

pub fn send_destroy(&self)

destroy data offer

Destroy the data offer.

pub fn try_send_offer(&self, mime_type: &str) -> Result<(), ObjectError>

advertise offered mime type

Sent immediately after creating the wl_data_offer object. One event per offered mime type.

Arguments

• mime_type: offered mime type

pub fn send_offer(&self, mime_type: &str)

advertise offered mime type

Sent immediately after creating the wl_data_offer object. One event per offered mime type.

Arguments

• mime_type: offered mime type

pub fn try_send_finish(&self) -> Result<(), ObjectError>

the offer will no longer be used

Notifies the compositor that the drag destination successfully finished the drag-and-drop operation.

Upon receiving this request, the compositor will emit wl_data_source.dnd_finished on the drag source client.

It is a client error to perform other requests than wl_data_offer.destroy after this one. It is also an error to perform this request after a NULL mime type has been set in wl_data_offer.accept or no action was received through wl_data_offer.action.

If wl_data_offer.finish request is received for a non drag and drop operation, the invalid_finish protocol error is raised.

pub fn send_finish(&self)

the offer will no longer be used

Notifies the compositor that the drag destination successfully finished the drag-and-drop operation.

Upon receiving this request, the compositor will emit wl_data_source.dnd_finished on the drag source client.

It is a client error to perform other requests than wl_data_offer.destroy after this one. It is also an error to perform this request after a NULL mime type has been set in wl_data_offer.accept or no action was received through wl_data_offer.action.

If wl_data_offer.finish request is received for a non drag and drop operation, the invalid_finish protocol error is raised.

pub fn try_send_set_actions( &self, dnd_actions: WlDataDeviceManagerDndAction, preferred_action: WlDataDeviceManagerDndAction, ) -> Result<(), ObjectError>

set the available/preferred drag-and-drop actions

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.

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 will result in a protocol error.

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, in order to convey the action selected by the user. If the preferred action is not in the wl_data_offer.source_actions mask, an error will be raised.

If the “ask” action is dismissed (e.g. user cancellation), the client is expected to perform wl_data_offer.destroy right away.

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

Arguments

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

pub fn send_set_actions( &self, dnd_actions: WlDataDeviceManagerDndAction, preferred_action: WlDataDeviceManagerDndAction, )

set the available/preferred drag-and-drop actions

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.

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 will result in a protocol error.

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, in order to convey the action selected by the user. If the preferred action is not in the wl_data_offer.source_actions mask, an error will be raised.

If the “ask” action is dismissed (e.g. user cancellation), the client is expected to perform wl_data_offer.destroy right away.

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

Arguments

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

pub fn try_send_source_actions( &self, source_actions: WlDataDeviceManagerDndAction, ) -> Result<(), ObjectError>

notify the source-side available actions

This event indicates the actions offered by the data source. It will be sent immediately after creating the wl_data_offer object, or anytime the source side changes its offered actions through wl_data_source.set_actions.

Arguments

• source_actions: actions offered by the data source

pub fn send_source_actions(&self, source_actions: WlDataDeviceManagerDndAction)

notify the source-side available actions

This event indicates the actions offered by the data source. It will be sent immediately after creating the wl_data_offer object, or anytime the source side changes its offered actions through wl_data_source.set_actions.

Arguments

• source_actions: actions offered by the data source

pub fn try_send_action( &self, dnd_action: WlDataDeviceManagerDndAction, ) -> Result<(), ObjectError>

notify the selected action

This event indicates the action selected by the compositor after matching the source/destination side actions. Only one action (or none) will be offered here.

This event can be emitted multiple times during the drag-and-drop operation in response to destination side action changes through wl_data_offer.set_actions.

This event will no longer be emitted after wl_data_device.drop happened on the drag-and-drop destination, the client must honor the last action received, or the last preferred one set through wl_data_offer.set_actions when handling an “ask” action.

Compositors may also change the selected action on the fly, mainly in response to keyboard modifier changes during the drag-and-drop operation.

The most recent action received is always the valid one. Prior to receiving wl_data_device.drop, the chosen action may change (e.g. due to keyboard modifiers being pressed). At the time of receiving wl_data_device.drop the drag-and-drop destination must honor the last action received.

Action changes may still happen after wl_data_device.drop, especially on “ask” actions, where the drag-and-drop destination may choose another action afterwards. Action changes happening at this stage are always the result of inter-client negotiation, the compositor shall no longer be able to induce a different action.

Upon “ask” actions, it is expected that the drag-and-drop destination may potentially choose a different action and/or mime type, based on wl_data_offer.source_actions and finally chosen by the user (e.g. 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.

Arguments

• dnd_action: action selected by the compositor

pub fn send_action(&self, dnd_action: WlDataDeviceManagerDndAction)

notify the selected action

This event indicates the action selected by the compositor after matching the source/destination side actions. Only one action (or none) will be offered here.

This event can be emitted multiple times during the drag-and-drop operation in response to destination side action changes through wl_data_offer.set_actions.

This event will no longer be emitted after wl_data_device.drop happened on the drag-and-drop destination, the client must honor the last action received, or the last preferred one set through wl_data_offer.set_actions when handling an “ask” action.

Compositors may also change the selected action on the fly, mainly in response to keyboard modifier changes during the drag-and-drop operation.

The most recent action received is always the valid one. Prior to receiving wl_data_device.drop, the chosen action may change (e.g. due to keyboard modifiers being pressed). At the time of receiving wl_data_device.drop the drag-and-drop destination must honor the last action received.

Action changes may still happen after wl_data_device.drop, especially on “ask” actions, where the drag-and-drop destination may choose another action afterwards. Action changes happening at this stage are always the result of inter-client negotiation, the compositor shall no longer be able to induce a different action.

Upon “ask” actions, it is expected that the drag-and-drop destination may potentially choose a different action and/or mime type, based on wl_data_offer.source_actions and finally chosen by the user (e.g. 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.

Arguments

• dnd_action: action selected by the compositor

impl WlDataOffer

pub const ENM__ERROR_INVALID_FINISH__SINCE: u32 = 1u32

Since when the error.invalid_finish enum variant is available.

pub const ENM__ERROR_INVALID_ACTION_MASK__SINCE: u32 = 1u32

Since when the error.invalid_action_mask enum variant is available.

pub const ENM__ERROR_INVALID_ACTION__SINCE: u32 = 1u32

Since when the error.invalid_action enum variant is available.

pub const ENM__ERROR_INVALID_OFFER__SINCE: u32 = 1u32

Since when the error.invalid_offer enum variant is available.

Trait Implementations

impl ConcreteObject for WlDataOffer

const XML_VERSION: u32 = 3u32

The interface version from the XML file that the interface was generated from.

const INTERFACE: ObjectInterface = ObjectInterface::WlDataOffer

The interface of the object.

const INTERFACE_NAME: &str = "wl_data_offer"

The interface of the object as a string.

impl Debug for WlDataOffer

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Object for WlDataOffer

fn core(&self) -> &ObjectCore

Returns the ObjectCore of this object.

fn unset_handler(&self)

Unsets the handler of this object.

fn get_handler_any_ref( &self, ) -> Result<HandlerRef<'_, dyn Any>, HandlerAccessError>

Returns a shared reference to the handler.

fn get_handler_any_mut( &self, ) -> Result<HandlerMut<'_, dyn Any>, HandlerAccessError>

Returns a mutable reference to the handler.