18 Mar
2018
18 Mar
'18
2:37 p.m.
Hi Caty,
Plenty of questions ;)
See below.
On 26 Feb 2018, at 12:57, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> 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-colo…
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