Hi 2014-05-28 12:22 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
> 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. > OK. > > 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-colortheme.less > > https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-variables.less > > 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. > Yes, and it is also what I propose. The only problem is that we wanted to be able to use bootstrap kits such as bootswatch, so I have proposed to add a textarea to write less code directly in the color theme. [ http://xwiki.markmail.org/thread/cvfvbrldneg67lmf ] The problem is, even if you have decided that $theme.buttonPrimaryBackgroundColor correspond to @brand-primary, how do you get the actual value of @brand-primary? If @brand-primary is darken(#00FF00), what is the plain CSS result that I should set to $theme.buttonPrimaryBackgroundColor ? BTW, we do not have integrated LESS inside Skin Extension ($xwiki.ssx), so we cannot use LESS variables directly there... That is why I am proposing to add a new component which is able to parse a compiled LESS file and to set values to the color theme variables depending on that. Actually, in colorThemeInit.vm, I add this code: #set($theme2 = $services.lesscss.getColorThemeFromSkinFile("style.less")) #foreach($key in $theme2.keySet()) #set($discard = $theme.put($key, $theme2.get($key))) #end Whis is what getColorThemeFromSkinFile does: 1 - style.less is transformed to CSS 2 - the CSS is parsed to detect the color theme variables And it works :) > > 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 > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
