[xwiki-devs] [Proposal] Retro-compatibility between Color Theme Application ad Flamingo
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
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. 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) ? 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
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. 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. 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
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
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; } So my parser is able to say "highlightColor" = "#eee". 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
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/xwik... 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
2014-05-28 11:25 GMT+02:00 Marius Dumitru Florea < [email protected]>:
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?
My LESSColorThemeConverter component, that uses a CSS parser inside. I've used CSSOMParser a few times
in the past, such as here
https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik...
Thanks. Actually, I am looking for the correct implementation. I have a prototype which works with a regular expression, an other one with https://code.google.com/p/phloc-css/ and I am looking for https://github.com/phil-brown/jCSS-Parser which has the advantage to not build a big tree of elements but to be a streamable parser. I will look at yours too.
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
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/xwik...
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? 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
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/xwik...
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
On Wed, May 28, 2014 at 3:16 PM, Caleb James DeLisle <[email protected]> wrote:
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/xwik...
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?
Marius: does my explanation make any sense?
Yes, thanks :), it was clear for me already though (as I stated), except for the used CSS 'parser' which Guillaume explained as a reply. Thanks, Marius
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
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. 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-colorth... https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-variabl... 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. 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
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-colorth...
https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-variabl...
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
Hi, +1 in general (we brainstormed about it together with Guillaume actually ;)). Also, do you remove the end part of the CSS that’s not used after the LESS compilation? (I think we should). Thanks -Vincent On 26 May 2014 at 15:49:50, Guillaume Louis-Marie Delhumeau ([email protected](mailto:[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
2014-05-28 17:07 GMT+02:00 [email protected] <[email protected]>:
Hi,
+1 in general (we brainstormed about it together with Guillaume actually ;)).
Also, do you remove the end part of the CSS that’s not used after the LESS compilation? (I think we should).
No. The alternative is to not compile "style.less", but instead "style-simplified.less" that would only contains color-theme special classes. So in the standard style.less, there would be no pollution.
Thanks -Vincent
On 26 May 2014 at 15:49:50, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[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
participants (6)
-
Caleb James DeLisle -
Denis Gervalle -
Ecaterina Moraru (Valica) -
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
vincent＠massol.net