#[non_exhaustive]pub enum Request {
Accept {
serial: u32,
mime_type: Option<String>,
},
Receive {
mime_type: String,
fd: OwnedFd,
},
Destroy,
Finish,
SetActions {
dnd_actions: WEnum<DndAction>,
preferred_action: WEnum<DndAction>,
},
}
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
Accept
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.
Fields
Receive
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.
Destroy
destroy data offer
Destroy the data offer.
This is a destructor, once received this object cannot be used any longer.
Finish
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.
Only available since version 3 of the interface
SetActions
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.
Only available since version 3 of the interface
Implementations§
Trait Implementations§
Auto Trait Implementations§
impl Freeze for Request
impl RefUnwindSafe for Request
impl Send for Request
impl Sync for Request
impl Unpin for Request
impl UnwindSafe for Request
Blanket Implementations§
source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
§impl<T> Downcast for Twhere
T: Any,
impl<T> Downcast for Twhere
T: Any,
§fn into_any(self: Box<T>) -> Box<dyn Any>
fn into_any(self: Box<T>) -> Box<dyn Any>
Box<dyn Trait>
(where Trait: Downcast
) to Box<dyn Any>
. Box<dyn Any>
can
then be further downcast
into Box<ConcreteType>
where ConcreteType
implements Trait
.§fn into_any_rc(self: Rc<T>) -> Rc<dyn Any>
fn into_any_rc(self: Rc<T>) -> Rc<dyn Any>
Rc<Trait>
(where Trait: Downcast
) to Rc<Any>
. Rc<Any>
can then be
further downcast
into Rc<ConcreteType>
where ConcreteType
implements Trait
.§fn as_any(&self) -> &(dyn Any + 'static)
fn as_any(&self) -> &(dyn Any + 'static)
&Trait
(where Trait: Downcast
) to &Any
. This is needed since Rust cannot
generate &Any
’s vtable from &Trait
’s.§fn as_any_mut(&mut self) -> &mut (dyn Any + 'static)
fn as_any_mut(&mut self) -> &mut (dyn Any + 'static)
&mut Trait
(where Trait: Downcast
) to &Any
. This is needed since Rust cannot
generate &mut Any
’s vtable from &mut Trait
’s.