From 8b8f7563ad33dafeadf6238e377748cdec17d67a Mon Sep 17 00:00:00 2001 From: Héctor Ramón Jiménez Date: Tue, 10 Sep 2019 19:41:49 +0200 Subject: Switch to workspace layout --- src/renderer.rs | 45 --------------------------------------------- 1 file changed, 45 deletions(-) delete mode 100644 src/renderer.rs (limited to 'src/renderer.rs') 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); -} -- cgit From a97401aed2a173260a4abfdb65a77975ce6c0f01 Mon Sep 17 00:00:00 2001 From: Héctor Ramón Jiménez Date: Sat, 14 Sep 2019 19:16:06 +0200 Subject: Rethink workspace structure --- src/renderer.rs | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 src/renderer.rs (limited to 'src/renderer.rs') 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); +} -- cgit From b83a4b42dd912b5f59d40e7d4f7f7ccdabc43019 Mon Sep 17 00:00:00 2001 From: Héctor Ramón Jiménez Date: Thu, 19 Sep 2019 18:47:01 +0200 Subject: Remove generic `Color` in widgets --- src/renderer.rs | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) (limited to 'src/renderer.rs') diff --git a/src/renderer.rs b/src/renderer.rs index b445190b..2244f00b 100644 --- a/src/renderer.rs +++ b/src/renderer.rs @@ -17,19 +17,12 @@ //! [`text::Renderer`]: ../widget/text/trait.Renderer.html //! [`Checkbox`]: ../widget/checkbox/struct.Checkbox.html //! [`checkbox::Renderer`]: ../widget/checkbox/trait.Renderer.html -use crate::Layout; +use crate::{Color, 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 @@ -41,5 +34,5 @@ pub trait Debugger { /// [`Layout`]: struct.Layout.html /// [`Element`]: struct.Element.html /// [`Element::explain`]: struct.Element.html#method.explain - fn explain(&mut self, layout: &Layout<'_>, color: Self::Color); + fn explain(&mut self, layout: &Layout<'_>, color: Color); } -- cgit From b9e0f7494881ad7cdfbcbc16878ecc6ef717753f Mon Sep 17 00:00:00 2001 From: Héctor Ramón Jiménez Date: Fri, 20 Sep 2019 19:15:31 +0200 Subject: Create `iced_core` and `iced_native` --- src/renderer.rs | 38 -------------------------------------- 1 file changed, 38 deletions(-) delete mode 100644 src/renderer.rs (limited to 'src/renderer.rs') diff --git a/src/renderer.rs b/src/renderer.rs deleted file mode 100644 index 2244f00b..00000000 --- a/src/renderer.rs +++ /dev/null @@ -1,38 +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::{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); -} -- cgit