28 May
2014
28 May
'14
1:41 p.m.
Hi
2014-05-28 12:22 GMT+02:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>om>:
On Mon, May 26, 2014 at 4:49 PM, Guillaume
"Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
OK.
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-colort…
https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-variab…
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
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