Hi Marius, 2014-06-11 21:26 GMT+02:00 Marius Dumitru Florea < [email protected]>:
There are currently many places (both in platform and in extensions) where we use color theme properties such as $theme.pageContentBackgroundColor .
For them, I have written a retro-compatibility component that computes the color themes variables from the style.css generated by Flamingo. It actually does a mapping between bootstrap variables and old color theme variables. It is not perfect, but at least it does not break the whole UI.
Does FlamingoThemeCode.ThemeClass have completely different properties? I hope not. I'm looking at the ColorThemeClass and most of its properties seem pretty generic, i.e. skin independent. Which ones are skin dependent?
First, the preview section is completely skin dependent (see: http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/Ca... ). Then, the new theme editor will propose to customize a set of variables specific to bootstrap, just like: http://fancyboot.designspebam.com/ We are exposing the BS variables because it is flexible and powerful. Mixing old color theme variables and bootstrap variables will not resulting to a consistent set of variables, so that is why I am proposing to separate the 2 cases. BTW, old color themes are still compatibles with Flamingo, because we have a binding between the old color theme variables and the bootstrap variables, but it is far from perfect.
Also, https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c7... shows that FlamingoThemeCode.ThemeClass has only two properties? body-bg and text-color, both present with a different name in ColorThemeClass.
When I have posted the link above, I only wanted to show you the modifications done on SkinAction.java. Of course, ThemeClass will not have only two properties! This commit is a first step to have a proof of concept. If you want to have the list of bootstrap variables, you could see there: http://getbootstrap.com/customize/#less-variables Of course we won't expose all these variables: it would be confusing for the end user. We have to chose some of them. If the user wants to customize variables that are not exposed, she can do that with the textarea field where she can write LESS code.
Thanks, Marius
On Wed, Jun 11, 2014 at 6:43 PM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote:
Hi devs.
I am implementing the Color Theme Editor for Flamingo! And this is a preview:
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/fl...
Since the current color theme application is strongly linked to Colibri, and the new application will be strongly linked to Flamingo, I propose
the
following:
1/ move xwiki-platform-colorthemes in xwiki-platform-colibri and state that this application is only compatible with colibri-based skin. 2/ create the new application in xwiki-platform-flamingo 3/ the new color theme application will actually propose more than colors (fonts, less code, etc...), so I propose to call it xwiki-platform-flamingo-themes. 4/ in the administration, we have a page that propose which color theme we want to use. Since the new application will not be compatible with the old one, I propose to add an extension point (such as what we have to configure search suggest sources) in order to propose the themes corresponding to the selected skin (ie: xobjects of ColorThemes.ColorThemeClass for colibri and skins based on colibri, and xobjects of FlamingoThemeCode.ThemeClass for flamingo). 5/ modify SkinAction that currenlty executes velocity code on a skin file if the mime type is CSS or JS, to also execute velocity on files suffixed by .less.vm, because I need it for my application. To see what it looks like, please look at
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c7...
. The alternative is to create a new action which is too much IMO. 6/ when colibri will be deprecated on removed from XE, we will do the same for the old color theme application.
WDYT?
Thanks, Guillaume _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Thanks, Guillaume