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
<
>> gdelhumeau(a)xwiki.com> 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
>>> devs(a)xwiki.org
>>>
http://lists.xwiki.org/mailman/listinfo/devs
>>>
>>
>>
>>
>> --
>> Denis Gervalle
>> SOFTEC sa - CEO
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>>
http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
>
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org