[xwiki-devs] Color Themes Questions
Hi devs, I need your input on some questions: 1. (Important) Where to commit Color Themes? 2. Where do we move old / deprecated Color Themes? 3. What should a Flamingo Theme contain? --- 1. Where to commit Color Themes? We have a running vote for a new default Color Theme. So where should this theme be committed? When considering this question think about the default theme, but also to the other Color Themes variations that won't be voted as a default. A. Platform ( https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik... ) PRO: Being default makes sense to be committed in Platform and to not have a dependency towards a Contrib extension. CON: It will depends on an 10.x XWiki version. The themes could be used for any XWiki > 6.2. Having them outside Platform would allow installation also on older versions. CON: Slow release process for outside contributions CON: Grouped: in the current implementation they come as a package, you cannot install an individual module in a separate Flavor. B. Grouped on Contrib but as individual modules (example https://github.com/xwiki-contrib/color-themes/tree/master/color-theme-iceber... ) CON: Grouped versioning and release process. Each theme could have its own component on JIRA. PRO: Medium contributions: The Maven / JIRA / module setup is done only in the beginning, but still there are technical knowledge to be known how to contribute a theme. PRO: XWiki version independent - can be installed on older instances C. Individual on Contrib (example https://github.com/xwiki-contrib/color-theme-iceberg) PRO/CON: Independent versioning and release process. Still we will be spammed with JIRA projects for each theme. CON: Slow contributions since you need to know how to create Maven modules, provide JIRA components for each theme, release on Nexus, always ask for a repo, etc. D. Individual as XARs on e.x.o PRO: Easy / rapid contributions: you just need to provide a XAR PRO: Platform version independent CON: Cannot be referenced as a dependency from a .pom CON: No blaming or versioning of sources --- IMO the default theme should be committed in Platform (A), but all the other proposals should be in Contrib either grouped (B) or individual (C). I prefer version B (grouped on Contrib) since the themes are very similar in concept and for me it doesn't justify all the independent projects on JIRA, etc. It would be similar to what I did for Icon Themes, see https://github.com/xwiki-contrib/icon-themes Other notes: 1.1 The themes from Platform that were not default, should be made as extensions. This is the case for Garder, Kitty, Marina. 1.2 xwiki-platform-flamingo-theme-bootswatch https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik... should be put in Contrib, as extensions, since they don't relate to XWiki. 1.3 Keeping just the default in Platform is also good for Flavors. Not all themes work for all Flavors. Each Flavor would add the dependency they want. Still this means more work in selecting these themes. --- 2. Where do we move old / deprecated Color Themes? This question applies for old Color Themes. For example when we retired Colibri, we moved all the themes in the Attic https://github.com/xwiki-attic/skin-colibri/tree/master/xwiki-platform-color... even though those themes still worked (since we made them backwards compatible). Also the majority of themes on e.x.o are as XARs. How will we deprecate those? Also how do we mark themes that are not good looking anymore? Also this point is very subjective. I guess the answer to this question depends on what were we vote to commit the Color Themes. --- 3. What should a Flamingo Theme contain? (difference between Skin and CT) The Colibri Color Themes contained just colors. Now with the Flamingo Themes's Advanced section you could easily remove the need to have a Skin and add there also CSS rules, etc. The Bootswatch (xwiki-platform-flamingo-theme-bootswatch) themes are a very bad example, since they change quite a lot of styling and not just variables. I just want to enforce that default themes and especially themes that are provided by XWiki Development Theme should contain only variables. If there are things we need to override we should fix them first in the Skin, not just abuse the "Advanced" section capabilities and power. This is important since the changes done in the Skin apply for all the Themes. You don't need to duplicate the "hack" for all the themes. --- Let me know what you think. Thanks, Caty
On Mon, Feb 26, 2018 at 1:57 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi devs,
I need your input on some questions: 1. (Important) Where to commit Color Themes? 2. Where do we move old / deprecated Color Themes? 3. What should a Flamingo Theme contain?
---
1. Where to commit Color Themes?
We have a running vote for a new default Color Theme. So where should this theme be committed? When considering this question think about the default theme, but also to the other Color Themes variations that won't be voted as a default.
A. Platform (https://github.com/xwiki/xwiki-platform/tree/master/ xwiki-platform-core/xwiki-platform-flamingo/xwiki- platform-flamingo-themes/xwiki-platform-flamingo-theme-ui) PRO: Being default makes sense to be committed in Platform and to not have a dependency towards a Contrib extension. CON: It will depends on an 10.x XWiki version. The themes could be used for any XWiki > 6.2. Having them outside Platform would allow installation also on older versions. CON: Slow release process for outside contributions CON: Grouped: in the current implementation they come as a package, you cannot install an individual module in a separate Flavor.
B. Grouped on Contrib but as individual modules (example https://github.com/xwiki-contrib/color-themes/tree/ master/color-theme-iceberg) CON: Grouped versioning and release process. Each theme could have its own component on JIRA. PRO: Medium contributions: The Maven / JIRA / module setup is done only in the beginning, but still there are technical knowledge to be known how to contribute a theme. PRO: XWiki version independent - can be installed on older instances
C. Individual on Contrib (example https://github.com/xwiki- contrib/color-theme-iceberg) PRO/CON: Independent versioning and release process. Still we will be spammed with JIRA projects for each theme. CON: Slow contributions since you need to know how to create Maven modules, provide JIRA components for each theme, release on Nexus, always ask for a repo, etc.
D. Individual as XARs on e.x.o PRO: Easy / rapid contributions: you just need to provide a XAR PRO: Platform version independent CON: Cannot be referenced as a dependency from a .pom CON: No blaming or versioning of sources
CON: We don't see the active install of individual themes
---
IMO the default theme should be committed in Platform (A), but all the other proposals should be in Contrib either grouped (B) or individual (C). I prefer version B (grouped on Contrib) since the themes are very similar in concept and for me it doesn't justify all the independent projects on JIRA, etc. It would be similar to what I did for Icon Themes, see https://github.com/xwiki-contrib/icon-themes
Other notes: 1.1 The themes from Platform that were not default, should be made as extensions. This is the case for Garder, Kitty, Marina.
1.2 xwiki-platform-flamingo-theme-bootswatch https://github.com/xwiki/ xwiki-platform/tree/master/xwiki-platform-core/xwiki- platform-flamingo/xwiki-platform-flamingo-themes/ xwiki-platform-flamingo-theme-bootswatch should be put in Contrib, as extensions, since they don't relate to XWiki.
1.3 Keeping just the default in Platform is also good for Flavors. Not all themes work for all Flavors. Each Flavor would add the dependency they want. Still this means more work in selecting these themes.
---
2. Where do we move old / deprecated Color Themes?
This question applies for old Color Themes. For example when we retired Colibri, we moved all the themes in the Attic https://github.com/xwiki- attic/skin-colibri/tree/master/xwiki-platform-colorthemes/xwiki-platform- colorthemes-ui/src/main/resources/ColorThemes even though those themes still worked (since we made them backwards compatible).
Also the majority of themes on e.x.o are as XARs. How will we deprecate those?
Also how do we mark themes that are not good looking anymore? Also this point is very subjective.
I guess the answer to this question depends on what were we vote to commit the Color Themes.
---
3. What should a Flamingo Theme contain? (difference between Skin and CT)
The Colibri Color Themes contained just colors. Now with the Flamingo Themes's Advanced section you could easily remove the need to have a Skin and add there also CSS rules, etc.
The Bootswatch (xwiki-platform-flamingo-theme-bootswatch) themes are a very bad example, since they change quite a lot of styling and not just variables.
I just want to enforce that default themes and especially themes that are provided by XWiki Development Theme should contain only variables. If there are things we need to override we should fix them first in the Skin, not just abuse the "Advanced" section capabilities and power.
This is important since the changes done in the Skin apply for all the Themes. You don't need to duplicate the "hack" for all the themes.
---
Let me know what you think. Thanks, Caty
On Mon, Feb 26, 2018 at 1:57 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:
Hi devs,
I need your input on some questions: 1. (Important) Where to commit Color Themes? 2. Where do we move old / deprecated Color Themes? 3. What should a Flamingo Theme contain?
---
1. Where to commit Color Themes?
We have a running vote for a new default Color Theme. So where should this theme be committed? When considering this question think about the default theme, but also to the other Color Themes variations that won't be voted as a default.
A. Platform (https://github.com/xwiki/xwiki-platform/tree/master/ xwiki-platform-core/xwiki-platform-flamingo/xwiki- platform-flamingo-themes/xwiki-platform-flamingo-theme-ui) PRO: Being default makes sense to be committed in Platform and to not have a dependency towards a Contrib extension. CON: It will depends on an 10.x XWiki version. The themes could be used for any XWiki > 6.2. Having them outside Platform would allow installation also on older versions. CON: Slow release process for outside contributions CON: Grouped: in the current implementation they come as a package, you cannot install an individual module in a separate Flavor.
Another CON of being grouped is that we cannot declare correctly the dependency for each individual theme. For example, some themes come with a typographic dependency towards a font-family.
B. Grouped on Contrib but as individual modules (example https://github.com/xwiki-contrib/color-themes/tree/ master/color-theme-iceberg) CON: Grouped versioning and release process. Each theme could have its own component on JIRA. PRO: Medium contributions: The Maven / JIRA / module setup is done only in the beginning, but still there are technical knowledge to be known how to contribute a theme. PRO: XWiki version independent - can be installed on older instances
C. Individual on Contrib (example https://github.com/xwiki- contrib/color-theme-iceberg) PRO/CON: Independent versioning and release process. Still we will be spammed with JIRA projects for each theme. CON: Slow contributions since you need to know how to create Maven modules, provide JIRA components for each theme, release on Nexus, always ask for a repo, etc.
D. Individual as XARs on e.x.o PRO: Easy / rapid contributions: you just need to provide a XAR PRO: Platform version independent CON: Cannot be referenced as a dependency from a .pom CON: No blaming or versioning of sources
---
IMO the default theme should be committed in Platform (A), but all the other proposals should be in Contrib either grouped (B) or individual (C). I prefer version B (grouped on Contrib) since the themes are very similar in concept and for me it doesn't justify all the independent projects on JIRA, etc. It would be similar to what I did for Icon Themes, see https://github.com/xwiki-contrib/icon-themes
Other notes: 1.1 The themes from Platform that were not default, should be made as extensions. This is the case for Garder, Kitty, Marina.
1.2 xwiki-platform-flamingo-theme-bootswatch https://github.com/xwiki/ xwiki-platform/tree/master/xwiki-platform-core/xwiki- platform-flamingo/xwiki-platform-flamingo-themes/ xwiki-platform-flamingo-theme-bootswatch should be put in Contrib, as extensions, since they don't relate to XWiki.
1.3 Keeping just the default in Platform is also good for Flavors. Not all themes work for all Flavors. Each Flavor would add the dependency they want. Still this means more work in selecting these themes.
---
2. Where do we move old / deprecated Color Themes?
This question applies for old Color Themes. For example when we retired Colibri, we moved all the themes in the Attic https://github.com/xwiki- attic/skin-colibri/tree/master/xwiki-platform-colorthemes/xwiki-platform- colorthemes-ui/src/main/resources/ColorThemes even though those themes still worked (since we made them backwards compatible).
Also the majority of themes on e.x.o are as XARs. How will we deprecate those?
Also how do we mark themes that are not good looking anymore? Also this point is very subjective.
I guess the answer to this question depends on what were we vote to commit the Color Themes.
---
3. What should a Flamingo Theme contain? (difference between Skin and CT)
The Colibri Color Themes contained just colors. Now with the Flamingo Themes's Advanced section you could easily remove the need to have a Skin and add there also CSS rules, etc.
The Bootswatch (xwiki-platform-flamingo-theme-bootswatch) themes are a very bad example, since they change quite a lot of styling and not just variables.
I just want to enforce that default themes and especially themes that are provided by XWiki Development Theme should contain only variables. If there are things we need to override we should fix them first in the Skin, not just abuse the "Advanced" section capabilities and power.
This is important since the changes done in the Skin apply for all the Themes. You don't need to duplicate the "hack" for all the themes.
---
Let me know what you think. Thanks, Caty
Hi Caty, Plenty of questions ;) See below.
On 26 Feb 2018, at 12:57, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi devs,
I need your input on some questions: 1. (Important) Where to commit Color Themes? 2. Where do we move old / deprecated Color Themes? 3. What should a Flamingo Theme contain?
---
1. Where to commit Color Themes?
[snip] Already answered in a different thread. Note that you forgot several very important CONs (the most important IMO; the other arguments in favor being small in comparison IMO) of not having them in XS by default such as the discoverability and the ease of use.
2. Where do we move old / deprecated Color Themes?
In the attic IMO. If we remove them it means they’re not good enough and thus should go to the attic (until someone wants to resurrect them and work no them at which they can be moved back to contrib).
This question applies for old Color Themes. For example when we retired Colibri, we moved all the themes in the Attic https://github.com/xwiki-attic/skin-colibri/tree/master/xwiki-platform-color... even though those themes still worked (since we made them backwards compatible).
Also the majority of themes on e.x.o are as XARs. How will we deprecate those?
Same as for all extensions. We mark them as deprecated in the extension. All code in attic still have extensions on e.x.o (we’ve not removed them). Generally we should have a better typed way of marking extensions as deprecated.
Also how do we mark themes that are not good looking anymore? Also this point is very subjective.
By mentioning the issues on the extension page.
I guess the answer to this question depends on what were we vote to commit the Color Themes.
---
3. What should a Flamingo Theme contain? (difference between Skin and CT)
The Colibri Color Themes contained just colors. Now with the Flamingo Themes's Advanced section you could easily remove the need to have a Skin and add there also CSS rules, etc.
Not really. How do you override templates with a Flamingo Theme? You’re probably just referring the style.css template in the skin. Indeed we could possibly deprecate this part. Would need to do some survey and list the pros/cons from our users. Thus the Skin would be reserved to content and the Theme to styling/L&F.
The Bootswatch (xwiki-platform-flamingo-theme-bootswatch) themes are a very bad example, since they change quite a lot of styling and not just variables. I just want to enforce that default themes and especially themes that are provided by XWiki Development Theme should contain only variables. If there are things we need to override we should fix them first in the Skin, not just abuse the "Advanced" section capabilities and power.
Actually I would view it the other way around: * Styling/CSS: in Themes * Content/Layout: in Skins It’s actually not logical that the Skin would do styling anymore since we have themes for that.
This is important since the changes done in the Skin apply for all the Themes. You don't need to duplicate the "hack" for all the themes.
Couldn’t the Themes do the same as we do in the Skin and use @import for common stuff? Thanks -Vincent
---
Let me know what you think. Thanks, Caty
participants (2)
-
Ecaterina Moraru (Valica) -
Vincent Massol