On Mon, May 26, 2014 at 4:49 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:
Hi!
The current color theme editor is designed for colibri, and does not look like flamingo does. We have several options here: - create a new color theme editor, especially for Flamingo - modify the current one to detect which skin is currenlty used, and change the preview.
IMO we should create a new Themes editor especially for Flamingo. I'm not sure it needs to look exactly as the current ColorThemes wizard. I doesn't need to duplicate the display structure. I imagine it like this: * Layout: PartA - Part B * PartA - Variables: provide the fields needed to be changed, just like http://getbootstrap.com/customize/#less-variables * PartB - Preview: could be an iframe of something, even using less.js to parse the new LESS variables (without compiling them) IMO we shouldn't provide a mockup preview of the skin (like the current ColorTheme), but just use a real page and preview the changes on spot. Now it's true that we are using $theme values all over our uicomponents, so we need to find a way to map the LESS variables with the ColorThemes Velocity variables. When I did Junco I had these 2 files: https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-colorth... https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-variabl... So for example, we download a Boostrap theme. It will provide a variables.less file, containing something like: @brand-primary: #2173AF; If I look in my xwiki-variables.less I mapped @brand-primary: @theme-buttonPrimaryBackgroundColor; so IMO we should modify the colorThemeInit.vm and add something like: if a variables.less is provided than $theme.put('buttonPrimaryBackgroundColor',"@brand-primary"); = $theme.put('buttonPrimaryBackgroundColor','#2173AF'); We can discuss a bit my xwiki-variables.less, but the mapping was realistic. For example, : * theme.highlightColor took the color of @*-hover elements - we can select one of them (existing table-bg-color, pagination-hover-bg, etc.) * theme.borderColor took the color of @*.border - again we select one that is the best * theme.notification*Color tool the color of @state-*-text * etc. So my solution would be to provide a mapping for the variables. Thanks, Caty
The application will be splited in 2 sections: 1/ a live preview where you can set some variables (what we currenlty have) 2/ a free textarea where the user can fill LESS code (for example, some code downloaded on bootswatch).
But a lot of applications already use the color theme as it is, via the "colorThemeInit.vm" template. So we need a retro-compatibility: a color theme computed by LESS must be usable with old color themes.
Concretly, we will map the old color theme variables to the bootstrap ones, example: $theme.notificationSuccessColor = @brand-success
But because of the section 2 (the free textarea), we are not able to know what will be the final value of a bootstrap variables without parsing the content of the textarea!
What are the options we have: 1/ Implementing our own LESS parser/compiler in Java 2/ Trying to reuse the official LESS Parser through Rhino in a way that we can get the computed variables 3/ Do not parse the input but the ouput: parse the CSS code to get the final values of the variables
I'm for 3.
The idea is to create some CSS classes like this: .colortheme-bordercolor{ color: @border-color; }
which will be converted by LESS to: .colortheme-bordercolor{ color: #000000; }
so we can parse it and know the value of $theme.bordercolor. It is quick, simple, but it pollutes the output CSS a little.
WDYT?
Thanks, Guillaume _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs