Fix typos (#3899)

CONTRIBUTING.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-`egui` has been an on-and-off weekend project of mine since late 2018. I am grateful to any help I can get, but bare in mind that sometimes I can be slow to respond because I am busy with other things!
+`egui` has been an on-and-off weekend project of mine since late 2018. I am grateful to any help I can get, but bear in mind that sometimes I can be slow to respond because I am busy with other things!
 
 / Emil
 

crates/egui/src/context.rs

@@ -683,7 +683,7 @@ impl Context {
     /// ```
     /// # let mut ctx = egui::Context::default();
     /// ctx.input(|i| {
-    ///     // ⚠️ Using `ctx` (even from other `Arc` reference) again here will lead to a dead-lock!
+    ///     // ⚠️ Using `ctx` (even from other `Arc` reference) again here will lead to a deadlock!
     /// });
     ///
     /// if let Some(pos) = ctx.input(|i| i.pointer.hover_pos()) {
@@ -1339,18 +1339,18 @@ impl Context {
     /// redraws when the app is not in focus. But sometimes the GUI of the app might become stale
     /// and outdated if it is not updated for too long.
     ///
-    /// Lets say, something like a stop watch widget that displays the time in seconds. You would waste
+    /// Let's say, something like a stopwatch widget that displays the time in seconds. You would waste
     /// resources repainting multiple times within the same second (when you have no input),
     /// just calculate the difference of duration between current time and next second change,
     /// and call this function, to make sure that you are displaying the latest updated time, but
     /// not wasting resources on needless repaints within the same second.
     ///
     /// ### Quirk:
-    /// Duration begins at the next frame. lets say for example that its a very inefficient app
+    /// Duration begins at the next frame. Let's say for example that it's a very inefficient app
     /// and takes 500 milliseconds per frame at 2 fps. The widget / user might want a repaint in
     /// next 500 milliseconds. Now, app takes 1000 ms per frame (1 fps) because the backend event
     /// timeout takes 500 milliseconds AFTER the vsync swap buffer.
-    /// So, its not that we are requesting repaint within X duration. We are rather timing out
+    /// So, it's not that we are requesting repaint within X duration. We are rather timing out
     /// during app idle time where we are not receiving any new input events.
     ///
     /// This repaints the specified viewport
@@ -2888,12 +2888,12 @@ impl Context {
 
     /// For integrations: Set this to render a sync viewport.
     ///
-    /// This will only be set the callback for the current thread,
+    /// This will only set the callback for the current thread,
     /// which most likely should be the main thread.
     ///
     /// When an immediate viewport is created with [`Self::show_viewport_immediate`] it will be rendered by this function.
     ///
-    /// When called, the integration need to:
+    /// When called, the integration needs to:
     /// * Check if there already is a window for this viewport id, and if not open one
     /// * Set the window attributes (position, size, …) based on [`ImmediateViewport::builder`].
     /// * Call [`Context::run`] with [`ImmediateViewport::viewport_ui_cb`].
@@ -2931,7 +2931,7 @@ impl Context {
         self.send_viewport_cmd_to(self.viewport_id(), command);
     }
 
-    /// Send a command to a speicfic viewport.
+    /// Send a command to a specific viewport.
     ///
     /// This lets you affect another viewport, e.g. resizing its window.
     pub fn send_viewport_cmd_to(&self, id: ViewportId, command: ViewportCommand) {

crates/egui/src/viewport.rs

@@ -20,7 +20,7 @@
 //! These are created with [`Context::show_viewport_deferred`].
 //! Deferred viewports take a closure that is called by the integration at a later time, perhaps multiple times.
 //! Deferred viewports are repainted independenantly of the parent viewport.
-//! This means communication with them need to done via channels, or `Arc/Mutex`.
+//! This means communication with them needs to be done via channels, or `Arc/Mutex`.
 //!
 //! This is the most performant type of child viewport, though a bit more cumbersome to work with compared to immediate viewports.
 //!
@@ -33,7 +33,7 @@
 //! In short: immediate viewports are simpler to use, but can waste a lot of CPU time.
 //!
 //! ### Embedded viewports
-//! These are not real, independenant viewports, but is a fallback mode for when the integration does not support real viewports. In your callback is called with [`ViewportClass::Embedded`] it means you need to create an [`crate::Window`] to wrap your ui in, which will then be embedded in the parent viewport, unable to escape it.
+//! These are not real, independent viewports, but is a fallback mode for when the integration does not support real viewports. In your callback is called with [`ViewportClass::Embedded`] it means you need to create a [`crate::Window`] to wrap your ui in, which will then be embedded in the parent viewport, unable to escape it.
 //!
 //!
 //! ## Using the viewports
@@ -94,7 +94,7 @@ pub enum ViewportClass {
     ///
     /// This is the easier type of viewport to use, but it is less performant
     /// at it requires both parent and child to repaint if any one of them needs repainting,
-    /// which efficvely produce double work for two viewports, and triple work for three viewports, etc.
+    /// which effectively produces double work for two viewports, and triple work for three viewports, etc.
     ///
     /// Create these with [`crate::Context::show_viewport_immediate`].
     Immediate,
@@ -367,7 +367,7 @@ impl ViewportBuilder {
     /// buffer.
     ///
     /// The default is `false`.
-    /// If this is not working is because the graphic context dozen't support transparency,
+    /// If this is not working, it's because the graphic context doesn't support transparency,
     /// you will need to set the transparency in the eframe!
     #[inline]
     pub fn with_transparent(mut self, transparent: bool) -> Self {
@@ -550,7 +550,7 @@ impl ViewportBuilder {
         self
     }
 
-    /// Control if window i always-on-top, always-on-bottom, or neither.
+    /// Control if window is always-on-top, always-on-bottom, or neither.
     #[inline]
     pub fn with_window_level(mut self, level: WindowLevel) -> Self {
         self.window_level = Some(level);
@@ -574,7 +574,7 @@ impl ViewportBuilder {
     }
 
     /// Update this `ViewportBuilder` with a delta,
-    /// returning a list of commands and a bool intdicating if the window needs to be recreated.
+    /// returning a list of commands and a bool indicating if the window needs to be recreated.
     #[must_use]
     pub fn patch(&mut self, new_vp_builder: Self) -> (Vec<ViewportCommand>, bool) {
         let Self {
@@ -841,7 +841,7 @@ pub enum ViewportCommand {
     /// For other viewports, the [`crate::ViewportInfo::close_requested`] flag will be set.
     Close,
 
-    /// Calcel the closing that was signaled by [`crate::ViewportInfo::close_requested`].
+    /// Cancel the closing that was signaled by [`crate::ViewportInfo::close_requested`].
     CancelClose,
 
     /// Set the window title.
@@ -1004,9 +1004,9 @@ pub struct ViewportOutput {
     /// Commands to change the viewport, e.g. window title and size.
     pub commands: Vec<ViewportCommand>,
 
-    /// Schedulare a repaint of this viewport after this delay.
+    /// Schedule a repaint of this viewport after this delay.
     ///
-    /// It is preferably to instead install a [`Context::set_request_repaint_callback`],
+    /// It is preferable to instead install a [`Context::set_request_repaint_callback`],
     /// but if you haven't, you can use this instead.
     ///
     /// If the duration is zero, schedule a repaint immediately.