Color Themes Questions

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Color Themes Questions

Ecaterina Moraru (Valica)
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

---

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
Reply | Threaded
Open this post in threaded view
|

Re: Color Themes Questions

Ecaterina Moraru (Valica)
On Mon, Feb 26, 2018 at 1:57 PM, Ecaterina Moraru (Valica) <
[hidden email]> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Color Themes Questions

Ecaterina Moraru (Valica)
In reply to this post by Ecaterina Moraru (Valica)
On Mon, Feb 26, 2018 at 1:57 PM, Ecaterina Moraru (Valica) <
[hidden email]> 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Color Themes Questions

vmassol
Administrator
In reply to this post by Ecaterina Moraru (Valica)
Hi Caty,

Plenty of questions ;)

See below.

> On 26 Feb 2018, at 12:57, Ecaterina Moraru (Valica) <[hidden email]> 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-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?

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