diff options
author | 2019-09-14 19:16:06 +0200 | |
---|---|---|
committer | 2019-09-14 19:16:06 +0200 | |
commit | a97401aed2a173260a4abfdb65a77975ce6c0f01 (patch) | |
tree | ca85ba2e078ddfeee8e74abd4eaae7c25b031cb2 /src/renderer.rs | |
parent | 8b8f7563ad33dafeadf6238e377748cdec17d67a (diff) | |
download | iced-a97401aed2a173260a4abfdb65a77975ce6c0f01.tar.gz iced-a97401aed2a173260a4abfdb65a77975ce6c0f01.tar.bz2 iced-a97401aed2a173260a4abfdb65a77975ce6c0f01.zip |
Rethink workspace structure
Diffstat (limited to 'src/renderer.rs')
-rw-r--r-- | src/renderer.rs | 45 |
1 files changed, 45 insertions, 0 deletions
diff --git a/src/renderer.rs b/src/renderer.rs new file mode 100644 index 00000000..b445190b --- /dev/null +++ b/src/renderer.rs @@ -0,0 +1,45 @@ +//! 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); +} |