summaryrefslogtreecommitdiffstats
path: root/src/renderer.rs
diff options
context:
space:
mode:
authorLibravatar Héctor Ramón <hector0193@gmail.com>2019-09-24 15:39:33 +0200
committerLibravatar GitHub <noreply@github.com>2019-09-24 15:39:33 +0200
commit68c4752e998dca1d618380ce4e7d8ac52b710056 (patch)
tree35e386030b072c189509bb2ed3adeaec5b0fd4d1 /src/renderer.rs
parentbb5cac49d028eb53c259ae58e3a007ebfb736fd4 (diff)
parent05c7c39ecb8910c75b82dc4052a7720fb2d42b4a (diff)
downloadiced-68c4752e998dca1d618380ce4e7d8ac52b710056.tar.gz
iced-68c4752e998dca1d618380ce4e7d8ac52b710056.tar.bz2
iced-68c4752e998dca1d618380ce4e7d8ac52b710056.zip
Merge pull request #17 from hecrj/web
Basic web support (core, native, and web crates)
Diffstat (limited to 'src/renderer.rs')
-rw-r--r--src/renderer.rs45
1 files changed, 0 insertions, 45 deletions
diff --git a/src/renderer.rs b/src/renderer.rs
deleted file mode 100644
index b445190b..00000000
--- a/src/renderer.rs
+++ /dev/null
@@ -1,45 +0,0 @@
-//! 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.
-//!
-//! This approach is flexible and composable. For instance, the
-//! [`Text`] widget only needs a [`text::Renderer`] while a [`Checkbox`] widget
-//! needs both a [`text::Renderer`] and a [`checkbox::Renderer`], reusing logic.
-//!
-//! In the end, a __renderer__ satisfying all the constraints is
-//! needed to build a [`UserInterface`].
-//!
-//! [`Widget`]: ../widget/trait.Widget.html
-//! [`UserInterface`]: ../struct.UserInterface.html
-//! [`Text`]: ../widget/text/struct.Text.html
-//! [`text::Renderer`]: ../widget/text/trait.Renderer.html
-//! [`Checkbox`]: ../widget/checkbox/struct.Checkbox.html
-//! [`checkbox::Renderer`]: ../widget/checkbox/trait.Renderer.html
-use crate::Layout;
-
-/// A renderer able to graphically explain a [`Layout`].
-///
-/// [`Layout`]: ../struct.Layout.html
-pub trait Debugger {
- /// The color type that will be used to configure the _explanation_.
- ///
- /// This is the type that will be asked in [`Element::explain`].
- ///
- /// [`Element::explain`]: ../struct.Element.html#method.explain
- type Color: Copy;
-
- /// 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: Self::Color);
-}