2014-05-28 14:16 GMT+02:00 Caleb James DeLisle <[email protected]>: > > > On 05/28/2014 11:25 AM, Marius Dumitru Florea wrote: > > On Wed, May 28, 2014 at 12:10 PM, Guillaume "Louis-Marie" Delhumeau > > <[email protected]> wrote: > >> 2014-05-28 10:43 GMT+02:00 Marius Dumitru Florea < > >> [email protected]>: > >> > >>> 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)? > >>> > >> > >> Ok. > >> > >> I have mapped "highlightColor" (color theme variable) to > >> "@nav-link-hover-bg" (bootstrap variable). > >> > >> So, when slat changes @nav-link-hover-bg to gray, I want to be able to > say > >> "$theme.highlightColor" is gray too. > >> > >> How can I do that? > >> > >> 1/ Parsing the LESS file > >> or > >> 2/ Parsing the CSS output file > >> > >> I am prototyping the method 2. > >> > >> Concretly, at the end of my style.less file, I add: > >> > >> /* this class is actually useless for the browser */ > >> .colortheme-highlightColor{ > >> color: @nav-link-hover-bg; > >> } > >> > >> > >> LESS transforms it to: > >> > >> .colortheme-highlightColor{ > >> color: #eee; > >> } > >> > >> Now, my parser looks at every classes starting by ".colortheme-". The > >> mapping looks like this: > >> > >> .colortheme-NAME_OF_THE_VARIABLE{ > >> color: VALUE_OF_THE_VARIABLE; > >> } > >> > > > > All clear. > > > >> So my parser is able to say "highlightColor" = "#eee". > > > > WDYM by "my parser"? The CSS parser? I've used CSSOMParser a few times > > in the past, such as here > > > https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-rendering/xwiki-platform-rendering-xwiki/src/main/java/org/xwiki/rendering/internal/wiki/XWikiWikiModel.java#L125 > > > Guillaume ran his explanation by me to verify that he was explaining > it reasonably well. I thought I'd throw my understanding in to see if > it helps. > > I gather there's a need to update a few velocity variables from CSS, > this is because all of the old extensions depend on these variables > and if they're not updated according to the CSS then the old applications > will look hilarious when used with the new skin. > > Even if we hooked into the colortheme editor and trapped the changes > to the theme to update the old variables, this would not allow us to > pull in bootstrap themes from around the internet by pasting in the LESS > code. > > Guillaume's solution was to add some special LESS code which assigns > the desired values to a set of uniquely named classes and then *grep* > the output CSS for those classes and copy over the values. > > Something like: > word = cssOutput.indexOf(".colortheme-magic-class-21246798237"); > begin = cssOutput.indexOf('{', word); > end = cssOutput.indexOf('}', begin); > > A fairly clever method of making XWiki compatible with arbitrary > LESS code and arbitrary bootstrap themes and +1 for me. > > Guillaume: did I understand this properly? >
Yes you did, thanks ! Except that I eventually implemented it with a regexp (but it could be changed to a real CSS parser afterwards...). > Marius: does my explanation make any sense? > > Thanks, > Caleb > > > > > > Hope this helps, > > Marius > > > >> > >> I agree... it looks like a hack. But it is the simplest way I have > found to > >> compute the color theme from a LESS file... > >> > >> > >> > >>> > >>> 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 > >>> > >> _______________________________________________ > >> 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
