Update docs to differentiate DeviceEvents and WindowEvents (#976)

src/lib.rs

@@ -22,11 +22,15 @@
 //!
 //! # Event handling
 //!
-//! Once a [`Window`] has been created, it will *generate events*. For example whenever the user moves
-//! the [`Window`], resizes the [`Window`], moves the mouse, etc. an event is generated.
+//! Once a [`Window`] has been created, it will generate different *events*. A [`Window`] object can
+//! generate a [`WindowEvent`] when certain things happen, like whenever the user moves their mouse
+//! or presses a key inside the [`Window`]. Devices can generate a [`DeviceEvent`] directly as well,
+//! which contains unfiltered event data that isn't specific to a certain window. Some user
+//! activity, like mouse movement, can generate both a [`WindowEvent`] *and* a [`DeviceEvent`]. You
+//! can also create and handle your own custom [`UserEvent`]s, if desired.
 //!
-//! The events generated by a [`Window`] can be retreived from the [`EventLoop`] the [`Window`] was created
-//! with.
+//! Events can be retreived by using an [`EventLoop`]. A [`Window`] will send its events to the
+//! [`EventLoop`] object it was created with.
 //!
 //! You do this by calling [`event_loop.run(...)`][event_loop_run]. This function will run forever
 //! unless `control_flow` is set to [`ControlFlow`]`::`[`Exit`], at which point [`Event`]`::`[`LoopDestroyed`]
@@ -100,7 +104,9 @@
 //! [window_builder_build]: ./window/struct.WindowBuilder.html#method.build
 //! [window_id_fn]: ./window/struct.Window.html#method.id
 //! [`Event`]: ./event/enum.Event.html
-//! [`WindowEvent`]: ./event/enum.Event.html#variant.WindowEvent
+//! [`WindowEvent`]: ./event/enum.WindowEvent.html
+//! [`DeviceEvent`]: ./event/enum.DeviceEvent.html
+//! [`UserEvent`]: ./event/enum.Event.html#variant.UserEvent
 //! [`LoopDestroyed`]: ./event/enum.Event.html#variant.LoopDestroyed
 //! [`platform`]: ./platform/index.html