3 files changed, 55 insertions, 20 deletions
diff --git a/native/src/renderer.rs b/native/src/renderer.rs
index 2244f00b..afe1b09a 100644
--- a/native/src/renderer.rs
+++ b/native/src/renderer.rs
@@ -1,8 +1,10 @@
 //! Write your own renderer.
 //!
-//! There is not a common entrypoint or trait for a __renderer__ in Iced.
-//! Instead, every [`Widget`] constrains its generic `Renderer` type as
-//! necessary.
+//! You will need to implement the `Renderer` trait first. It simply contains
+//! an `Output` associated type.
+//!
+//! There is no common trait to draw all the widgets. Instead, every [`Widget`]
+//! constrains its generic `Renderer` type as necessary.
 //!
 //! This approach is flexible and composable. For instance, the
 //! [`Text`] widget only needs a [`text::Renderer`] while a [`Checkbox`] widget
@@ -17,22 +19,13 @@
 //! [`text::Renderer`]: ../widget/text/trait.Renderer.html
 //! [`Checkbox`]: ../widget/checkbox/struct.Checkbox.html
 //! [`checkbox::Renderer`]: ../widget/checkbox/trait.Renderer.html
-use crate::{Color, Layout};
 
-/// A renderer able to graphically explain a [`Layout`].
-///
-/// [`Layout`]: ../struct.Layout.html
-pub trait Debugger {
-    /// Explains the [`Layout`] of an [`Element`] for debugging purposes.
-    ///
-    /// This will be called when [`Element::explain`] has been used. It should
-    /// _explain_ the given [`Layout`] graphically.
-    ///
-    /// A common approach consists in recursively rendering the bounds of the
-    /// [`Layout`] and its children.
-    ///
-    /// [`Layout`]: struct.Layout.html
-    /// [`Element`]: struct.Element.html
-    /// [`Element::explain`]: struct.Element.html#method.explain
-    fn explain(&mut self, layout: &Layout<'_>, color: Color);
+mod debugger;
+mod windowed;
+
+pub use debugger::Debugger;
+pub use windowed::Windowed;
+
+pub trait Renderer {
+    type Output;
 }
diff --git a/native/src/renderer/debugger.rs b/native/src/renderer/debugger.rs
new file mode 100644
index 00000000..4cc50661
--- /dev/null
+++ b/native/src/renderer/debugger.rs
@@ -0,0 +1,25 @@
+use crate::{Color, Layout, Point, Widget};
+
+/// A renderer able to graphically explain a [`Layout`].
+///
+/// [`Layout`]: ../struct.Layout.html
+pub trait Debugger: super::Renderer {
+    /// Explains the [`Layout`] of an [`Element`] for debugging purposes.
+    ///
+    /// This will be called when [`Element::explain`] has been used. It should
+    /// _explain_ the given [`Layout`] graphically.
+    ///
+    /// A common approach consists in recursively rendering the bounds of the
+    /// [`Layout`] and its children.
+    ///
+    /// [`Layout`]: struct.Layout.html
+    /// [`Element`]: struct.Element.html
+    /// [`Element::explain`]: struct.Element.html#method.explain
+    fn explain<Message>(
+        &mut self,
+        widget: &dyn Widget<Message, Self>,
+        layout: Layout<'_>,
+        cursor_position: Point,
+        color: Color,
+    ) -> Self::Output;
+}
diff --git a/native/src/renderer/windowed.rs b/native/src/renderer/windowed.rs
new file mode 100644
index 00000000..bcf37964
--- /dev/null
+++ b/native/src/renderer/windowed.rs
@@ -0,0 +1,17 @@
+use crate::MouseCursor;
+
+use raw_window_handle::HasRawWindowHandle;
+
+pub trait Windowed: super::Renderer {
+    type Target;
+
+    fn new<W: HasRawWindowHandle>(window: &W) -> Self;
+
+    fn target(&self, width: u16, height: u16) -> Self::Target;
+
+    fn draw(
+        &mut self,
+        output: &Self::Output,
+        target: &mut Self::Target,
+    ) -> MouseCursor;
+}