From ea97b36db68c08746ce7135ecc11cc42e8163025 Mon Sep 17 00:00:00 2001 From: wiiznokes <78230769+wiiznokes@users.noreply.github.com> Date: Sat, 18 May 2024 13:02:26 +0200 Subject: [PATCH 1/6] Create 0000-template.md --- text/0000-template.md | 77 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 text/0000-template.md diff --git a/text/0000-template.md b/text/0000-template.md new file mode 100644 index 0000000..bad13a0 --- /dev/null +++ b/text/0000-template.md @@ -0,0 +1,77 @@ +# Feature Name + +## Summary + +One paragraph explanation of the feature. + + +## Motivation + +Why are we doing this? What use cases does it support? What is the expected outcome? + + +## Guide-level explanation + +Explain the proposal as if it was already included in the library and you were teaching it to another iced programmer. That generally means: + +- Introducing new named concepts. +- Explaining the feature largely in terms of examples. +- Explaining how iced programmers should *think* about the feature, and how it should impact the way they use iced. It should explain the impact as concretely as possible. + +For implementation-oriented RFCs (e.g. for compiler internals), this section should focus on how compiler contributors should think about the change, and give examples of its concrete impact. For policy RFCs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms. + + +## Implementation strategy + +This is the technical portion of the RFC. Explain the design in sufficient detail that: + +- Its interaction with other features is clear. +- It is reasonably clear how the feature would be implemented. +- Corner cases are dissected by example. + +The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. + + +## Drawbacks + +Why should we *not* do this? + + +## Rationale and alternatives + +- Why is this design the best in the space of possible designs? +- What other designs have been considered and what is the rationale for not choosing them? +- What is the impact of not doing this? + + +## [Optional] Prior art + +Discuss prior art, both the good and the bad, in relation to this proposal. +A few examples of what this can include are: + +- Does this feature exist in other GUI toolkits and what experience have their community had? +- Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. + +This section is intended to encourage you as an author to think about the lessons from other toolkits, provide readers of your RFC with a fuller picture. +If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other languages. + +Note that while precedent set by other languages is some motivation, it does not on its own motivate an RFC. +Please also take into consideration that iced sometimes intentionally diverges from common toolkit features. + + +## Unresolved questions + +- What parts of the design do you expect to resolve through the RFC process before this gets merged? +- What parts of the design do you expect to resolve through the implementation of this feature before stabilization? +- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? + + +## [Optional] Future possibilities + +Think about what the natural extension and evolution of your proposal would be and how it would affect the toolkit and project as a whole in a holistic way. Try to use this section as a tool to more fully consider all possible interactions with the project and language in your proposal. Also consider how this all fits into the roadmap for the project. + +This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related. + +If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything. + +Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information. From 72f0ba10516594e0b953807d224b96ebffbf1361 Mon Sep 17 00:00:00 2001 From: wiiznokes <78230769+wiiznokes@users.noreply.github.com> Date: Sat, 18 May 2024 13:03:58 +0200 Subject: [PATCH 2/6] rename file --- text/{0000-template.md => 0024-template.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename text/{0000-template.md => 0024-template.md} (100%) diff --git a/text/0000-template.md b/text/0024-template.md similarity index 100% rename from text/0000-template.md rename to text/0024-template.md From fda32d952e0944d2c5f1e2850ccd6e5ba5d8c763 Mon Sep 17 00:00:00 2001 From: wiiznokes <78230769+wiiznokes@users.noreply.github.com> Date: Sat, 18 May 2024 14:33:48 +0200 Subject: [PATCH 3/6] write rfc --- text/0024-template.md | 122 +++++++++++++++++++++++++++++++----------- 1 file changed, 91 insertions(+), 31 deletions(-) diff --git a/text/0024-template.md b/text/0024-template.md index bad13a0..4816481 100644 --- a/text/0024-template.md +++ b/text/0024-template.md @@ -1,77 +1,137 @@ -# Feature Name +# Theme Section + ## Summary -One paragraph explanation of the feature. + +This rfc proposes to add a field `section` to the `Theme` enum. +```rust +enum Section { + TopBar, + Card, + Body, + Drawer, + ... +} +``` ## Motivation -Why are we doing this? What use cases does it support? What is the expected outcome? +Imagine you want to add an icon in an elevated Card, and a drawer. It is likely that the background color of these "sections" will be different. Yet, currently, the colors of the button will be the same. This change will allow widgets to change their colors based on the section they are in. This would fix all contrast issues out of the box. ## Guide-level explanation -Explain the proposal as if it was already included in the library and you were teaching it to another iced programmer. That generally means: +### For widgets + +The style function signature will not change. You will be able to know the section you're in and change properties accordingly. Example: + + +```rust +fn style(theme: Theme, status: Status) -> Style { + let mut style = Style::default(); + if theme.section() == Section::Card { + style.text = theme.palette().on_background_card; + } + style +} +``` + -- Introducing new named concepts. -- Explaining the feature largely in terms of examples. -- Explaining how iced programmers should *think* about the feature, and how it should impact the way they use iced. It should explain the impact as concretely as possible. +We could also define well known widgets to structure an Iced app. +For example, a [drawer](https://m3.material.io/components/navigation-drawer/overview) which takes two `Element`s. In its draw function, it could change the theme section like this: -For implementation-oriented RFCs (e.g. for compiler internals), this section should focus on how compiler contributors should think about the change, and give examples of its concrete impact. For policy RFCs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms. + +```rust +fn draw( + &self, + tree: &Tree, + renderer: &mut Renderer, + theme: &Theme, + ... +) { + + let drawer_theme = theme.with_section(Section::Drawer); + let body_theme = theme.with_section(Section::Body); + + + self.content + .as_widget() + .draw(tree, renderer, &drawer_theme, &style, layout, cursor, viewport); + self.content + .as_widget() + .draw(tree, renderer, &body_theme, &style, layout, cursor, viewport); + +} +``` ## Implementation strategy -This is the technical portion of the RFC. Explain the design in sufficient detail that: -- Its interaction with other features is clear. -- It is reasonably clear how the feature would be implemented. -- Corner cases are dissected by example. +The implementation for this is quite simple with the new theme API. +- change the `Theme` enum to a struct. +- add a `section` field to it. +- add a `kind` field for the previous `Theme` enum. + + +functions added to `Theme`: +- `pub fn section(&self) -> &Section` +- `pub fn kind(&self) -> &ThemeKind` +- `pub fn with_section(&self, section: Section) -> Theme` + -The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. + + +But the interesting and difficult task is to have a coherent structure and style across Iced app and widgets. Ei, what section and widgets we expose to structure an app, and what colors to use. +This would probably require changing the color palette to match the set of sections exposed. ## Drawbacks -Why should we *not* do this? + +- Some could argue that it is the responsibility of the developer to make a nice UI. However, I disagree. I believe a quality UI toolkit should inherently prevent issues with contrast or coherence in your app by default. Similarly to the Rust api that tends to be impossible to miss use. +- It could lead to apps that look like each other. But I think it is partially true, since this would only expose building blocks for your UI. Also, I kinda like that toolkits have their own identity. Like you directly know if an app was made with qt or gtk. +- Users will not be able to define their own section. +- This kinda increases the number of possible combinations of styles for a widget, which is already quite big. But you don’t have to define a custom style for every section. And we could imagine helper functions for the palette. + + ## Rationale and alternatives + - Why is this design the best in the space of possible designs? - What other designs have been considered and what is the rationale for not choosing them? - What is the impact of not doing this? + + ## [Optional] Prior art -Discuss prior art, both the good and the bad, in relation to this proposal. -A few examples of what this can include are: -- Does this feature exist in other GUI toolkits and what experience have their community had? -- Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. +Some jetpack compose components: +- [scaffold](https://www.composables.com/material3/scaffold) +- [cards](https://m3.material.io/components/cards/overview) +- [dialogs](https://m3.material.io/components/dialogs/overview) +- [navigation-bar](https://m3.material.io/components/navigation-bar/overview) +- [navigation-drawer](https://m3.material.io/components/navigation-drawer/overview). -This section is intended to encourage you as an author to think about the lessons from other toolkits, provide readers of your RFC with a fuller picture. -If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other languages. -Note that while precedent set by other languages is some motivation, it does not on its own motivate an RFC. -Please also take into consideration that iced sometimes intentionally diverges from common toolkit features. +The material3 color palette: +- [how to use it](https://m3.material.io/styles/color/roles) +- [all the fields](https://developer.android.com/reference/kotlin/androidx/compose/material3/ColorScheme#public-properties) ## Unresolved questions -- What parts of the design do you expect to resolve through the RFC process before this gets merged? -- What parts of the design do you expect to resolve through the implementation of this feature before stabilization? -- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? +- What sections should we expose ? -## [Optional] Future possibilities -Think about what the natural extension and evolution of your proposal would be and how it would affect the toolkit and project as a whole in a holistic way. Try to use this section as a tool to more fully consider all possible interactions with the project and language in your proposal. Also consider how this all fits into the roadmap for the project. - -This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related. +## [Optional] Future possibilities -If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything. -Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information. +More and more sections. From 0288cc098d82bb0a3599a15a43493174772bc898 Mon Sep 17 00:00:00 2001 From: wiiznokes <78230769+wiiznokes@users.noreply.github.com> Date: Sat, 18 May 2024 14:35:19 +0200 Subject: [PATCH 4/6] rename file --- text/{0024-template.md => 0024-theme-sections.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename text/{0024-template.md => 0024-theme-sections.md} (99%) diff --git a/text/0024-template.md b/text/0024-theme-sections.md similarity index 99% rename from text/0024-template.md rename to text/0024-theme-sections.md index 4816481..ddef99f 100644 --- a/text/0024-template.md +++ b/text/0024-theme-sections.md @@ -1,4 +1,4 @@ -# Theme Section +# Theme Sections ## Summary From 397a81adfe018cda2ce32443ca11c7b070c14ecb Mon Sep 17 00:00:00 2001 From: wiiznokes <78230769+wiiznokes@users.noreply.github.com> Date: Sat, 18 May 2024 18:40:46 +0200 Subject: [PATCH 5/6] typo --- text/0024-theme-sections.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0024-theme-sections.md b/text/0024-theme-sections.md index ddef99f..1d06eec 100644 --- a/text/0024-theme-sections.md +++ b/text/0024-theme-sections.md @@ -18,7 +18,7 @@ enum Section { ## Motivation -Imagine you want to add an icon in an elevated Card, and a drawer. It is likely that the background color of these "sections" will be different. Yet, currently, the colors of the button will be the same. This change will allow widgets to change their colors based on the section they are in. This would fix all contrast issues out of the box. +Imagine you want to add an icon in an elevated Card and a drawer. It is likely that the background color of these "sections" will be different. Yet, currently, the colors of the button will be the same. This change will allow widgets to change their colors based on the section they are in. This would fix all contrast issues out of the box. ## Guide-level explanation From e96162da3b51d209cd9882d7cecdc5558cb0ffec Mon Sep 17 00:00:00 2001 From: wiiznokes <78230769+wiiznokes@users.noreply.github.com> Date: Sat, 18 May 2024 18:43:47 +0200 Subject: [PATCH 6/6] Update 0024-theme-sections.md --- text/0024-theme-sections.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0024-theme-sections.md b/text/0024-theme-sections.md index 1d06eec..adc73c0 100644 --- a/text/0024-theme-sections.md +++ b/text/0024-theme-sections.md @@ -56,7 +56,7 @@ fn draw( let body_theme = theme.with_section(Section::Body); - self.content + self.drawer_content .as_widget() .draw(tree, renderer, &drawer_theme, &style, layout, cursor, viewport); self.content