On Tue, May 27, 2014 at 11:47 AM, Guillaume "Louis-Marie" Delhumeau <[email protected]> wrote: > 2014-05-27 9:56 GMT+02:00 Denis Gervalle <[email protected]>: > >> Hi Guillaume, >> >> Maintaining retro-compatibility for theme using LESS code is too much. >> Maintaining retro compatibility could be simply to support importing >> existing color themes in the new theme system made for bootstrap and no >> more. >> > > Let me show you an example: > The Activity Stream has its own CSS, which does: > > #template('colorThemeInit.vm') > ... > .activityPage:hover , .activityApplication:hover , .activityUser:hover { > background: $theme.highlightColor; > } > ... > > So when my mouse is hovering the AS, its background color change. By > default, it's a kind of yellow. > > Now, if I want to integrate a bootswatch theme, let say 'slate' [1]. I just > copy the LESS files ([2] and [3]) in my textarea. > > It looks very good [4], until my mouse comes over the activity stream... > that becomes yellow! [5] Something needs to be done. >
All clear up to here. > A solution could be to manually fix the colors in the color theme editor > but it defeats the principle to easily integrate a bootstrap kit found on > the web... > > That's why I would like to parse the LESS code. With the solution 3, which > is easy to implement, we have a solution. So you need to set the value of $theme.highlightColor to a color taken from the 'slate' theme (which was taken from bootswatch). I must say I didn't understood very well what you mean by parsing the LESS output. Can you give more details (for solution 3)? Thanks, Marius > > I agree it's not perfect, but it could be a migration path until we change > all the CSS of every applications! > > > >> Regarding the customization of Bootstrap, it exists a couple of tools >> already. It allows far more than just color customization. Have you check >> if one of those existing tools could be adapted (and have appropriate >> license) ? >> > > I am looking at it. Not sure we could find it (easy to integrate, > maintained, compatible with XWiki....). > > Thanks, > Guillaume > > [1] Slate: http://bootswatch.com/slate/ > [2] Slate variables.less: http://bootswatch.com/slate/variables.less > [3] Slate bootswatch.less: http://bootswatch.com/slate/bootswatch.less > [4] Results: > http://tof.canardpc.com/view/7740a7ee-29f4-454f-99e7-f45ef53d9095.jpg > [5] Not good: > http://tof.canardpc.com/view/a23e7101-449d-4fed-a922-cf58323220d3.jpg > > >> >> Thanks, >> >> >> On Mon, May 26, 2014 at 3: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. >> > >> > 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 >> > >> >> >> >> -- >> Denis Gervalle >> SOFTEC sa - CEO >> _______________________________________________ >> 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
