Changes and improvements to the documentation (#3253)

* FEATURES.md improvements

* docs improvements

* typo fix: 'mean' -> 'main'

Co-authored-by: daxpedda <daxpedda@gmail.com>

---------

Co-authored-by: daxpedda <daxpedda@gmail.com>

CONTRIBUTING.md

@@ -11,7 +11,7 @@ may be worth creating a separate crate that extends Winit's API to add that func
 When reporting an issue, in order to help the maintainers understand what the problem is, please make
 your description of the issue as detailed as possible:
 
-- if it is a bug, please provide clear explanation of what happens, what should happen, and how to
+- if it is a bug, please provide a clear explanation of what happens, what should happen, and how to
   reproduce the issue, ideally by providing a minimal program exhibiting the problem
 - if it is a feature request, please provide a clear argumentation about why you believe this feature
   should be supported by winit
@@ -21,7 +21,7 @@ your description of the issue as detailed as possible:
 When making a code contribution to winit, before opening your pull request, please make sure that:
 
 - your patch builds with Winit's minimal supported rust version - Rust 1.65.
-- you tested your modifications on all the platforms impacted, or if not possible detail which platforms
+- you tested your modifications on all the platforms impacted, or if not possible, detail which platforms
   were not tested, and what should be tested, so that a maintainer or another contributor can test them
 - you updated any relevant documentation in winit
 - you left comments in your code explaining any part that is not straightforward, so that the
@@ -34,7 +34,7 @@ When making a code contribution to winit, before opening your pull request, plea
   relevant sections in [`FEATURES.md`](https://github.com/rust-windowing/winit/blob/master/FEATURES.md#features)
   should be updated.
 
-Once your PR is open, you can ask for review by a maintainer of your platform. Winit's merging policy
+Once your PR is open, you can ask for a review by a maintainer of your platform. Winit's merging policy
 is that a PR must be approved by at least two maintainers of winit before being merged, including
 at least a maintainer of the platform (a maintainer making a PR themselves counts as approving it).
 
@@ -46,27 +46,26 @@ Once your PR is deemed ready, the merging maintainer will take care of resolving
 
 The current maintainers are listed in the [CODEOWNERS](.github/CODEOWNERS) file.
 
-If you are interested in being pinged when testing is needed for a certain platform, please add yourself to the [Testers and Contributors](https://github.com/rust-windowing/winit/wiki/Testers-and-Contributors) table!
+If you are interested in being pinged when testing is needed for a specific platform, please add yourself to the [Testers and Contributors](https://github.com/rust-windowing/winit/wiki/Testers-and-Contributors) table!
 
 ## Release process
 
-Given that winit is a widely used library we should be able to make a patch
+Given that winit is a widely used library, we should be able to make a patch
 releases at any time we want without blocking the development of new features.
 
-To achieve these goals, a new branch is created for every new release. Releases
+To achieve these goals, a new branch is created for every new release. Releases and later patch releases are committed and tagged in this branch.
-and later patch releases are committed and tagged in this branch.
 
 The exact steps for an exemplary `0.2.0` release might look like this:
-  1. Initially the version on the latest master is `0.1.0`
+  1. Initially, the version on the latest master is `0.1.0`
   2. A new `v0.2.x` branch is created for the release
   3. In the branch, the version is bumped to `v0.2.0`
   4. The new commit in the branch is tagged `v0.2.0`
   5. The version is pushed to crates.io
   6. A GitHub release is created for the `v0.2.0` tag
-  7. On master, the version is bumped to `0.2.0` and the CHANGELOG is updated
+  7. On master, the version is bumped to `0.2.0`, and the CHANGELOG is updated
   
-When doing a patch release the process is similar:
+When doing a patch release, the process is similar:
-  1. Initially the version of the latest release is `0.2.0`
+  1. Initially, the version of the latest release is `0.2.0`
   2. Checkout the `v0.2.x` branch
   3. Cherry-pick the required non-breaking changes into the `v0.2.x`
   4. Follow steps 3-7 of the regular release example

FEATURES.md

@@ -1,6 +1,6 @@
 # Winit Scope
 
-Winit aims to expose an interface that abstracts over window creation and input handling, and can
+Winit aims to expose an interface that abstracts over window creation and input handling and can
 be used to create both games and applications. It supports the following main graphical platforms:
 - Desktop
   - Windows 7+ (10+ is tested regularly)
@@ -45,10 +45,10 @@ be released and the library will enter maintenance mode. For the most part, new
 be added past this point. New platform features may be accepted and exposed through point releases.
 
 ### Tier upgrades
-Some platform features could in theory be exposed across multiple platforms, but have not gone
+Some platform features could, in theory, be exposed across multiple platforms, but have not gone
 through the implementation work necessary to function on all platforms. When one of these features
 gets implemented across all platforms, a PR can be opened to upgrade the feature to a core feature.
-If that gets accepted, the platform-specific functions gets deprecated and become permanently
+If that gets accepted, the platform-specific functions get deprecated and become permanently
 exposed through the core, cross-platform API.
 
 # Features
@@ -88,7 +88,7 @@ If your PR makes notable changes to Winit's features, please update this section
 - **Fullscreen toggle**: The windows created by winit can be switched to and from fullscreen after
   creation.
 - **Exclusive fullscreen**: Winit allows changing the video mode of the monitor
-  for fullscreen windows, and if applicable, captures the monitor for exclusive
+  for fullscreen windows and, if applicable, captures the monitor for exclusive
   use by this application.
 - **HiDPI support**: Winit assists developers in appropriately scaling HiDPI content.
 - **Popup / modal windows**: Windows can be created relative to the client area of other windows, and parent
@@ -105,7 +105,7 @@ If your PR makes notable changes to Winit's features, please update this section
 - **Mouse set location**: Forcibly changing the location of the pointer.
 - **Cursor locking**: Locking the cursor inside the window so it cannot move.
 - **Cursor confining**: Confining the cursor to the window bounds so it cannot leave them.
-- **Cursor icon**: Changing the cursor icon, or hiding the cursor.
+- **Cursor icon**: Changing the cursor icon or hiding the cursor.
 - **Cursor hittest**: Handle or ignore mouse events for a window.
 - **Touch events**: Single-touch events.
 - **Touch pressure**: Touch events contain information about the amount of force being applied.
@@ -151,12 +151,12 @@ If your PR makes notable changes to Winit's features, please update this section
 * Valid orientations
 * Home indicator visibility
 * Status bar visibility and style
-* Deferrring system gestures
+* Deferring system gestures
 * Getting the device idiom
 * Getting the preferred video mode
 
 ### Web
-* Get if systems preferred color scheme is "dark"
+* Get if the systems preferred color scheme is "dark"
 
 ## Usability
 * `serde`: Enables serialization/deserialization of certain types with Serde. (Maintainer: @Osspial)
@@ -166,7 +166,7 @@ If your PR makes notable changes to Winit's features, please update this section
 Legend:
 
 - ✔️: Works as intended
-- ▢: Mostly works but some bugs are known
+- ▢: Mostly works, but some bugs are known
 - ❌: Missing feature or large bugs making it unusable
 - **N/A**: Not applicable for this platform
 - ❓: Unknown status

HALL_OF_CHAMPIONS.md

@@ -2,21 +2,20 @@
 
 The winit maintainers would like to recognize the following former winit
 contributors, without whom winit would not exist in its current form. We thank
-them deeply for their time and efforts, and wish them best of luck in their
+them deeply for their time and efforts and wish them the best of luck in their
 future endeavors:
 
 * [@tomaka]: For creating the winit project and guiding it through its early
   years of existence.
-* [@vberger]: For diligently creating the Wayland backend, and being its
+* [@vberger]: For diligently creating the Wayland backend and being its
   extremely helpful and benevolent maintainer for years.
 * [@francesca64]: For taking over the responsibility of maintaining almost every
-  winit backend, and standardizing HiDPI support across all of them.
+  winit backend and standardizing HiDPI support across all of them.
-* [@Osspial]: For heroically landing EventLoop 2.0, and valiantly ushering in a
+* [@Osspial]: For heroically landing EventLoop 2.0 and valiantly ushering in a
   vastly more sustainable era of winit.
-* [@goddessfreya]: For selflessly taking over maintainership of glutin, and her
+* [@goddessfreya]: For selflessly taking over maintainership of glutin and her
   stellar dedication to improving both winit and glutin.
-* [@ArturKovacs]: For consistently maintaining the macOS backend, and his
+* [@ArturKovacs]: For consistently maintaining the macOS backend and for his immense involvement in designing and implementing the new keyboard API.
-  immense involvement in designing and implementing the new keyboard API.
 
 [@tomaka]: https://github.com/tomaka
 [@vberger]: https://github.com/vberger

README.md

@@ -26,7 +26,7 @@ Join us in any of these:
 
 Winit is a window creation and management library. It can create windows and lets you handle
 events (for example: the window being resized, a key being pressed, a mouse movement, etc.)
-produced by window.
+produced by the window.
 
 Winit is designed to be a low-level brick in a hierarchy of libraries. Consequently, in order to
 show something on the window you need to use the platform-specific getters provided by winit, or
@@ -42,7 +42,7 @@ Winit provides the following features, which can be enabled in your `Cargo.toml`
 
 ## MSRV Policy
 
-The Minimum Supported Rust Version (MSRV) of this crate is **1.65**. Changes to
+This crate's Minimum Supported Rust Version (MSRV) is **1.65**. Changes to
 the MSRV will be accompanied by a minor version bump.
 
 As a **tentative** policy, the upper bound of the MSRV is given by the following
@@ -53,12 +53,11 @@ min(sid, stable - 3)
 ```
 
 Where `sid` is the current version of `rustc` provided by [Debian Sid], and
-`stable` is the latest stable version of Rust. This bound may be broken in the
+`stable` is the latest stable version of Rust. This bound may be broken in case of a major ecosystem shift or a security vulnerability.
-event of a major ecosystem shift or a security vulnerability.
 
 [Debian Sid]: https://packages.debian.org/sid/rustc
 
-The exception to this is for the Android platform, where a higher Rust version
+The exception is for the Android platform, where a higher Rust version
 must be used for certain Android features. In this case, the MSRV will be
 capped at the latest stable version of Rust minus three. This inconsistency is
 not reflected in Cargo metadata, as it is not powerful enough to expose this
@@ -86,7 +85,7 @@ either [provide Winit with a `<canvas>` element][web with_canvas], or [let Winit
 create a `<canvas>` element which you can then retrieve][web canvas getter] and
 insert it into the DOM yourself.
 
-For example code using Winit with WebAssembly, check out the [web example]. For
+For the example code using Winit with WebAssembly, check out the [web example]. For
 information on using Rust on WebAssembly, check out the [Rust and WebAssembly
 book].
 
@@ -109,7 +108,7 @@ glue crate (prior to `0.28` it used
 
 The version of the glue crate that your application depends on _must_ match the
 version that Winit depends on because the glue crate is responsible for your
-application's main entrypoint. If Cargo resolves multiple versions they will
+application's main entry point. If Cargo resolves multiple versions, they will
 clash.
 
 `winit` glue compatibility table:
@@ -127,7 +126,7 @@ The recommended way to avoid a conflict with the glue version is to avoid explic
 depending on the `android-activity` crate, and instead consume the API that
 is re-exported by Winit under `winit::platform::android::activity::*`
 
-Running on an Android device needs a dynamic system library, add this to Cargo.toml:
+Running on an Android device needs a dynamic system library. Add this to Cargo.toml:
 
 ```toml
 [lib]
@@ -135,14 +134,14 @@ name = "main"
 crate-type = ["cdylib"]
 ```
 
-All Android applications are based on an `Activity` subclass and the
+All Android applications are based on an `Activity` subclass, and the
 `android-activity` crate is designed to support different choices for this base
 class. Your application _must_ specify the base class it needs via a feature flag:
 
 | Base Class       | Feature Flag      |  Notes  |
 | :--------------: | :---------------: | :-----: |
 | `NativeActivity` | `android-native-activity` | Built-in to Android - it is possible to use without compiling any Java or Kotlin code. Java or Kotlin code may be needed to subclass `NativeActivity` to access some platform features. It does not derive from the [`AndroidAppCompat`] base class.|
-| [`GameActivity`] | `android-game-activity`   | Derives from [`AndroidAppCompat`] which is a defacto standard `Activity` base class that helps support a wider range of Android versions. Requires a build system that can compile Java or Kotlin and fetch Android dependencies from a [Maven repository][agdk_jetpack] (or link with an embedded [release][agdk_releases] of [`GameActivity`]) |
+| [`GameActivity`] | `android-game-activity`   | Derives from [`AndroidAppCompat`], a defacto standard `Activity` base class that helps support a wider range of Android versions. Requires a build system that can compile Java or Kotlin and fetch Android dependencies from a [Maven repository][agdk_jetpack] (or link with an embedded [release][agdk_releases] of [`GameActivity`]) |
 
 [`GameActivity`]: https://developer.android.com/games/agdk/game-activity
 [`GameTextInput`]: https://developer.android.com/games/agdk/add-support-for-text-input
@@ -155,7 +154,7 @@ For more details, refer to these `android-activity` [example applications](https
 
 ##### Converting from `ndk-glue` to `android-activity`
 
-If your application is currently based on `NativeActivity` via the `ndk-glue` crate and building with `cargo apk` then the minimal changes would be:
+If your application is currently based on `NativeActivity` via the `ndk-glue` crate and building with `cargo apk`, then the minimal changes would be:
 1. Remove `ndk-glue` from your `Cargo.toml`
 2. Enable the `"android-native-activity"` feature for Winit: `winit = { version = "0.29.4", features = [ "android-native-activity" ] }`
 3. Add an `android_main` entrypoint (as above), instead of using the '`[ndk_glue::main]` proc macro from `ndk-macros` (optionally add a dependency on `android_logger` and initialize logging as above).
@@ -173,7 +172,7 @@ If you encounter problems, you should try doing your initialization inside
 #### iOS
 
 Similar to macOS, iOS's main `UIApplicationMain` does some init work that's required
-by all UI related code, see issue [#1705]. You should consider creating your windows
+by all UI-related code (see issue [#1705]). It would be best to consider creating your windows
 inside `Event::Resumed`.
 
 
@@ -184,5 +183,5 @@ inside `Event::Resumed`.
 
 #### Redox OS
 
-Redox OS has some functionality not present yet, that will be implemented when
+Redox OS has some functionality not yet present that will be implemented when
 its orbital display server provides it.

docs/res/ATTRIBUTION.md

@@ -5,7 +5,7 @@ These images are used in the documentation of `winit`.
 ## keyboard_*.svg
 
 These files are a modified version of "[ANSI US QWERTY (Windows)](https://commons.wikimedia.org/wiki/File:ANSI_US_QWERTY_(Windows).svg)"
-by [Tomiĉo] (https://commons.wikimedia.org/wiki/User:Tomi%C4%89o). It is
+by [Tomiĉo] (https://commons.wikimedia.org/wiki/User:Tomi%C4%89o). It was
 originally released under the [CC-BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/deed.en)
 License. Minor modifications have been made by [John Nunley](https://github.com/notgull),
 which have been released under the same license as a derivative work.

src/dpi.rs

@@ -4,13 +4,13 @@
 //!
 //! Modern computer screens don't have a consistent relationship between resolution and size.
 //! 1920x1080 is a common resolution for both desktop and mobile screens, despite mobile screens
-//! normally being less than a quarter the size of their desktop counterparts. What's more, neither
+//! typically being less than a quarter the size of their desktop counterparts. Moreover, neither
-//! desktop nor mobile screens are consistent resolutions within their own size classes - common
+//! desktop nor mobile screens have consistent resolutions within their own size classes - common
 //! mobile screens range from below 720p to above 1440p, and desktop screens range from 720p to 5K
 //! and beyond.
 //!
 //! Given that, it's a mistake to assume that 2D content will only be displayed on screens with
-//! a consistent pixel density. If you were to render a 96-pixel-square image on a 1080p screen,
+//! a consistent pixel density. If you were to render a 96-pixel-square image on a 1080p screen and
 //! then render the same image on a similarly-sized 4K screen, the 4K rendition would only take up
 //! about a quarter of the physical space as it did on the 1080p screen. That issue is especially
 //! problematic with text rendering, where quarter-sized text becomes a significant legibility
@@ -25,12 +25,12 @@
 //!
 //! The solution to this problem is to account for the device's *scale factor*. The scale factor is
 //! the factor UI elements should be scaled by to be consistent with the rest of the user's system -
-//! for example, a button that's normally 50 pixels across would be 100 pixels across on a device
+//! for example, a button that's usually 50 pixels across would be 100 pixels across on a device
 //! with a scale factor of `2.0`, or 75 pixels across with a scale factor of `1.5`.
 //!
 //! Many UI systems, such as CSS, expose DPI-dependent units like [points] or [picas]. That's
-//! usually a mistake, since there's no consistent mapping between the scale factor and the screen's
+//! usually a mistake since there's no consistent mapping between the scale factor and the screen's
-//! actual DPI. Unless you're printing to a physical medium, you should work in scaled pixels rather
+//! actual DPI. Unless printing to a physical medium, you should work in scaled pixels rather
 //! than any DPI-dependent units.
 //!
 //! ### Position and Size types
@@ -42,11 +42,11 @@
 //! coordinates as input, allowing you to use the most convenient coordinate system for your
 //! particular application.
 //!
-//! Winit's position and size types types are generic over their exact pixel type, `P`, to allow the
+//! Winit's position and size types are generic over their exact pixel type, `P`, to allow the
 //! API to have integer precision where appropriate (e.g. most window manipulation functions) and
 //! floating precision when necessary (e.g. logical sizes for fractional scale factors and touch
 //! input). If `P` is a floating-point type, please do not cast the values with `as {int}`. Doing so
-//! will truncate the fractional part of the float, rather than properly round to the nearest
+//! will truncate the fractional part of the float rather than properly round to the nearest
 //! integer. Use the provided `cast` function or [`From`]/[`Into`] conversions, which handle the
 //! rounding properly. Note that precision loss will still occur when rounding from a float to an
 //! int, although rounding lessens the problem.
@@ -55,34 +55,34 @@
 //!
 //! Winit will dispatch a [`ScaleFactorChanged`] event whenever a window's scale factor has changed.
 //! This can happen if the user drags their window from a standard-resolution monitor to a high-DPI
-//! monitor, or if the user changes their DPI settings. This gives you a chance to rescale your
+//! monitor or if the user changes their DPI settings. This allows you to rescale your application's
-//! application's UI elements and adjust how the platform changes the window's size to reflect the new
+//! UI elements and adjust how the platform changes the window's size to reflect the new scale
-//! scale factor. If a window hasn't received a [`ScaleFactorChanged`] event,  then its scale factor
+//! factor. If a window hasn't received a [`ScaleFactorChanged`] event, its scale factor
 //! can be found by calling [`window.scale_factor()`].
 //!
 //! ## How is the scale factor calculated?
 //!
-//! Scale factor is calculated differently on different platforms:
+//! The scale factor is calculated differently on different platforms:
 //!
 //! - **Windows:** On Windows 8 and 10, per-monitor scaling is readily configured by users from the
 //!   display settings. While users are free to select any option they want, they're only given a
-//!   selection of "nice" scale factors, i.e. 1.0, 1.25, 1.5... on Windows 7, the scale factor is
+//!   selection of "nice" scale factors, i.e. 1.0, 1.25, 1.5... on Windows 7. The scale factor is
 //!   global and changing it requires logging out. See [this article][windows_1] for technical
 //!   details.
-//! - **macOS:** Recent versions of macOS allow the user to change the scaling factor for certain
+//! - **macOS:** Recent macOS versions allow the user to change the scaling factor for specific
-//!   displays. When this is available, the user may pick a per-monitor scaling factor from a set
+//!   displays. When available, the user may pick a per-monitor scaling factor from a set of
-//!   of pre-defined settings. All "retina displays" have a scaling factor above 1.0 by default but
+//!   pre-defined settings. All "retina displays" have a scaling factor above 1.0 by default,
-//!   the specific value varies across devices.
+//!   but the specific value varies across devices.
 //! - **X11:** Many man-hours have been spent trying to figure out how to handle DPI in X11. Winit
 //!   currently uses a three-pronged approach:
-//!   + Use the value in the `WINIT_X11_SCALE_FACTOR` environment variable, if present.
+//!   + Use the value in the `WINIT_X11_SCALE_FACTOR` environment variable if present.
 //!   + If not present, use the value set in `Xft.dpi` in Xresources.
 //!   + Otherwise, calculate the scale factor based on the millimeter monitor dimensions provided by XRandR.
 //!
 //!   If `WINIT_X11_SCALE_FACTOR` is set to `randr`, it'll ignore the `Xft.dpi` field and use the
 //!   XRandR scaling method. Generally speaking, you should try to configure the standard system
 //!   variables to do what you want before resorting to `WINIT_X11_SCALE_FACTOR`.
-//! - **Wayland:** Scale factor is suggested by the compositor for each window individually. The
+//! - **Wayland:** The scale factor is suggested by the compositor for each window individually. The
 //!   monitor scale factor may differ from the window scale factor.
 //! - **iOS:** Scale factors are set by Apple to the value that best suits the device, and range
 //!   from `1.0` to `3.0`. See [this article][apple_1] and [this article][apple_2] for more

src/lib.rs

@@ -10,12 +10,12 @@
 //! let event_loop = EventLoop::new().unwrap();
 //! ```
 //!
-//! Once this is done there are two ways to create a [`Window`]:
+//! Once this is done, there are two ways to create a [`Window`]:
 //!
 //!  - Calling [`Window::new(&event_loop)`][window_new].
 //!  - Calling [`let builder = WindowBuilder::new()`][window_builder_new] then [`builder.build(&event_loop)`][window_builder_build].
 //!
-//! The first method is the simplest, and will give you default values for everything. The second
+//! The first method is the simplest and will give you default values for everything. The second
 //! method allows you to customize the way your [`Window`] will look and behave by modifying the
 //! fields of the [`WindowBuilder`] object before you create the [`Window`].
 //!
@@ -56,7 +56,7 @@
     doc = "`EventLoopExtPumpEvents::pump_events()`"
 )]
 //! [^1]. See that method's documentation for more reasons about why
-//! it's discouraged, beyond compatibility reasons.
+//! it's discouraged beyond compatibility reasons.
 //!
 //!
 //! ```no_run
@@ -92,9 +92,9 @@
 //!
 //!             // Queue a RedrawRequested event.
 //!             //
-//!             // You only need to call this if you've determined that you need to redraw, in
+//!             // You only need to call this if you've determined that you need to redraw in
 //!             // applications which do not always need to. Applications that redraw continuously
-//!             // can just render here instead.
+//!             // can render here instead.
 //!             window.request_redraw();
 //!         },
 //!         Event::WindowEvent {
@@ -118,7 +118,7 @@
 //!
 //! # Drawing on the window
 //!
-//! Winit doesn't directly provide any methods for drawing on a [`Window`]. However it allows you to
+//! Winit doesn't directly provide any methods for drawing on a [`Window`]. However, it allows you to
 //! retrieve the raw handle of the window and display (see the [`platform`] module and/or the
 //! [`raw_window_handle`] and [`raw_display_handle`] methods), which in turn allows
 //! you to create an OpenGL/Vulkan/DirectX/Metal/etc. context that can be used to render graphics.
@@ -183,13 +183,13 @@ pub mod window;
 pub mod platform;
 
 /// Wrapper for objects which winit will access on the main thread so they are effectively `Send`
-/// and `Sync`, since they always excute on a single thread.
+/// and `Sync`, since they always execute on a single thread.
 ///
 /// # Safety
 ///
-/// Winit can run only one event loop at the time and the event loop itself is tied to some thread.
+/// Winit can run only one event loop at a time, and the event loop itself is tied to some thread.
-/// The objects could be send across the threads, but once passed to winit, they execute on the
+/// The objects could be sent across the threads, but once passed to winit, they execute on the
-/// mean thread if the platform demands it. Thus marking such objects as `Send + Sync` is safe.
+/// main thread if the platform demands it. Thus, marking such objects as `Send + Sync` is safe.
 #[doc(hidden)]
 #[derive(Clone, Debug)]
 pub(crate) struct SendSyncWrapper<T>(pub(crate) T);