From af80ce842d9da2289d5a2649f82784ff755e733c Mon Sep 17 00:00:00 2001 From: Murarth Date: Tue, 12 Nov 2019 16:51:46 -0700 Subject: [PATCH] Fix `cargo doc` on nightly builds (#1274) --- src/dpi.rs | 18 +++++++++--------- src/event.rs | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/dpi.rs b/src/dpi.rs index 27fbbc49..ba163de2 100644 --- a/src/dpi.rs +++ b/src/dpi.rs @@ -28,18 +28,18 @@ //! them entering an existential panic. Once users enter that state, they will no longer be focused on your application. //! //! There are two ways to get the DPI factor: -//! - You can track the [`HiDpiFactorChanged`](event::WindowEvent::HiDpiFactorChanged) event of your +//! - You can track the [`HiDpiFactorChanged`](crate::event::WindowEvent::HiDpiFactorChanged) event of your //! windows. This event is sent any time the DPI factor changes, either because the window moved to another monitor, //! or because the user changed the configuration of their screen. //! - You can also retrieve the DPI factor of a monitor by calling -//! [`MonitorHandle::hidpi_factor`](monitor::MonitorHandle::hidpi_factor), or the +//! [`MonitorHandle::hidpi_factor`](crate::monitor::MonitorHandle::hidpi_factor), or the //! current DPI factor applied to a window by calling -//! [`Window::hidpi_factor`](window::Window::hidpi_factor), which is roughly equivalent +//! [`Window::hidpi_factor`](crate::window::Window::hidpi_factor), which is roughly equivalent //! to `window.current_monitor().hidpi_factor()`. //! //! Depending on the platform, the window's actual DPI factor may only be known after //! the event loop has started and your window has been drawn once. To properly handle these cases, -//! the most robust way is to monitor the [`HiDpiFactorChanged`](event::WindowEvent::HiDpiFactorChanged) +//! the most robust way is to monitor the [`HiDpiFactorChanged`](crate::event::WindowEvent::HiDpiFactorChanged) //! event and dynamically adapt your drawing logic to follow the DPI factor. //! //! Here's an overview of what sort of DPI factors you can expect, and where they come from: @@ -59,21 +59,21 @@ //! //! The window's logical size is conserved across DPI changes, resulting in the physical size changing instead. This //! may be surprising on X11, but is quite standard elsewhere. Physical size changes always produce a -//! [`Resized`](event::WindowEvent::Resized) event, even on platforms where no resize actually occurs, +//! [`Resized`](crate::event::WindowEvent::Resized) event, even on platforms where no resize actually occurs, //! such as macOS and Wayland. As a result, it's not necessary to separately handle -//! [`HiDpiFactorChanged`](event::WindowEvent::HiDpiFactorChanged) if you're only listening for size. +//! [`HiDpiFactorChanged`](crate::event::WindowEvent::HiDpiFactorChanged) if you're only listening for size. //! //! Your GPU has no awareness of the concept of logical pixels, and unless you like wasting pixel density, your //! framebuffer's size should be in physical pixels. //! -//! `winit` will send [`Resized`](event::WindowEvent::Resized) events whenever a window's logical size -//! changes, and [`HiDpiFactorChanged`](event::WindowEvent::HiDpiFactorChanged) events +//! `winit` will send [`Resized`](crate::event::WindowEvent::Resized) events whenever a window's logical size +//! changes, and [`HiDpiFactorChanged`](crate::event::WindowEvent::HiDpiFactorChanged) events //! whenever the DPI factor changes. Receiving either of these events means that the physical size of your window has //! changed, and you should recompute it using the latest values you received for each. If the logical size and the //! DPI factor change simultaneously, `winit` will send both events together; thus, it's recommended to buffer //! these events and process them at the end of the queue. //! -//! If you never received any [`HiDpiFactorChanged`](event::WindowEvent::HiDpiFactorChanged) events, +//! If you never received any [`HiDpiFactorChanged`](crate::event::WindowEvent::HiDpiFactorChanged) events, //! then your window's DPI factor is 1. /// Checks that the DPI factor is a normal positive `f64`. diff --git a/src/event.rs b/src/event.rs index c06f3c3d..ff94aa84 100644 --- a/src/event.rs +++ b/src/event.rs @@ -3,7 +3,7 @@ //! These are sent to the closure given to [`EventLoop::run(...)`][event_loop_run], where they get //! processed and used to modify the program state. For more details, see the root-level documentation. //! -//! [event_loop_run]: event_loop::EventLoop::run +//! [event_loop_run]: crate::event_loop::EventLoop::run use instant::Instant; use std::path::PathBuf;