Put smithay's docs through a spell checker.

I noticed quite a few spelling errors, so I fixed a whole bunch of them.
This commit is contained in:
i509VCB 2021-07-24 18:31:25 -05:00 committed by Victor Berger
parent 5524f1f6bd
commit 7e4eff529e
35 changed files with 77 additions and 77 deletions

View File

@ -5,7 +5,7 @@
//! underlying resources are freed.
//!
//! If you want to hold on to a potentially alive dmabuf without blocking the free up
//! of the underlying resouces, you may `downgrade` a `Dmabuf` reference to a `WeakDmabuf`.
//! of the underlying resources, you may `downgrade` a `Dmabuf` reference to a `WeakDmabuf`.
//!
//! This can be especially useful in resources where other parts of the stack should decide upon
//! the lifetime of the buffer. E.g. when you are only caching associated resources for a dmabuf.
@ -125,7 +125,7 @@ pub struct DmabufBuilder {
}
impl DmabufBuilder {
/// Add a plane to the construted Dmabuf
/// Add a plane to the constructed Dmabuf
///
/// *Note*: Each Dmabuf needs at least one plane.
/// MAX_PLANES notes the maximum amount of planes any format may use with this implementation.
@ -158,7 +158,7 @@ impl DmabufBuilder {
}
impl Dmabuf {
/// Create a new Dmabuf by intializing with values from an existing buffer
/// Create a new Dmabuf by initializing with values from an existing buffer
///
// Note: the `src` Buffer is only used a reference for size and format.
// The contents are determined by the provided file descriptors, which

View File

@ -146,7 +146,7 @@ where
/// Change the dimensions of newly returned buffers.
///
/// Already optained buffers are unaffected and will be cleaned up on drop.
/// Already obtained buffers are unaffected and will be cleaned up on drop.
pub fn resize(&mut self, width: u32, height: u32) {
if self.width == width && self.height == height {
return;

View File

@ -212,7 +212,7 @@ impl<A: AsRawFd + 'static> DrmDevice<A> {
///
/// - [`crtcs`](drm::control::crtc) represent scanout engines of the device pointing to one framebuffer. \
/// Their responsibility is to read the data of the framebuffer and export it into an "Encoder". \
/// The number of crtc's represent the number of independant output devices the hardware may handle.
/// The number of crtc's represent the number of independent output devices the hardware may handle.
/// - [`mode`](drm::control::Mode) describes the resolution and rate of images produced by the crtc and \
/// has to be compatible with the provided `connectors`.
/// - [`connectors`](drm::control::connector) - List of connectors driven by the crtc. At least one(!) connector needs to be \
@ -304,9 +304,9 @@ impl<A: AsRawFd> DevPath for A {
/// Events that can be generated by a DrmDevice
#[derive(Debug)]
pub enum DrmEvent {
/// A vblank blank event on the provided crtc has happend
/// A vblank blank event on the provided crtc has happened
VBlank(crtc::Handle),
/// An error happend while processing events
/// An error happened while processing events
Error(Error),
}

View File

@ -60,7 +60,7 @@
//! It just provides a way to create framebuffers from various buffer types (mainly `DumbBuffer`s and hardware-backed gbm `BufferObject`s).
//!
//! Buffer management and details about the various types can be found in the [`allocator`-Module](crate::backend::allocator) and
//! renderering abstractions, which can target these buffers can be found in the [`renderer`-Module](crate::backend::renderer).
//! rendering abstractions, which can target these buffers can be found in the [`renderer`-Module](crate::backend::renderer).
pub(crate) mod device;
pub(self) mod error;

View File

@ -40,7 +40,7 @@ where
/// Create a new `GbmBufferedSurface` from a given compatible combination
/// of a surface, an allocator and renderer formats.
///
/// To sucessfully call this function, you need to have a renderer,
/// To successfully call this function, you need to have a renderer,
/// which can render into a Dmabuf, and a gbm allocator that can produce
/// buffers of a supported format for rendering.
#[allow(clippy::type_complexity)]

View File

@ -292,7 +292,7 @@ pub struct PixelFormatRequirements {
pub color_bits: Option<u8>,
/// If `true`, the color buffer must be in a floating point format. Default is `false`.
///
/// Using floating points allows you to write values outside of the `[0.0, 1.0]` range.
/// Using floating points allows you to write values outside the `[0.0, 1.0]` range.
pub float_color_buffer: bool,
/// Minimum number of bits for the alpha in the color buffer. `None` means "don't care". The default is `None`.
pub alpha_bits: Option<u8>,

View File

@ -7,7 +7,7 @@
//! - Import/Export external resources to/from OpenGL
//!
//! To use this module, you first need to create a [`EGLDisplay`] through a supported EGL platform
//! as inidicated by an implementation of the `native::EGLNativeDisplay` trait.
//! as indicated by an implementation of the `native::EGLNativeDisplay` trait.
//!
//! You may bind the [`EGLDisplay`], that shall be used by clients for rendering (so pick one initialized by a fast platform)
//! to the [`wayland_server::Display`] of your compositor. Note only one backend may be bound to any [`Display`](wayland_server::Display) at any time.
@ -20,7 +20,7 @@
//! it may also be used to initialize an [`EGLSurface`], which can be [bound](crate::backend::renderer::Bind) to some renderers.
//!
//! Alternatively you may import [`dmabuf`](crate::backend::allocator::dmabuf)s using the display, which result
//! in an [`EGLImage`], which can be rendered into by OpenGL. This is perferrable to using surfaces as the dmabuf can be
//! in an [`EGLImage`], which can be rendered into by OpenGL. This is preferable to using surfaces as the dmabuf can be
//! passed around freely making resource-management and more complex use-cases like Multi-GPU rendering easier to manage.
//! Renderers based on EGL may support doing this for you by allowing you to [`Bind`](crate::backend::renderer::Bind) a dmabuf directly.
//!

View File

@ -79,7 +79,7 @@ impl<'a> EGLPlatform<'a> {
///
/// * `platform` - The platform defined in `ffi::egl::`
/// * `platform_name` - A human readable representation of the platform
/// * `native_display` - The native display raw pointer which can be casted to `*mut c_void`
/// * `native_display` - The native display raw pointer which can be cast to `*mut c_void`
/// * `attrib_list` - A list of `ffi::EGLint` like defined in the EGL Extension
/// * `required_extensions` - The names of the required EGL Extensions for this platform
///
@ -185,7 +185,7 @@ pub unsafe trait EGLNativeSurface: Send + Sync {
/// Will be called to check if any internal resources will need
/// to be recreated. Old resources must be used until `create`
/// was called again and a new surface was optained.
/// was called again and a new surface was obtained.
///
/// Only needs to be recreated, if this may return true.
/// The default implementation always returns false.

View File

@ -455,7 +455,7 @@ impl<B: InputBackend> TouchUpEvent<B> for UnusedEvent {
}
}
/// Trait for touch events cancelling the chain
/// Trait for touch events canceling the chain
pub trait TouchCancelEvent<B: InputBackend>: Event<B> {
/// [`TouchSlot`], if the device has multi-touch capabilities
fn slot(&self) -> Option<TouchSlot>;
@ -497,7 +497,7 @@ pub trait InputBackend: Sized {
type TouchUpEvent: TouchUpEvent<Self>;
/// Type representing touch events from moving
type TouchMotionEvent: TouchMotionEvent<Self>;
/// Type representing cancelling of touch events
/// Type representing canceling of touch events
type TouchCancelEvent: TouchCancelEvent<Self>;
/// Type representing touch frame events
type TouchFrameEvent: TouchFrameEvent<Self>;
@ -532,17 +532,17 @@ pub enum InputEvent<B: InputBackend> {
/// The removed device
device: B::Device,
},
/// A keyboard event occured
/// A keyboard event occurred
Keyboard {
/// The keyboard event
event: B::KeyboardKeyEvent,
},
/// A relative pointer motion occured
/// A relative pointer motion occurred
PointerMotion {
/// The pointer motion event
event: B::PointerMotionEvent,
},
/// An absolute pointer motion occures
/// An absolute pointer motion occurs
PointerMotionAbsolute {
/// The absolute pointer motion event
event: B::PointerMotionAbsoluteEvent,
@ -552,7 +552,7 @@ pub enum InputEvent<B: InputBackend> {
/// The pointer button event
event: B::PointerButtonEvent,
},
/// A pointer axis was actionned
/// A pointer action occurred while scrolling on an axis
PointerAxis {
/// The pointer axis event
event: B::PointerAxisEvent,
@ -577,7 +577,7 @@ pub enum InputEvent<B: InputBackend> {
/// The touch cancel event
event: B::TouchCancelEvent,
},
/// A touch frame was emmited
/// A touch frame was emitted
///
/// A set of two events received on the same seat between two frames should
/// be interpreted as an atomic event.
@ -586,19 +586,19 @@ pub enum InputEvent<B: InputBackend> {
event: B::TouchFrameEvent,
},
/// A tablet tool axis was emited
/// A tablet tool axis was emitted
TabletToolAxis {
/// The tablet tool axis event
event: B::TabletToolAxisEvent,
},
/// A tablet tool proximity was emited
/// A tablet tool proximity was emitted
TabletToolProximity {
/// The tablet tool proximity event
event: B::TabletToolProximityEvent,
},
/// A tablet tool tip event was emited
/// A tablet tool tip event was emitted
TabletToolTip {
/// The tablet tool axis event
event: B::TabletToolTipEvent,

View File

@ -16,7 +16,7 @@ pub struct TabletToolDescriptor {
pub capabilitys: TabletToolCapabilitys,
}
/// Describes the physical type of a tool. The physical type of a tool generally defines its base usage.
/// Describes the physical type of tool. The physical type of tool generally defines its base usage.
#[derive(Debug, Clone, Copy, Hash, Eq, PartialEq)]
pub enum TabletToolType {
/// A generic pen.

View File

@ -9,9 +9,9 @@
//!
//! ### Session management
//!
//! Session management relates to mechanisms allowing the compositor to access the ressources
//! Session management relates to mechanisms allowing the compositor to access the resources
//! it needs to function. It contains interaction with the login manager if any ((e)logind or
//! seatd), as well as releasing thoses ressources when TTY-switching. It is handled by the
//! seatd), as well as releasing those resources when TTY-switching. It is handled by the
//! [`session`] module, gated by the `backend_session` cargo feature. You will generally need
//! it to run your compositor directly on a TTY.
//!

View File

@ -163,7 +163,7 @@ pub trait Frame {
/// If called outside this operation may error-out, do nothing or modify future rendering results in any way.
fn clear(&mut self, color: [f32; 4]) -> Result<(), Self::Error>;
/// Render a texture to the current target using given projection matrix and alpha.
/// The given verticies are used to source the texture. This is mostly useful for cropping the texture.
/// The given vertices are used to source the texture. This is mostly useful for cropping the texture.
fn render_texture(
&mut self,
texture: &Self::TextureId,
@ -257,7 +257,7 @@ pub trait Renderer {
/// Initialize a rendering context on the current rendering target with given dimensions and transformation.
///
/// This function *may* error, if:
/// - The given dimensions are unsuppored (too large) for this renderer
/// - The given dimensions are unsupported (too large) for this renderer
/// - The given Transformation is not supported by the renderer (`Transform::Normal` is always supported).
/// - This renderer implements `Bind`, no target was bound *and* has no default target.
/// - (Renderers not implementing `Bind` always have a default target.)

View File

@ -13,7 +13,7 @@
//!
//! The session may be used to open devices manually through the [`Session`] interface
//! or be passed to other objects that need it to open devices themselves.
//! The [`AutoSession`] is clonable
//! The [`AutoSession`] is cloneable
//! and may be passed to multiple devices easily.
//!
//! Examples for those are e.g. the [`LibinputInputBackend`](crate::backend::libinput::LibinputInputBackend)

View File

@ -14,7 +14,7 @@
//! Session handling in Smithay is done through a pair of types that each session provider implements.
//!
//! The first is a handle implementing the [`Session`] trait, which allows you to request the opening
//! of devices, a VT change, or informations about the session state.
//! of devices, a VT change, or information about the session state.
//!
//! The second is a notifier which informs you when the session is enabled or disabled by the system.
//! This notifier takes the form of a [`calloop`] event source, but it does not generates any event

View File

@ -644,7 +644,7 @@ impl InputBackend for WinitInputBackend {
/// Processes new events of the underlying event loop and calls the provided callback.
///
/// You need to periodically call this function to keep the underlying event loop and
/// [`WinitWindow`] active. Otherwise the window may no respond to user interaction.
/// [`WinitWindow`] active. Otherwise the window may not respond to user interaction.
///
/// Returns an error if the [`WinitWindow`] the window has been closed. Calling
/// `dispatch_new_events` again after the [`WinitWindow`] has been closed is considered an

View File

@ -31,7 +31,7 @@
//! as `Rc` and `Arc` and the synchronization they require, [`calloop`] allows you to provide a mutable
//! reference to a value, that will be passed down to most callbacks (possibly under the form of a
//! [`DispatchData`](::wayland_server::DispatchData) for wayland-related callbacks). This structure provides
//! an easy access to a centralized mutable state without synchronization (as the callback invocation is
//! easy access to a centralized mutable state without synchronization (as the callback invocation is
//! *always* sequential), and is the recommended way to of structuring your compositor.
//!
//! Several objects, in particular on the wayland clients side, can exist as multiple instances where each

View File

@ -3,7 +3,7 @@
//! This mechanism allows inter-module communication, by letting your modules
//! register callbacks to listen for events generated by other modules. This
//! signaling mechanism is synchronous and non-thread safe. If you need
//! ascynchronous threadsafe communication, instead consider relying on channels.
//! asynchronous thread safe communication, instead consider relying on channels.
//!
//! The whole mechanism is built on the [`Signaler`] type.
//! It serves both as a message sending facility and a way to register new callbacks

View File

@ -32,7 +32,7 @@ use downcast_rs::{impl_downcast, Downcast};
use crate::wayland::Serial;
/// Trait represening a value that can be used in double-buffered storage
/// Trait representing a value that can be used in double-buffered storage
///
/// The type needs to implement the [`Default`] trait, which will be used
/// to initialize. You further need to provide two methods:
@ -46,14 +46,14 @@ use crate::wayland::Serial;
/// current state.
///
/// In most cases, this method will simply produce a copy of the pending state,
/// but you might need additionnal logic in some cases, such as for handling
/// but you might need additional logic in some cases, such as for handling
/// non-cloneable resources (which thus need to be moved into the produce value).
///
/// Then at some point the [`Cacheable::merge_into`] method of your type will be
/// invoked. In this method, `self` acts as the update that should be merged into
/// the current state provided as argument. In simple cases, the action would just
/// be to copy `self` into the current state, but mre complex cases require
/// additionnal logic.
/// be to copy `self` into the current state, but more complex cases require
/// additional logic.
pub trait Cacheable: Default {
/// Produce a new state to be cached from the pending state
fn commit(&mut self) -> Self;
@ -117,7 +117,7 @@ impl<T: Cacheable + 'static> Cache for RefCell<CachedState<T>> {
/// A typemap-like container for double-buffered values
///
/// All values inserted into this container must implement the [`Cacheable`] trait,
/// which defines their buffering semantics. They futhermore must be `Send` as the surface state
/// which defines their buffering semantics. They furthermore must be `Send` as the surface state
/// can be accessed from multiple threads (but `Sync` is not required, the surface internally synchronizes
/// access to its state).
///
@ -130,7 +130,7 @@ impl<T: Cacheable + 'static> Cache for RefCell<CachedState<T>> {
/// stored.
///
/// This contained has [`RefCell`]-like semantics: values of multiple stored types can be accessed at the
/// same time. The stored values are initialized lazyly the first time `current()` or `pending()` are
/// same time. The stored values are initialized lazily the first time `current()` or `pending()` are
/// invoked with this type as argument.
pub struct MultiCache {
caches: appendlist::AppendList<Box<dyn Cache + Send>>,
@ -164,7 +164,7 @@ impl MultiCache {
.unwrap()
}
/// Acces the pending state associated with type `T`
/// Access the pending state associated with type `T`
pub fn pending<T: Cacheable + Send + 'static>(&self) -> RefMut<'_, T> {
RefMut::map(self.find_or_insert::<T>().borrow_mut(), |cs| &mut cs.pending)
}

View File

@ -8,7 +8,7 @@
//! ## Why use this implementation
//!
//! This implementation does a simple job: it stores in a coherent way the state of
//! surface trees with subsurfaces, to provide you a direct access to the tree
//! surface trees with subsurfaces, to provide you direct access to the tree
//! structure and all surface attributes, and handles the application of double-buffered
//! state.
//!
@ -17,7 +17,7 @@
//! need to display the subsurface tree.
//!
//! This implementation will not do anything more than present you the metadata specified by the
//! client in a coherent and practical way. All the logic regarding to drawing itself, and
//! client in a coherent and practical way. All the logic regarding drawing itself, and
//! the positioning of windows (surface trees) one relative to another is out of its scope.
//!
//! ## How to use it

View File

@ -185,7 +185,7 @@ pub(crate) struct Transaction {
}
impl Transaction {
/// Computes the global state of the transaction wrt its blockers
/// Computes the global state of the transaction with regard to its blockers
///
/// The logic is:
///

View File

@ -52,7 +52,7 @@ pub enum Location {
After,
}
/// Possible actions to do after handling a node diring tree traversal
/// Possible actions to do after handling a node during tree traversal
#[derive(Debug)]
pub enum TraversalAction<T> {
/// Traverse its children as well, providing them the data T

View File

@ -15,7 +15,7 @@
//! Using these two functions is enough for your clients to be able to interact with each other using
//! the data devices.
//!
//! The module also provides additionnal mechanisms allowing your compositor to see and interact with
//! The module also provides additional mechanisms allowing your compositor to see and interact with
//! the contents of the data device:
//!
//! - You can provide a callback closure to [`init_data_device`]
@ -83,7 +83,7 @@ pub enum DataDeviceEvent {
/// The data source provided by the client
///
/// If it is `None`, this means the DnD is restricted to surfaces of the
/// same client and the client will manage data transfert by itself.
/// same client and the client will manage data transfer by itself.
source: Option<wl_data_source::WlDataSource>,
/// The icon the client requested to be used to be associated with the cursor icon
/// during the drag'n'drop.
@ -93,7 +93,7 @@ pub enum DataDeviceEvent {
///
/// At this point, any pointer icon should be removed.
///
/// Note that this event will only be genrated for client-initiated drag'n'drop session.
/// Note that this event will only be generated for client-initiated drag'n'drop session.
DnDDropped,
/// A client requested to read the server-set selection
SendSelection {
@ -327,7 +327,7 @@ pub fn set_data_device_selection(seat: &Seat, mime_types: Vec<String>) {
}));
}
/// Start a drag'n'drop from a ressource controlled by the compositor
/// Start a drag'n'drop from a resource controlled by the compositor
///
/// You'll receive events generated by the interaction of clients with your
/// drag'n'drop in the provided callback. See [`ServerDndEvent`] for details about

View File

@ -22,7 +22,7 @@ pub enum ServerDndEvent {
Action(DndAction),
/// The DnD resource was dropped by the user
///
/// After that, the client can still interract with your ressource
/// After that, the client can still interact with your resource
Dropped,
/// The Dnd was cancelled
///

View File

@ -82,11 +82,11 @@ impl ExplicitBufferRelease {
/// An explicit synchronization state
///
/// The client is not required to fill both. `acquire` being `None` means that you don't need to wait
/// before acessing the buffer, `release` being `None` means that the client does not require additionnal
/// before accessing the buffer, `release` being `None` means that the client does not require additional
/// signaling that you are finished (you still need to send `wl_buffer.release`).
///
/// When processing the current state, the whould [`Option::take`] the values from it. Otherwise they'll
/// be treated as unused and released when overwritten by the next client commit.
/// When processing the current state, [`Option::take`] the values from it. Otherwise they'll be
/// treated as unused and released when overwritten by the next client commit.
#[derive(Debug)]
pub struct ExplicitSyncState {
/// An acquire `dma_fence` object, that you should wait on before accessing the contents of the

View File

@ -16,7 +16,7 @@
//!
//! Some of these modules require you to provide a callback that is invoked for some
//! client requests that your logic needs to handle. In most cases these callback
//! are given as input an enum specifying the event that occured, as well as the
//! are given as input an enum specifying the event that occurred, as well as the
//! [`DispatchData`](wayland_server::DispatchData) from `wayland_server`.
//!
//! ## Provided helpers
@ -28,7 +28,7 @@
//! Following this, the [`shell`] module contains the logic allowing clients to use their
//! surface to build concrete windows with the usual interactions. Different kind of shells
//! exist, but in general you will want to support at least the [`xdg`](shell::xdg) variant,
//! which is the standart used by most applications.
//! which is the standard used by most applications.
//!
//! Then, the [`seat`] module contains logic related to input handling. These helpers are used
//! to forward input (such as pointer action or keystrokes) to clients, and manage the input
@ -38,7 +38,7 @@
//! The [`shm`] module provides the necessary logic for client to provide buffers defining the
//! contents of their windows using shared memory. This is the main mechanism used by clients
//! that are not hardware accelerated. As a complement, the [`dmabuf`] module provides support
//! hardware-accelerated clients; it is tighly linked to the
//! hardware-accelerated clients; it is tightly linked to the
//! [`backend::allocator`](crate::backend::allocator) module.
//!
//! The [`output`] module helps forwarding to clients information about the display monitors that

View File

@ -1,6 +1,6 @@
//! XDG Output advertising capabilities
//!
//! This protocol is ment for describing outputs in a way
//! This protocol is meant for describing outputs in a way
//! which is more in line with the concept of an output on desktop oriented systems.
use std::{

View File

@ -162,7 +162,7 @@ impl Seat {
.map(|arc| Seat { arc })
}
/// Acces the `UserDataMap` associated with this `Seat`
/// Access the `UserDataMap` associated with this `Seat`
pub fn user_data(&self) -> &UserDataMap {
&self.arc.user_data
}

View File

@ -161,7 +161,7 @@ impl PointerHandle {
self.inner.borrow_mut().grab = GrabStatus::Active(serial, Box::new(grab));
}
/// Remove any current grab on this pointer, reseting it to the default behavior
/// Remove any current grab on this pointer, resetting it to the default behavior
pub fn unset_grab(&self) {
self.inner.borrow_mut().grab = GrabStatus::None;
}

View File

@ -4,7 +4,7 @@
//! as a global handler for `wl_shell`. This protocol is deprecated in favor of `xdg_shell`,
//! thus this module is provided as a compatibility layer with older clients. As a consequence,
//! you can as a compositor-writer decide to only support its functionality in a best-effort
//! maneer: as this global is part of the core protocol, you are still required to provide
//! manner: as this global is part of the core protocol, you are still required to provide
//! some support for it.
//!
//! ## Why use this implementation
@ -159,7 +159,7 @@ pub enum ShellSurfaceKind {
parent: wl_surface::WlSurface,
/// Location relative to the parent
location: Point<i32, Logical>,
/// Wether this window should be marked as inactive
/// Weather this window should be marked as inactive
inactive: bool,
},
/// Fullscreen surface, covering an entire output
@ -181,7 +181,7 @@ pub enum ShellSurfaceKind {
/// The serial of the input event triggering the creation of this
/// popup
serial: Serial,
/// Wether this popup should be marked as inactive
/// Weather this popup should be marked as inactive
inactive: bool,
/// Location of the popup relative to its parent
location: Point<i32, Logical>,

View File

@ -183,11 +183,11 @@ xdg_role!(
///
/// Unmapping an xdg_toplevel means that the surface cannot be shown
/// by the compositor until it is explicitly mapped again.
/// All active operations (e.g., move, resize) are canceled and all
/// All active operations (e.g., move, resize) are cancelled and all
/// attributes (e.g. title, state, stacking, ...) are discarded for
/// an xdg_toplevel surface when it is unmapped. The xdg_toplevel returns to
/// the state it had right after xdg_surface.get_toplevel. The client
/// can re-map the toplevel by perfoming a commit without any buffer
/// can re-map the toplevel by performing a commit without any buffer
/// attached, waiting for a configure event and handling it as usual (see
/// xdg_surface description).
///

View File

@ -46,9 +46,9 @@ pub use tablet::{TabletDescriptor, TabletHandle};
pub use tablet_seat::TabletSeatHandle;
pub use tablet_tool::TabletToolHandle;
/// Extends [Seat] with graphic tablet specyfic functionality
/// Extends [Seat] with graphic tablet specific functionality
pub trait TabletSeatTrait {
/// Get tablet seat asosiated with this seat
/// Get tablet seat associated with this seat
fn tablet_seat(&self) -> TabletSeatHandle;
}

View File

@ -41,7 +41,7 @@ impl fmt::Debug for TabletSeat {
/// Handle to a tablet seat
///
/// TabletSeat extends `Seat` with graphic tablet specyfic functionality
/// TabletSeat extends `Seat` with graphic tablet specific functionality
///
/// TabletSeatHandle can be used to advertise available graphics tablets and tools to wayland clients
#[derive(Default, Debug, Clone)]
@ -92,7 +92,7 @@ impl TabletSeatHandle {
/// You can either add tablet on [input::Event::DeviceAdded](crate::backend::input::InputEvent::DeviceAdded) event,
/// or you can add tablet based on tool event, then clients will not know about devices that are not being used
///
/// Returns new [TabletHandle] if tablet was not know by this seat, if tablet was allready know it returns exsisting handle.
/// Returns new [TabletHandle] if tablet was not know by this seat, if tablet was already know it returns existing handle.
pub fn add_tablet(&self, tablet_desc: &TabletDescriptor) -> TabletHandle {
let inner = &mut *self.inner.borrow_mut();
@ -123,7 +123,7 @@ impl TabletSeatHandle {
/// Remove tablet device
///
/// Called when tablet is no longer avalible
/// Called when tablet is no longer available
/// For example on [input::Event::DeviceRemoved](crate::backend::input::InputEvent::DeviceRemoved) event.
pub fn remove_tablet(&self, tablet_desc: &TabletDescriptor) {
self.inner.borrow_mut().tablets.remove(tablet_desc);
@ -138,7 +138,7 @@ impl TabletSeatHandle {
///
/// Tool is usually added on [TabletToolProximityEvent](crate::backend::input::InputEvent::TabletToolProximity) event.
///
/// Returns new [TabletToolHandle] if tool was not know by this seat, if tool was allready know it returns exsisting handle,
/// Returns new [TabletToolHandle] if tool was not know by this seat, if tool was already know it returns existing handle,
/// it allows you to send tool input events to clients.
pub fn add_tool(&self, tool_desc: &TabletToolDescriptor) -> TabletToolHandle {
let inner = &mut *self.inner.borrow_mut();
@ -177,7 +177,7 @@ impl TabletSeatHandle {
///
/// Policy of tool removal is a compositor-specific.
///
/// One posible policy would be to remove a tool when all tablets the tool was used on are removed.
/// One possible policy would be to remove a tool when all tablets the tool was used on are removed.
pub fn remove_tool(&self, tool_desc: &TabletToolDescriptor) {
self.inner.borrow_mut().tools.remove(tool_desc);
}

View File

@ -350,7 +350,7 @@ impl TabletToolHandle {
}
}
/// Notifify that this tool is focused on a certain surface.
/// Notify that this tool is focused on a certain surface.
///
/// You provide the location of the tool, in the form of:
///
@ -370,7 +370,7 @@ impl TabletToolHandle {
.proximity_in(pos, focus, tablet, serial, time)
}
/// Notifify that this tool has left proximity.
/// Notify that this tool has left proximity.
pub fn proximity_out(&self, time: u32) {
self.inner.borrow_mut().proximity_out(time);
}

View File

@ -111,7 +111,7 @@ impl Drop for X11Lock {
/// Open the two unix sockets an X server listens on
///
/// Should only be done after the associated lockfile is aquired!
/// Should only be done after the associated lockfile is acquired!
fn open_x11_sockets_for_display(display: u32) -> NixResult<[UnixStream; 2]> {
let path = format!("/tmp/.X11-unix/X{}", display);
let _ = ::std::fs::remove_file(&path);

View File

@ -76,7 +76,7 @@ pub struct XWayland<Data> {
/// This is a very low-level interface, only notifying you when the connection
/// with XWayland is up, or when it terminates.
///
/// Your WM code must be able handle the XWayland server connecting then
/// Your WM code must be able to handle the XWayland server connecting then
/// disconnecting several time in a row, but only a single connection will
/// be active at any given time.
#[derive(Debug)]