11 Jun
2014
11 Jun
'14
5:43 p.m.
Hi devs.
I am implementing the Color Theme Editor for Flamingo! And this is a
preview:
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
Since the current color theme application is strongly linked to Colibri,
and the new application will be strongly linked to Flamingo, I propose the
following:
1/ move xwiki-platform-colorthemes in xwiki-platform-colibri and state that
this application is only compatible with colibri-based skin.
2/ create the new application in xwiki-platform-flamingo
3/ the new color theme application will actually propose more than colors
(fonts, less code, etc...), so I propose to call it
xwiki-platform-flamingo-themes.
4/ in the administration, we have a page that propose which color theme we
want to use. Since the new application will not be compatible with the old
one, I propose to add an extension point (such as what we have to configure
search suggest sources) in order to propose the themes corresponding to the
selected skin (ie: xobjects of ColorThemes.ColorThemeClass for colibri and
skins based on colibri, and xobjects of FlamingoThemeCode.ThemeClass for
flamingo).
5/ modify SkinAction that currenlty executes velocity code on a skin file
if the mime type is CSS or JS, to also execute velocity on files suffixed
by .less.vm, because I need it for my application. To see what it looks
like, please look at
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
. The alternative is to create a new action which is too much IMO.
6/ when colibri will be deprecated on removed from XE, we will do the same
for the old color theme application.
WDYT?
Thanks,
Guillaume
11 Jun
11 Jun
5:51 p.m.
I have not read all of the code but I'm +1 to the principle, including the
skin action change which makes logical sense.
Are you planning on pushing this into 6.1M2 ?
Thanks,
Caleb
On 06/11/2014 05:43 PM, Guillaume "Louis-Marie" Delhumeau wrote:
Hi devs.
I am implementing the Color Theme Editor for Flamingo! And this is a
preview:
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
Since the current color theme application is strongly linked to Colibri,
and the new application will be strongly linked to Flamingo, I propose the
following:
1/ move xwiki-platform-colorthemes in xwiki-platform-colibri and state that
this application is only compatible with colibri-based skin.
2/ create the new application in xwiki-platform-flamingo
3/ the new color theme application will actually propose more than colors
(fonts, less code, etc...), so I propose to call it
xwiki-platform-flamingo-themes.
4/ in the administration, we have a page that propose which color theme we
want to use. Since the new application will not be compatible with the old
one, I propose to add an extension point (such as what we have to configure
search suggest sources) in order to propose the themes corresponding to the
selected skin (ie: xobjects of ColorThemes.ColorThemeClass for colibri and
skins based on colibri, and xobjects of FlamingoThemeCode.ThemeClass for
flamingo).
5/ modify SkinAction that currenlty executes velocity code on a skin file
if the mime type is CSS or JS, to also execute velocity on files suffixed
by .less.vm, because I need it for my application. To see what it looks
like, please look at
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
. The alternative is to create a new action which is too much IMO.
6/ when colibri will be deprecated on removed from XE, we will do the same
for the old color theme application.
WDYT?
Thanks,
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:33 p.m.
New subject: [xwiki-devs] [Proposal] Link the color theme application to the skin
2014-06-11 17:51 GMT+02:00 Caleb James DeLisle <cjd(a)cjdns.fr>fr>:
I have not read all of the code but I'm +1 to the
principle, including the
skin action change which makes logical sense.
Are you planning on pushing this into 6.1M2 ?
No, it will be for RC1.
Thanks,
Caleb
Thanks,
Guillaume
On 06/11/2014 05:43 PM, Guillaume "Louis-Marie" Delhumeau wrote:
Hi devs.
I am implementing the Color Theme Editor for Flamingo! And this is a
preview:
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
Since the current color theme application is strongly linked to Colibri,
and the new application will be strongly linked to Flamingo, I propose
the
following:
1/ move xwiki-platform-colorthemes in xwiki-platform-colibri and state
that
this application is only compatible with
colibri-based skin.
2/ create the new application in xwiki-platform-flamingo
3/ the new color theme application will actually propose more than colors
(fonts, less code, etc...), so I propose to call it
xwiki-platform-flamingo-themes.
4/ in the administration, we have a page that propose which color theme
we
want to use. Since the new application will not
be compatible with the
old
one, I propose to add an extension point (such as
what we have to
configure
search suggest sources) in order to propose the
themes corresponding to
the
selected skin (ie: xobjects of
ColorThemes.ColorThemeClass for colibri
and
skins based on colibri, and xobjects of
FlamingoThemeCode.ThemeClass for
flamingo).
5/ modify SkinAction that currenlty executes velocity code on a skin file
if the mime type is CSS or JS, to also execute velocity on files suffixed
by .less.vm, because I need it for my application. To see what it looks
like, please look at
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
. The alternative is to create a new action which
is too much IMO.
6/ when colibri will be deprecated on removed from XE, we will do the
same
for the old color theme application.
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
9:26 p.m.
New subject: [xwiki-devs] [Proposal] Link the color theme application to the skin
There are currently many places (both in platform and in extensions)
where we use color theme properties such as
$theme.pageContentBackgroundColor . Does FlamingoThemeCode.ThemeClass
have completely different properties? I hope not. I'm looking at the
ColorThemeClass and most of its properties seem pretty generic, i.e.
skin independent. Which ones are skin dependent?
Also,
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
shows that FlamingoThemeCode.ThemeClass has only two properties?
body-bg and text-color, both present with a different name in
ColorThemeClass.
Thanks,
Marius
On Wed, Jun 11, 2014 at 6:43 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
Hi devs.
I am implementing the Color Theme Editor for Flamingo! And this is a
preview:
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
Since the current color theme application is strongly linked to Colibri,
and the new application will be strongly linked to Flamingo, I propose the
following:
1/ move xwiki-platform-colorthemes in xwiki-platform-colibri and state that
this application is only compatible with colibri-based skin.
2/ create the new application in xwiki-platform-flamingo
3/ the new color theme application will actually propose more than colors
(fonts, less code, etc...), so I propose to call it
xwiki-platform-flamingo-themes.
4/ in the administration, we have a page that propose which color theme we
want to use. Since the new application will not be compatible with the old
one, I propose to add an extension point (such as what we have to configure
search suggest sources) in order to propose the themes corresponding to the
selected skin (ie: xobjects of ColorThemes.ColorThemeClass for colibri and
skins based on colibri, and xobjects of FlamingoThemeCode.ThemeClass for
flamingo).
5/ modify SkinAction that currenlty executes velocity code on a skin file
if the mime type is CSS or JS, to also execute velocity on files suffixed
by .less.vm, because I need it for my application. To see what it looks
like, please look at
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
. The alternative is to create a new action which is too much IMO.
6/ when colibri will be deprecated on removed from XE, we will do the same
for the old color theme application.
WDYT?
Thanks,
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12 Jun
12 Jun
9:41 a.m.
New subject: [xwiki-devs] [Proposal] Link the color theme application to the skin
Hi Marius,
2014-06-11 21:26 GMT+02:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
There are currently many places (both in platform and
in extensions)
where we use color theme properties such as
$theme.pageContentBackgroundColor .
For them, I have written a retro-compatibility component that computes the
color themes variables from the style.css generated by Flamingo. It
actually does a mapping between bootstrap variables and old color theme
variables. It is not perfect, but at least it does not break the whole UI.
Does FlamingoThemeCode.ThemeClass
have completely different properties? I hope not. I'm looking at the
ColorThemeClass and most of its properties seem pretty generic, i.e.
skin independent. Which ones are skin dependent?
First, the preview section is completely skin dependent (see:
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/C…
).
Then, the new theme editor will propose to customize a set of variables
specific to bootstrap, just like:
http://fancyboot.designspebam.com/
We are exposing the BS variables because it is flexible and powerful.
Mixing old color theme variables and bootstrap variables will not resulting
to a consistent set of variables, so that is why I am proposing to separate
the 2 cases.
BTW, old color themes are still compatibles with Flamingo, because we have
a binding between the old color theme variables and the bootstrap
variables, but it is far from perfect.
Also,
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
shows that FlamingoThemeCode.ThemeClass has only two properties?
body-bg and text-color, both present with a different name in
ColorThemeClass.
When I have posted the link above, I only wanted to show you the
modifications done on SkinAction.java. Of course, ThemeClass will not have
only two properties! This commit is a first step to have a proof of concept.
If you want to have the list of bootstrap variables, you could see there:
http://getbootstrap.com/customize/#less-variables
Of course we won't expose all these variables: it would be confusing for
the end user. We have to chose some of them. If the user wants to customize
variables that are not exposed, she can do that with the textarea field
where she can write LESS code.
Thanks,
Marius
On Wed, Jun 11, 2014 at 6:43 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
Thanks,
Guillaume
Hi devs.
I am implementing the Color Theme Editor for Flamingo! And this is a
preview:
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
Since the current color theme application is strongly linked to Colibri,
and the new application will be strongly linked to Flamingo, I propose
the
following:
1/ move xwiki-platform-colorthemes in xwiki-platform-colibri and state
that
this application is only compatible with
colibri-based skin.
2/ create the new application in xwiki-platform-flamingo
3/ the new color theme application will actually propose more than colors
(fonts, less code, etc...), so I propose to call it
xwiki-platform-flamingo-themes.
4/ in the administration, we have a page that propose which color theme
we
want to use. Since the new application will not
be compatible with the
old
one, I propose to add an extension point (such as
what we have to
configure
search suggest sources) in order to propose the
themes corresponding to
the
selected skin (ie: xobjects of
ColorThemes.ColorThemeClass for colibri
and
skins based on colibri, and xobjects of
FlamingoThemeCode.ThemeClass for
flamingo).
5/ modify SkinAction that currenlty executes velocity code on a skin file
if the mime type is CSS or JS, to also execute velocity on files suffixed
by .less.vm, because I need it for my application. To see what it looks
like, please look at
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
. The alternative is to create a new action which
is too much IMO.
6/ when colibri will be deprecated on removed from XE, we will do the
same
for the old color theme application.
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
9:44 a.m.
New subject: [xwiki-devs] [Proposal] Link the color theme application to the skin
On Thu, Jun 12, 2014 at 9:41 AM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
--
Thomas Mortagne
Hi Marius,
2014-06-11 21:26 GMT+02:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
IMO the real question here was: so we don't have any cross skin
standard anymore ? Or is it bootstrap now ?
There are currently many places (both in platform
and in extensions)
where we use color theme properties such as
$theme.pageContentBackgroundColor .
For them, I have written a retro-compatibility component that computes the
color themes variables from the style.css generated by Flamingo. It
actually does a mapping between bootstrap variables and old color theme
variables. It is not perfect, but at least it does not break the whole UI. Does FlamingoThemeCode.ThemeClass
have completely different properties? I hope not. I'm looking at the
ColorThemeClass and most of its properties seem pretty generic, i.e.
skin independent. Which ones are skin dependent?
First, the preview section is completely skin dependent (see:
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/C…
).
Then, the new theme editor will propose to customize a set of variables
specific to bootstrap, just like:
http://fancyboot.designspebam.com/
We are exposing the BS variables because it is flexible and powerful.
Mixing old color theme variables and bootstrap variables will not resulting
to a consistent set of variables, so that is why I am proposing to separate
the 2 cases.
BTW, old color themes are still compatibles with Flamingo, because we have
a binding between the old color theme variables and the bootstrap
variables, but it is far from perfect.
Also,
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
shows that FlamingoThemeCode.ThemeClass has only two properties?
body-bg and text-color, both present with a different name in
ColorThemeClass.
When I have posted the link above, I only wanted to show you the
modifications done on SkinAction.java. Of course, ThemeClass will not have
only two properties! This commit is a first step to have a proof of concept.
If you want to have the list of bootstrap variables, you could see there:
http://getbootstrap.com/customize/#less-variables
Of course we won't expose all these variables: it would be confusing for
the end user. We have to chose some of them. If the user wants to customize
variables that are not exposed, she can do that with the textarea field
where she can write LESS code.
Thanks,
Marius
On Wed, Jun 11, 2014 at 6:43 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
Thanks,
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi devs.
I am implementing the Color Theme Editor for Flamingo! And this is a
preview:
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
Since the current color theme application is strongly linked to Colibri,
and the new application will be strongly linked to Flamingo, I propose
the
following:
1/ move xwiki-platform-colorthemes in xwiki-platform-colibri and state
that
this application is only compatible with
colibri-based skin.
2/ create the new application in xwiki-platform-flamingo
3/ the new color theme application will actually propose more than colors
(fonts, less code, etc...), so I propose to call it
xwiki-platform-flamingo-themes.
4/ in the administration, we have a page that propose which color theme
we
want to use. Since the new application will not
be compatible with the
old
one, I propose to add an extension point (such as
what we have to
configure
search suggest sources) in order to propose the
themes corresponding to
the
selected skin (ie: xobjects of
ColorThemes.ColorThemeClass for colibri
and
skins based on colibri, and xobjects of
FlamingoThemeCode.ThemeClass for
flamingo).
5/ modify SkinAction that currenlty executes velocity code on a skin file
if the mime type is CSS or JS, to also execute velocity on files suffixed
by .less.vm, because I need it for my application. To see what it looks
like, please look at
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
. The alternative is to create a new action which
is too much IMO.
6/ when colibri will be deprecated on removed from XE, we will do the
same
for the old color theme application.
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
10:05 a.m.
New subject: [xwiki-devs] [Proposal] Link the color theme application to the skin
That is a good question.
Since we have the retro-compatibility component, we could still continue tu
use old color theme variables in our UIs, but if we deprecate colibri and
the color theme application, it would be weird then.
One of the benefits of using Bootstrap, it's the fact that it is becoming a
famous framework that can become "our" standard.
The drawback that I see, it's that we cannot be sure that the variables
will stay the same in Bootstrap 4.x, as Bootstrap 3.x is already not
compatible with Bootstrap 2.x.
2014-06-12 9:44 GMT+02:00 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
On Thu, Jun 12, 2014 at 9:41 AM, Guillaume
"Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/C…
have
Thanks,
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi Marius,
2014-06-11 21:26 GMT+02:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
the
There are currently many places (both in platform
and in extensions)
where we use color theme properties such as
$theme.pageContentBackgroundColor .
For them, I have written a retro-compatibility component that computes color themes variables from the style.css
generated by Flamingo. It
actually does a mapping between bootstrap variables and old color theme
variables. It is not perfect, but at least it does not break the whole
UI.
IMO the real question here was: so we don't have any cross skin
standard anymore ? Or is it bootstrap now ?
Does FlamingoThemeCode.ThemeClass
have completely different properties? I hope not. I'm looking at the
ColorThemeClass and most of its properties seem pretty generic, i.e.
skin independent. Which ones are skin dependent?
First, the preview section is completely skin dependent (see:
).
Then, the new theme editor will propose to customize a set of variables
specific to bootstrap, just like:
http://fancyboot.designspebam.com/
We are exposing the BS variables because it is flexible and powerful.
Mixing old color theme variables and bootstrap variables will not
resulting
to a consistent set of variables, so that is why
I am proposing to
separate
the 2 cases.
BTW, old color themes are still compatibles with Flamingo, because we
have
a binding between the old color theme variables
and the bootstrap
variables, but it is far from perfect.
>
> Also,
>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
shows
that FlamingoThemeCode.ThemeClass has only two properties?
body-bg and text-color, both present with a different name in
ColorThemeClass.
When I have posted the link above, I only wanted to show you the
modifications done on SkinAction.java. Of course, ThemeClass will not only two properties! This commit is a first step
to have a proof of
concept.
If you want to have the list of bootstrap variables, you could see there:
http://getbootstrap.com/customize/#less-variables
Of course we won't expose all these variables: it would be confusing for
the end user. We have to chose some of them. If the user wants to
customize
variables that are not exposed, she can do that
with the textarea field
where she can write LESS code.
>
> Thanks,
> Marius
>
> On Wed, Jun 11, 2014 at 6:43 PM, Guillaume "Louis-Marie" Delhumeau
> <gdelhumeau(a)xwiki.com> wrote:
> > Hi devs.
> >
> > I am implementing the Color Theme Editor for Flamingo! And this is a
> > preview:
> >
>
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
> >
> > Since the current color theme application is strongly linked to
Colibri,
> > and the new application will be strongly
linked to Flamingo, I propose
> the
> > following:
> >
> > 1/ move xwiki-platform-colorthemes in xwiki-platform-colibri and state
> that
> > this application is only compatible with colibri-based skin.
> > 2/ create the new application in xwiki-platform-flamingo
> > 3/ the new color theme application will actually propose more than
colors
> > (fonts, less code, etc...), so I propose
to call it
> > xwiki-platform-flamingo-themes.
> > 4/ in the administration, we have a page that propose which color
theme
> we
> > want to use. Since the new application will not be compatible with the
> old
> > one, I propose to add an extension point (such as what we have to
> configure
> > search suggest sources) in order to propose the themes corresponding
to
> the
> > selected skin (ie: xobjects of ColorThemes.ColorThemeClass for colibri
> and
> > skins based on colibri, and xobjects of FlamingoThemeCode.ThemeClass
for
> > flamingo).
> > 5/ modify SkinAction that currenlty executes velocity code on a skin
file
> > if the mime type is CSS or JS, to also
execute velocity on files
suffixed
> > by .less.vm, because I need it for my
application. To see what it
looks
> > like, please look at
> >
>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
. The alternative is to create a new action which is
too much IMO.
6/ when colibri will be deprecated on removed from XE, we will do the
same
for the old color theme application.
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
10:06 a.m.
New subject: [xwiki-devs] [Proposal] Link the color theme application to the skin
On Thu, Jun 12, 2014 at 10:41 AM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
> Then, the new theme editor will propose to customize a set of variables
> specific to bootstrap, just like:
> http://fancyboot.designspebam.com/
> We are exposing the BS variables because it
is flexible and powerful.
> Mixing old color theme variables and bootstrap variables will not resulting
> to a consistent set of variables, so that is why I am proposing to separate
> the 2 cases.
So the reason is not because the current color theme properties are
skin dependent but because we want to use the bootstrap 'properties'
(some of which are in the current color theme but with a different
name?).
Thanks,
Marius
> BTW, old color themes are still compatibles
with Flamingo, because we have
> a binding between the old color theme variables and the bootstrap
> variables, but it is far from perfect.
> >> Also,
>>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
>> shows that FlamingoThemeCode.ThemeClass has only two properties?
>> body-bg and text-color, both present with a different name in
>> ColorThemeClass.
>
> When I have posted the link above, I only wanted to show you the
> modifications done on SkinAction.java. Of course, ThemeClass will not have
> only two properties! This commit is a first step to have a proof of concept.
> If you want to have the list of bootstrap
variables, you could see there:
> http://getbootstrap.com/customize/#less-variables
> Of course we won't expose all these
variables: it would be confusing for
> the end user. We have to chose some of them. If the user wants to customize
> variables that are not exposed, she can do that with the textarea field
> where she can write LESS code.
> >> Thanks,
>> Marius
> >> On Wed, Jun 11, 2014 at 6:43 PM,
Guillaume "Louis-Marie" Delhumeau
>> <gdelhumeau(a)xwiki.com> wrote:
>> > Hi devs.
>> >> > I am
implementing the Color Theme Editor for Flamingo! And this is a
>> > preview:
>> >>
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
>> >> > Since
the current color theme application is strongly linked to Colibri,
>> > and the new application will be strongly linked to Flamingo, I propose
>> the
>> > following:
>> >> > 1/ move
xwiki-platform-colorthemes in xwiki-platform-colibri and state
>> that
>> > this application is only compatible with colibri-based skin.
>> > 2/ create the new application in xwiki-platform-flamingo
>> > 3/ the new color theme application will actually propose more than colors
>> > (fonts, less code, etc...), so I propose to call it
>> > xwiki-platform-flamingo-themes.
>> > 4/ in the administration, we have a page that propose which color theme
>> we
>> > want to use. Since the new application will not be compatible with the
>> old
>> > one, I propose to add an extension point (such as what we have to
>> configure
>> > search suggest sources) in order to propose the themes corresponding to
>> the
>> > selected skin (ie: xobjects of ColorThemes.ColorThemeClass for colibri
>> and
>> > skins based on colibri, and xobjects of FlamingoThemeCode.ThemeClass for
>> > flamingo).
>> > 5/ modify SkinAction that currenlty executes velocity code on a skin file
>> > if the mime type is CSS or JS, to also execute velocity on files suffixed
>> > by .less.vm, because I need it for my application. To see what it looks
>> > like, please look at
>> >>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
>> > . The alternative is to create a new action which is too much IMO.
>> > 6/ when colibri will be deprecated on removed from XE, we will do the
>> same
>> > for the old color theme application.
>> >> > 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
>
> Thanks,
> Guillaume
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
Hi Marius,
2014-06-11 21:26 GMT+02:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
There are currently many places (both in platform
and in extensions)
where we use color theme properties such as
$theme.pageContentBackgroundColor .
For them, I have written a retro-compatibility component that computes the
color themes variables from the style.css generated by Flamingo. It
actually does a mapping between bootstrap variables and old color theme
variables. It is not perfect, but at least it does not break the whole UI.
Does FlamingoThemeCode.ThemeClass
have completely different properties? I hope not. I'm looking at the
ColorThemeClass and most of its properties seem pretty generic, i.e.
skin independent. Which ones are skin dependent?
First, the preview section is completely skin
dependent (see:
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/C…
).
My question was not about the UI. I was talking strictly about the
'data'. A color theme is defined by a map of (property, value) pairs.
The current color theme definition has some properties that are (I
think) widely used. You propose a new color theme definition that has
different properties. The reason is, you say, because the current
color theme properties are skin dependent. I don't find this true, at
least not entirely. Most of the current color theme properties seem
skin independent to me, that's why I asked you to list the properties
that you view as skin dependent.
10:10 a.m.
New subject: [xwiki-devs] [Proposal] Link the color theme application to the skin
2014-06-12 10:06 GMT+02:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
On Thu, Jun 12, 2014 at 10:41 AM, Guillaume
"Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
> Then, the new theme editor will propose to customize a set of variables
> specific to bootstrap, just like:
> http://fancyboot.designspebam.com/
> We are exposing the BS variables
because it is flexible and powerful.
> Mixing old color theme variables and bootstrap variables will not
resulting
Yes.
The alternative is to not expose BS variables but only our already defined
variables and have an internal mapping between our variables and the
bootstrap ones. It would be less flexible, but we would still have the
textarea field to write LESS code if it is not enough. This alternative is
only about changing the UI, and not the data.
Hi Marius,
2014-06-11 21:26 GMT+02:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
the
There are currently many places (both in platform
and in extensions)
where we use color theme properties such as
$theme.pageContentBackgroundColor .
For them, I have written a retro-compatibility component that computes color themes variables from the style.css
generated by Flamingo. It
actually does a mapping between bootstrap variables and old color theme
variables. It is not perfect, but at least it does not break the whole
UI.
Does FlamingoThemeCode.ThemeClass
have completely different properties? I hope not. I'm looking at the
ColorThemeClass and most of its properties seem pretty generic, i.e.
skin independent. Which ones are skin dependent?
First, the preview section is completely skin
dependent (see:
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/C…
).
My question was not about the UI. I was talking strictly about the
'data'. A color theme is defined by a map of (property, value) pairs.
The current color theme definition has some properties that are (I
think) widely used. You propose a new color theme definition that has
different properties. The reason is, you say, because the current
color theme properties are skin dependent. I don't find this true, at
least not entirely. Most of the current color theme properties seem
skin independent to me, that's why I asked you to list the properties
that you view as skin dependent.
to a consistent set of variables, so that is why
I am proposing to
separate
the 2 cases.
So the reason is not because the current color theme properties are
skin dependent but because we want to use the bootstrap 'properties'
(some of which are in the current color theme but with a different
name?).
Thanks,
Marius
have
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
BTW, old color themes are still compatibles with Flamingo, because we
have
a binding between the old color theme variables
and the bootstrap
variables, but it is far from perfect.
>
> Also,
>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
shows
that FlamingoThemeCode.ThemeClass has only two properties?
body-bg and text-color, both present with a different name in
ColorThemeClass.
When I have posted the link above, I only wanted to show you the
modifications done on SkinAction.java. Of course, ThemeClass will not only two properties! This commit is a first step
to have a proof of
concept.
If you want to have the list of bootstrap variables, you could see there:
http://getbootstrap.com/customize/#less-variables
Of course we won't expose all these variables: it would be confusing for
the end user. We have to chose some of them. If the user wants to
customize
variables that are not exposed, she can do that
with the textarea field
where she can write LESS code.
>
> Thanks,
> Marius
>
> On Wed, Jun 11, 2014 at 6:43 PM, Guillaume "Louis-Marie" Delhumeau
> <gdelhumeau(a)xwiki.com> wrote:
> > Hi devs.
> >
> > I am implementing the Color Theme Editor for Flamingo! And this is a
> > preview:
> >
>
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
> >
> > Since the current color theme application is strongly linked to
Colibri,
> > and the new application will be strongly
linked to Flamingo, I propose
> the
> > following:
> >
> > 1/ move xwiki-platform-colorthemes in xwiki-platform-colibri and state
> that
> > this application is only compatible with colibri-based skin.
> > 2/ create the new application in xwiki-platform-flamingo
> > 3/ the new color theme application will actually propose more than
colors
> > (fonts, less code, etc...), so I propose
to call it
> > xwiki-platform-flamingo-themes.
> > 4/ in the administration, we have a page that propose which color
theme
> we
> > want to use. Since the new application will not be compatible with the
> old
> > one, I propose to add an extension point (such as what we have to
> configure
> > search suggest sources) in order to propose the themes corresponding
to
> the
> > selected skin (ie: xobjects of ColorThemes.ColorThemeClass for colibri
> and
> > skins based on colibri, and xobjects of FlamingoThemeCode.ThemeClass
for
> > flamingo).
> > 5/ modify SkinAction that currenlty executes velocity code on a skin
file
> > if the mime type is CSS or JS, to also
execute velocity on files
suffixed
> > by .less.vm, because I need it for my
application. To see what it
looks
> > like, please look at
> >
>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
. The alternative is to create a new action which is
too much IMO.
6/ when colibri will be deprecated on removed from XE, we will do the
same
for the old color theme application.
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
10:21 a.m.
New subject: [xwiki-devs] [Proposal] Link the color theme application to the skin
On Thu, Jun 12, 2014 at 11:10 AM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
2014-06-12 10:06 GMT+02:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
I don't have a strong opinion. Since we're gong to standardise our UI
around BS then I guess it's fine to use directly the BS variables for
the new color themes.
Thanks,
Marius
On Thu, Jun 12, 2014 at 10:41 AM, Guillaume
"Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
> Then, the new theme editor will propose to customize a set of variables
> specific to bootstrap, just like:
> http://fancyboot.designspebam.com/
> We are exposing the BS variables
because it is flexible and powerful.
> Mixing old color theme variables and bootstrap variables will not
resulting
Yes.
The alternative is to not expose BS variables but only our already defined
variables and have an internal mapping between our variables and the
bootstrap ones. It would be less flexible, but we would still have the
textarea field to write LESS code if it is not enough. This alternative is
only about changing the UI, and not the data. Hi Marius,
2014-06-11 21:26 GMT+02:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
the
There are currently many places (both in platform
and in extensions)
where we use color theme properties such as
$theme.pageContentBackgroundColor .
For them, I have written a retro-compatibility component that computes color themes variables from the style.css
generated by Flamingo. It
actually does a mapping between bootstrap variables and old color theme
variables. It is not perfect, but at least it does not break the whole
UI.
Does FlamingoThemeCode.ThemeClass
have completely different properties? I hope not. I'm looking at the
ColorThemeClass and most of its properties seem pretty generic, i.e.
skin independent. Which ones are skin dependent?
First, the preview section is completely skin
dependent (see:
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/C…
).
My question was not about the UI. I was talking strictly about the
'data'. A color theme is defined by a map of (property, value) pairs.
The current color theme definition has some properties that are (I
think) widely used. You propose a new color theme definition that has
different properties. The reason is, you say, because the current
color theme properties are skin dependent. I don't find this true, at
least not entirely. Most of the current color theme properties seem
skin independent to me, that's why I asked you to list the properties
that you view as skin dependent.
to a consistent set of variables, so that is why
I am proposing to
separate
the 2 cases.
So the reason is not because the current color theme properties are
skin dependent but because we want to use the bootstrap 'properties'
(some of which are in the current color theme but with a different
name?).
Thanks,
Marius
have
_______________________________________________
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
BTW, old color themes are still compatibles with Flamingo, because we
have
a binding between the old color theme variables
and the bootstrap
variables, but it is far from perfect.
>
> Also,
>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
shows
that FlamingoThemeCode.ThemeClass has only two properties?
body-bg and text-color, both present with a different name in
ColorThemeClass.
When I have posted the link above, I only wanted to show you the
modifications done on SkinAction.java. Of course, ThemeClass will not only two properties! This commit is a first step
to have a proof of
concept.
If you want to have the list of bootstrap variables, you could see there:
http://getbootstrap.com/customize/#less-variables
Of course we won't expose all these variables: it would be confusing for
the end user. We have to chose some of them. If the user wants to
customize
variables that are not exposed, she can do that
with the textarea field
where she can write LESS code.
>
> Thanks,
> Marius
>
> On Wed, Jun 11, 2014 at 6:43 PM, Guillaume "Louis-Marie" Delhumeau
> <gdelhumeau(a)xwiki.com> wrote:
> > Hi devs.
> >
> > I am implementing the Color Theme Editor for Flamingo! And this is a
> > preview:
> >
>
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
> >
> > Since the current color theme application is strongly linked to
Colibri,
> > and the new application will be strongly
linked to Flamingo, I propose
> the
> > following:
> >
> > 1/ move xwiki-platform-colorthemes in xwiki-platform-colibri and state
> that
> > this application is only compatible with colibri-based skin.
> > 2/ create the new application in xwiki-platform-flamingo
> > 3/ the new color theme application will actually propose more than
colors
> > (fonts, less code, etc...), so I propose
to call it
> > xwiki-platform-flamingo-themes.
> > 4/ in the administration, we have a page that propose which color
theme
> we
> > want to use. Since the new application will not be compatible with the
> old
> > one, I propose to add an extension point (such as what we have to
> configure
> > search suggest sources) in order to propose the themes corresponding
to
> the
> > selected skin (ie: xobjects of ColorThemes.ColorThemeClass for colibri
> and
> > skins based on colibri, and xobjects of FlamingoThemeCode.ThemeClass
for
> > flamingo).
> > 5/ modify SkinAction that currenlty executes velocity code on a skin
file
> > if the mime type is CSS or JS, to also
execute velocity on files
suffixed
> > by .less.vm, because I need it for my
application. To see what it
looks
> > like, please look at
> >
>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
> .
The alternative is to create a new action which is too much IMO.
> 6/ when colibri will be deprecated on removed from XE, we will do the
same
> for the old color theme application.
>
> 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
Thanks,
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:09 p.m.
New subject: [xwiki-devs] [Proposal] Link the color theme application to the skin
BTW, I first planned to implement this for RC1.
Do you see, guys, any inconvenient for writing such an application + modify
the administration-ui in a RC?
If there is, then I need a milestone 3, or pushing it for 6.2.
Thanks,
Guillaume
2014-06-12 10:21 GMT+02:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
On Thu, Jun 12, 2014 at 11:10 AM, Guillaume
"Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
Yes.
The alternative is to not expose BS variables but only our already defined
_______________________________________________
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
2014-06-12 10:06 GMT+02:00 Marius Dumitru Florea
<
mariusdumitru.florea(a)xwiki.com>gt;:
> On Thu, Jun 12, 2014 at 10:41 AM, Guillaume "Louis-Marie" Delhumeau
> <gdelhumeau(a)xwiki.com> wrote:
> > Hi Marius,
> >
> >
> > 2014-06-11 21:26 GMT+02:00 Marius Dumitru Florea <
> > mariusdumitru.florea(a)xwiki.com>gt;:
> >
> >> There are currently many places (both in platform and in extensions)
> >> where we use color theme properties such as
> >> $theme.pageContentBackgroundColor .
> >
> >
> > For them, I have written a retro-compatibility component that computes
> the
> > color themes variables from the style.css generated by Flamingo. It
> > actually does a mapping between bootstrap variables and old color
theme
> > variables. It is not perfect, but at
least it does not break the whole
> UI.
> >
> >
> >> Does FlamingoThemeCode.ThemeClass
> >> have completely different properties? I hope not. I'm looking at the
> >> ColorThemeClass and most of its properties seem pretty generic, i.e.
> >> skin independent. Which ones are skin dependent?
> >>
> >
>
> > First, the preview section is completely skin dependent (see:
> >
>
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/C…
> > ).
>
> My question was not about the UI. I was talking strictly about the
> 'data'. A color theme is defined by a map of (property, value) pairs.
> The current color theme definition has some properties that are (I
> think) widely used. You propose a new color theme definition that has
> different properties. The reason is, you say, because the current
> color theme properties are skin dependent. I don't find this true, at
> least not entirely. Most of the current color theme properties seem
> skin independent to me, that's why I asked you to list the properties
> that you view as skin dependent.
>
> >
>
> > Then, the new theme editor will propose to customize a set of
variables
specific to bootstrap, just like:
http://fancyboot.designspebam.com/
We are exposing the BS variables because it is flexible and powerful.
Mixing old color theme variables and bootstrap variables will not
resulting
to a consistent set of variables, so that is why
I am proposing to
separate
the 2 cases.
So the reason is not because the current color theme properties are
skin dependent but because we want to use the bootstrap 'properties'
(some of which are in the current color theme but with a different
name?).
variables and have an internal mapping between
our variables and the
bootstrap ones. It would be less flexible, but we would still have the
textarea field to write LESS code if it is not enough. This alternative
is
only about changing the UI, and not the data.
I don't have a strong opinion. Since we're gong to standardise our UI
around BS then I guess it's fine to use directly the BS variables for
the new color themes.
Thanks,
Marius
>
> Thanks,
> Marius
>
> >
> > BTW, old color themes are still compatibles with Flamingo, because we
> have
> > a binding between the old color theme variables and the bootstrap
> > variables, but it is far from perfect.
> >
> >
> >>
> >> Also,
> >>
>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
> >> shows that
FlamingoThemeCode.ThemeClass has only two properties?
> >> body-bg and text-color, both present with a different name in
> >> ColorThemeClass.
> >>
> >
> > When I have posted the link above, I only wanted to show you the
> > modifications done on SkinAction.java. Of course, ThemeClass will not
> have
> > only two properties! This commit is a first step to have a proof of
> concept.
> >
> > If you want to have the list of bootstrap variables, you could see
there:
> >
http://getbootstrap.com/customize/#less-variables
> >
> > Of course we won't expose all these variables: it would be confusing
for
> > the end user. We have to chose some of
them. If the user wants to
> customize
> > variables that are not exposed, she can do that with the textarea
field
> > where she can write LESS code.
> >
> >
> >>
> >> Thanks,
> >> Marius
> >>
> >> On Wed, Jun 11, 2014 at 6:43 PM, Guillaume "Louis-Marie"
Delhumeau
> >> <gdelhumeau(a)xwiki.com> wrote:
> >> > Hi devs.
> >> >
> >> > I am implementing the Color Theme Editor for Flamingo! And this is
a
> >> > preview:
> >> >
> >>
>
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
> >> >
> >> > Since the current color theme application is strongly linked to
> Colibri,
> >> > and the new application will be strongly linked to Flamingo, I
propose
> >> the
> >> > following:
> >> >
> >> > 1/ move xwiki-platform-colorthemes in xwiki-platform-colibri and
state
> >> that
> >> > this application is only compatible with colibri-based skin.
> >> > 2/ create the new application in xwiki-platform-flamingo
> >> > 3/ the new color theme application will actually propose more than
> colors
> >> > (fonts, less code, etc...), so I propose to call it
> >> > xwiki-platform-flamingo-themes.
> >> > 4/ in the administration, we have a page that propose which color
> theme
> >> we
> >> > want to use. Since the new application will not be compatible with
the
> >> old
> >> > one, I propose to add an extension point (such as what we have to
> >> configure
> >> > search suggest sources) in order to propose the themes
corresponding
> to
> >> the
> >> > selected skin (ie: xobjects of ColorThemes.ColorThemeClass for
colibri
> >> and
> >> > skins based on colibri, and xobjects of
FlamingoThemeCode.ThemeClass
> for
> >> > flamingo).
> >> > 5/ modify SkinAction that currenlty executes velocity code on a
skin
> file
> >> > if the mime type is CSS or JS, to also execute velocity on files
> suffixed
> >> > by .less.vm, because I need it for my application. To see what it
> looks
> >> > like, please look at
> >> >
> >>
>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
> >> > . The alternative is to create
a new action which is too much IMO.
> >> > 6/ when colibri will be deprecated on removed from XE, we will do
the
> same
> > for the old color theme application.
> >
> > 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
>
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
16 Jun
16 Jun
12:51 p.m.
New subject: [xwiki-devs] [Proposal] Link the color theme application to the skin
IMO the biggest problem are the applications that are using the colorthemes
variables.
So from what I understood you propose to deprecate the colorthemes
variables in favor of Bootstrap variables. My question is how do we do it?
So instead of using '$theme.textColor' I would need to use '@text-color'
?
The problem is that one is Velocity, while the other is LESS. Do we plan to
support and compile all css, across all applications. From what I know now
we only compile the style.css -> style.less.
Not sure how much work you have for the RC1, but for me is kind of risky.
Also because we need to reach an agreement.
So IMO we could make just the wizards/previewers skin dependent and keep
the ColorThemesClass generic.
The approach could be to have something like:
* xwiki-platform-colorthemes that contains the API colorthemes we propose
to use across our applications. ColorThemes name might be a bit
restrictive, since they are actually API variables used to customize the UI
across elements ( we could extend it to support IconThemes, PanelsThemes,
etc. but that's another discussion). This way we share the ColorThemeClass.
* xwiki-platform-colibri-colorthemes that could contain only the wizard.
This is indeed skin dependent because of the layout. It will be also
dependent of platform-colorthemes since it's using it's variables.
* xwiki-platform-flamingo-themes that will contain the prototype preview
you are working on. Here we will provide a tab for the standard XWiki
colortheme variables and other tabs that customize the Bootstrap values.
Maybe here we could write a mapping like '$theme.textColor = @text-color'
although this will be technical and these wizards should be used by
non-technical users (actually this is kind of problematic for Boostrap
variables, since they are intimidating because they are so many). It's a
bit problematic, since I don't know if in the Flamingo Wizard we should
provide all the Bootstrap varibles. The skin is not using all the structure
Bootstrap is providing. For example, in our panels we don't have a
dedicated footer, etc.
If we have this API colorthemes variables we will be on the safe side if
Bootstrap is changing again the syntax (like in the case of 2.x, 3.x, 4.x,
etc.). If they change it again we just adapt it in the
xwiki-platform-flamingo-themes wizard, but we will not need to change in
all our applications.
Thanks,
Caty
On Thu, Jun 12, 2014 at 7:09 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
BTW, I first planned to implement this for RC1.
Do you see, guys, any inconvenient for writing such an application + modify
the administration-ui in a RC?
If there is, then I need a milestone 3, or pushing it for 6.2.
Thanks,
Guillaume
2014-06-12 10:21 GMT+02:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
whole
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/C…
powerful.
defined
we
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
is
than
_______________________________________________
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
On Thu, Jun 12, 2014 at 11:10 AM, Guillaume
"Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
> 2014-06-12 10:06 GMT+02:00 Marius Dumitru Florea <
> mariusdumitru.florea(a)xwiki.com>gt;:
>
>> On Thu, Jun 12, 2014 at 10:41 AM, Guillaume "Louis-Marie" Delhumeau
>> <gdelhumeau(a)xwiki.com> wrote:
>> > Hi Marius,
>> >
>> >
>> > 2014-06-11 21:26 GMT+02:00 Marius Dumitru Florea <
>> > mariusdumitru.florea(a)xwiki.com>gt;:
>> >
>> >> There are currently many places (both in platform and in
extensions)
>> >> where we use color theme
properties such as
>> >> $theme.pageContentBackgroundColor .
>> >
>> >
>> > For them, I have written a retro-compatibility component that
computes
> the
> > color themes variables from the style.css generated by Flamingo. It
> > actually does a mapping between bootstrap variables and old color
theme
>> > variables. It is not perfect, but at least it does not break the >> UI.
>> >
>> >
>> >> Does FlamingoThemeCode.ThemeClass
>> >> have completely different properties? I hope not. I'm looking at
the
>> >> ColorThemeClass and most of its
properties seem pretty generic,
i.e.
>
>> skin independent. Which ones are skin dependent?
> >>
> >
>
> > First, the preview section is completely skin dependent (see:
> >
>
> >
).
>
> My question was not about the UI. I was talking strictly about the
> 'data'. A color theme is defined by a map of (property, value) pairs.
> The current color theme definition has some properties that are (I
> think) widely used. You propose a new color theme definition that has
> different properties. The reason is, you say, because the current
> color theme properties are skin dependent. I don't find this true, at
> least not entirely. Most of the current color theme properties seem
> skin independent to me, that's why I asked you to list the properties
> that you view as skin dependent.
>
> >
>
> > Then, the new theme editor will propose to customize a set of
variables
>> > specific to bootstrap, just like:
>> > http://fancyboot.designspebam.com/
>> >
>> > We are exposing the BS variables because it is flexible and > Mixing old color theme variables and bootstrap
variables will not
resulting
> to a consistent set of variables, so that is why I am proposing to
separate
> the 2 cases.
So the reason is not because the current color theme properties are
skin dependent but because we want to use the bootstrap 'properties'
(some of which are in the current color theme but with a different
name?).
Yes.
The alternative is to not expose BS variables but only our already variables and have an internal mapping between
our variables and the
bootstrap ones. It would be less flexible, but we would still have the
textarea field to write LESS code if it is not enough. This alternative
is
only about changing the UI, and not the data.
I don't have a strong opinion. Since we're gong to standardise our UI
around BS then I guess it's fine to use directly the BS variables for
the new color themes.
Thanks,
Marius
>
>
>>
>> Thanks,
>> Marius
>>
>> >
>> > BTW, old color themes are still compatibles with Flamingo, because > have
> > a binding between the old color theme variables and the bootstrap
> > variables, but it is far from perfect.
> >
> >
> >>
> >> Also,
> >>
>
>> >> shows that
FlamingoThemeCode.ThemeClass has only two properties?
>> >> body-bg and text-color, both present with a different name in
>> >> ColorThemeClass.
>> >>
>> >
>> > When I have posted the link above, I only wanted to show you the
>> > modifications done on SkinAction.java. Of course, ThemeClass will
not
> have
> > only two properties! This commit is a first step to have a proof of
> concept.
> >
> > If you want to have the list of bootstrap variables, you could see
there:
> >
http://getbootstrap.com/customize/#less-variables
> >
> > Of course we won't expose all these variables: it would be confusing
for
> > the end user. We have to chose some of
them. If the user wants to
> customize
> > variables that are not exposed, she can do that with the textarea
field
>> > where she can write LESS code.
>> >
>> >
>> >>
>> >> Thanks,
>> >> Marius
>> >>
>> >> On Wed, Jun 11, 2014 at 6:43 PM, Guillaume "Louis-Marie"
Delhumeau
>> >> <gdelhumeau(a)xwiki.com> wrote:
>> >> > Hi devs.
>> >> >
>> >> > I am implementing the Color Theme Editor for Flamingo! And this
a
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
> >> > preview:
> >> >
> >>
>
>
>> >
> >> > Since the current color theme application is strongly linked to
> Colibri,
> >> > and the new application will be strongly linked to Flamingo, I
propose
> >> the
> >> > following:
> >> >
> >> > 1/ move xwiki-platform-colorthemes in xwiki-platform-colibri and
state
>> >> that
>> >> > this application is only compatible with colibri-based skin.
>> >> > 2/ create the new application in xwiki-platform-flamingo
>> >> > 3/ the new color theme application will actually propose more
>> colors
>> >> > (fonts, less code, etc...), so I propose to call it
>> >> > xwiki-platform-flamingo-themes.
>> >> > 4/ in the administration, we have a page that propose which color
>> theme
>> >> we
>> >> > want to use. Since the new application will not be compatible
with
the
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
> >> old
> >> > one, I propose to add an extension point (such as what we have to
> >> configure
> >> > search suggest sources) in order to propose the themes
corresponding
> to
> >> the
> >> > selected skin (ie: xobjects of ColorThemes.ColorThemeClass for
colibri
> >> and
> >> > skins based on colibri, and xobjects of
FlamingoThemeCode.ThemeClass
> for
> >> > flamingo).
> >> > 5/ modify SkinAction that currenlty executes velocity code on a
skin
> file
> >> > if the mime type is CSS or JS, to also execute velocity on files
> suffixed
> >> > by .less.vm, because I need it for my application. To see what it
> looks
> >> > like, please look at
> >> >
> >>
>
>> >> > . The alternative is to
create a new action which is too much
IMO.
>
>> > 6/ when colibri will be deprecated on removed from XE, we will do
the
>>
same
>> > for the old color theme application.
>> >
>> > 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
>>
>
> 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:07 p.m.
New subject: [xwiki-devs] [Proposal] Link the color theme application to the skin
2014-06-16 12:51 GMT+02:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>om>:
IMO the biggest problem are the applications that are
using the colorthemes
variables.
So from what I understood you propose to deprecate the colorthemes
variables in favor of Bootstrap variables. My question is how do we do it?
So instead of using '$theme.textColor' I would need to use '@text-color'
?
The problem is that one is Velocity, while the other is LESS.
We could have velocity variables too, like
$bootstrapTheme.get('text-color').
Do we plan to
support and compile all css, across all applications. From what I know now
we only compile the style.css -> style.less.
Because of performances reasons, I think it is better to not offer this
feature everywhere.
Not sure how much work you have for the RC1, but for me is kind of risky.
Also because we need to reach an agreement.
Yes it seems the most careful choice.
So IMO we could make just the wizards/previewers skin dependent and keep
the ColorThemesClass generic.
The approach could be to have something like:
* xwiki-platform-colorthemes that contains the API colorthemes we propose
to use across our applications. ColorThemes name might be a bit
restrictive, since they are actually API variables used to customize the UI
across elements ( we could extend it to support IconThemes, PanelsThemes,
etc. but that's another discussion). This way we share the ColorThemeClass.
* xwiki-platform-colibri-colorthemes that could contain only the wizard.
This is indeed skin dependent because of the layout. It will be also
dependent of platform-colorthemes since it's using it's variables.
* xwiki-platform-flamingo-themes that will contain the prototype preview
you are working on. Here we will provide a tab for the standard XWiki
colortheme variables and other tabs that customize the Bootstrap values.
Maybe here we could write a mapping like '$theme.textColor = @text-color'
although this will be technical and these wizards should be used by
non-technical users (actually this is kind of problematic for Boostrap
variables, since they are intimidating because they are so many). It's a
bit problematic, since I don't know if in the Flamingo Wizard we should
provide all the Bootstrap varibles. The skin is not using all the structure
Bootstrap is providing. For example, in our panels we don't have a
dedicated footer, etc.
I would like to propose only **some** of the bootstrap variables. I have
already started to pick some of them, and just playing with it with
automatic preview. It's quite fun actually.
If we have this API colorthemes variables we will be on the safe side if
Bootstrap is changing again the syntax (like in the case of 2.x, 3.x, 4.x,
etc.). If they change it again we just adapt it in the
xwiki-platform-flamingo-themes wizard, but we will not need to change in
all our applications.
Ok but that means we do not choose Bootstrap as our new UI standard, but we
create our own.
Thanks,
Caty
On Thu, Jun 12, 2014 at 7:09 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
whole
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/C…
powerful.
> >> > Mixing old color theme variables and bootstrap variables will not
> >> resulting
> >> > to a consistent set of variables, so that is why I am proposing to
> >> separate
> >> > the 2 cases.
> >>
> >> So the reason is not because the current color theme properties are
> >> skin dependent but because we want to use the bootstrap
'properties'
> >> (some of which are in the current color theme but with a different
> >> name?).
> >>
> >
> > Yes.
> >
> > The alternative is to not expose BS variables but only our already
> defined
> > variables and have an internal mapping between our variables and the
> > bootstrap ones. It would be less flexible, but we would still have the
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
of
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
color
to
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
do
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks,
Guillaume
BTW, I first planned to implement this for RC1.
Do you see, guys, any inconvenient for writing such an application +
modify
the administration-ui in a RC?
If there is, then I need a milestone 3, or pushing it for 6.2.
Thanks,
Guillaume
2014-06-12 10:21 GMT+02:00 Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com>gt;:
It
On Thu, Jun 12, 2014 at 11:10 AM, Guillaume
"Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
> 2014-06-12 10:06 GMT+02:00 Marius Dumitru Florea <
> mariusdumitru.florea(a)xwiki.com>gt;:
>
>> On Thu, Jun 12, 2014 at 10:41 AM, Guillaume "Louis-Marie" Delhumeau
>> <gdelhumeau(a)xwiki.com> wrote:
>> > Hi Marius,
>> >
>> >
>> > 2014-06-11 21:26 GMT+02:00 Marius Dumitru Florea <
>> > mariusdumitru.florea(a)xwiki.com>gt;:
>> >
>> >> There are currently many places (both in platform and in
extensions)
>> >> where we use color theme
properties such as
>> >> $theme.pageContentBackgroundColor .
>> >
>> >
>> > For them, I have written a retro-compatibility component that
computes
> >> the
> >> > color themes variables from the style.css generated by Flamingo.
> > actually does a mapping between bootstrap
variables and old color
theme
>> > variables. It is not perfect, but at least it does not break the >> UI.
>> >
>> >
>> >> Does FlamingoThemeCode.ThemeClass
>> >> have completely different properties? I hope not. I'm looking at
the
>> >> ColorThemeClass and most of its
properties seem pretty generic,
i.e.
>
>> skin independent. Which ones are skin dependent?
> >>
> >
>
> > First, the preview section is completely skin dependent (see:
> >
>
> >> > ).
> >>
> >> My question was not about the UI. I was talking strictly about the
> >> 'data'. A color theme is defined by a map of (property, value)
pairs.
> >> The current color theme definition
has some properties that are (I
> >> think) widely used. You propose a new color theme definition that
has
> >> different properties. The reason
is, you say, because the current
> >> color theme properties are skin dependent. I don't find this true,
at
> >> least not entirely. Most of the
current color theme properties seem
> >> skin independent to me, that's why I asked you to list the
properties
> that you view as skin dependent.
>
> >
>
> > Then, the new theme editor will propose to customize a set of
variables
>> > specific to bootstrap, just like:
>> > http://fancyboot.designspebam.com/
>> >
>> > We are exposing the BS variables because it is flexible and > > textarea field to write LESS code if it
is not enough. This
alternative
is
we
only about changing the UI, and not the data.
I don't have a strong opinion. Since we're gong to standardise our UI
around BS then I guess it's fine to use directly the BS variables for
the new color themes.
Thanks,
Marius
>
>
>>
>> Thanks,
>> Marius
>>
>> >
>> > BTW, old color themes are still compatibles with Flamingo, because > have
> > a binding between the old color theme variables and the bootstrap
> > variables, but it is far from perfect.
> >
> >
> >>
> >> Also,
> >>
>
>>
>> shows that FlamingoThemeCode.ThemeClass has only two properties?
>> >> body-bg and text-color, both present with a different name in
>> >> ColorThemeClass.
>> >>
>> >
>> > When I have posted the link above, I only wanted to show you the
>> > modifications done on SkinAction.java. Of course, ThemeClass will
not
> >> have
> >> > only two properties! This commit is a first step to have a proof
> >> concept.
> >> >
> >> > If you want to have the list of bootstrap variables, you could see
> there:
> >> > http://getbootstrap.com/customize/#less-variables
> >> >
> >> > Of course we won't expose all these variables: it would be
confusing
> for
> >> > the end user. We have to chose some of them. If the user wants to
> >> customize
> >> > variables that are not exposed, she can do that with the textarea
> field
> >> > where she can write LESS code.
> >> >
> >> >
> >> >>
> >> >> Thanks,
> >> >> Marius
> >> >>
> >> >> On Wed, Jun 11, 2014 at 6:43 PM, Guillaume "Louis-Marie"
Delhumeau
>>
>> <gdelhumeau(a)xwiki.com> wrote:
>> >> > Hi devs.
>> >> >
>> >> > I am implementing the Color Theme Editor for Flamingo! And this
is
a
> >> > preview:
> >> >
> >>
>
> >> >> >
> >> >> > Since the current color theme application is strongly linked
to
> >> Colibri,
> >> >> > and the new application will be strongly linked to Flamingo,
I
> propose
> >> >> the
> >> >> > following:
> >> >> >
> >> >> > 1/ move xwiki-platform-colorthemes in xwiki-platform-colibri
and
state
>> >> that
>> >> > this application is only compatible with colibri-based skin.
>> >> > 2/ create the new application in xwiki-platform-flamingo
>> >> > 3/ the new color theme application will actually propose more
than
> >> colors
> >> >> > (fonts, less code, etc...), so I propose to call it
> >> >> > xwiki-platform-flamingo-themes.
> >> >> > 4/ in the administration, we have a page that propose which
>>
theme
>> >> we
>> >> > want to use. Since the new application will not be compatible
with
> the
> >> >> old
> >> >> > one, I propose to add an extension point (such as what we
have > >> >> configure
> >> >> > search suggest sources) in order to propose the themes
> corresponding
> >> to
> >> >> the
> >> >> > selected skin (ie: xobjects of ColorThemes.ColorThemeClass
for
> colibri
> >> >> and
> >> >> > skins based on colibri, and xobjects of
> FlamingoThemeCode.ThemeClass
> >> for
> >> >> > flamingo).
> >> >> > 5/ modify SkinAction that currenlty executes velocity code on
a
> skin
> >> file
> >> >> > if the mime type is CSS or JS, to also execute velocity on
files
> >> suffixed
> >> >> > by .less.vm, because I need it for my application. To see
what
it
> looks
> >> > like, please look at
> >> >
> >>
>
>>
>> > . The alternative is to create a new action which is too much
IMO.
> >> >> > 6/ when colibri will be deprecated on removed from XE, we
will the
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
> >> same
> >> > for the old color theme application.
> >> >
> >> > 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
> >>
> >
> > 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
>
_______________________________________________
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
5:02 p.m.
Ok after reading carefully and after talking to Guillaume, here’s what I propose:
- For 6.1:
* Our goal is to have a usable Flamingo skin, which means a polished skin UI, especially
for view/edit/admin modes.
* The following features will not be complete for 6.1:
** The App Bar (Applications Panel) will only work in medium size for the moment and
displayed on the right for now
** The Color Theme editor is the current one (the Colibri one). It works for Flamingo too,
the only limitation (acceptable IMO for 6.1) is that the preview is done on the Colibri
look
** We don’t change the icon set and still use Silk for 6.1.
- For 6.2:
* GuillaumeD starts a discussion thread about whether to standardize on the Bootstrap HTML
+ Bootstrap HTML Classes + Bootstrap theme variables or create our own: XWiki HTML + XWiki
HTML Classes + XWiki theme variables. Note that if we use our own, we should still strive
to copy Boostrap as much as possible to benefit from all the thoughts they gave to it.
* Guillaume/Caty make a proposal to support multiple icon sets and make a proposal for a
new icon set, that support different sizes in particular.
* Guillaume implements the new Theme Editor based on the result of the discussion
mentioned above.
* Guillaume/caty implement the support for multiple icon sets + the new icon set.
WDYT?
Thanks
-Vincent
On 16 Jun 2014 at 13:08:00, Guillaume Louis-Marie Delhumeau
(gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
2014-06-16 12:51 GMT+02:00 Ecaterina Moraru (Valica)
:
IMO the biggest problem are the applications that
are using the colorthemes
variables.
So from what I understood you propose to deprecate the colorthemes
variables in favor of Bootstrap variables. My question is how do we do it?
So instead of using '$theme.textColor' I would need to use '@text-color'
?
The problem is that one is Velocity, while the other is LESS.
We could have velocity variables too, like
$bootstrapTheme.get('text-color').
Do we plan to
support and compile all css, across all applications. From what I know now
we only compile the style.css -> style.less.
Because of performances reasons, I think it is better to not offer this
feature everywhere.
Not sure how much work you have for the RC1, but for me is kind of risky.
Also because we need to reach an agreement.
Yes it seems the most careful choice.
So IMO we could make just the wizards/previewers skin dependent and keep
the ColorThemesClass generic.
The approach could be to have something like:
* xwiki-platform-colorthemes that contains the API colorthemes we propose
to use across our applications. ColorThemes name might be a bit
restrictive, since they are actually API variables used to customize the UI
across elements ( we could extend it to support IconThemes, PanelsThemes,
etc. but that's another discussion). This way we share the ColorThemeClass.
* xwiki-platform-colibri-colorthemes that could contain only the wizard.
This is indeed skin dependent because of the layout. It will be also
dependent of platform-colorthemes since it's using it's variables.
* xwiki-platform-flamingo-themes that will contain the prototype preview
you are working on. Here we will provide a tab for the standard XWiki
colortheme variables and other tabs that customize the Bootstrap values.
Maybe here we could write a mapping like '$theme.textColor = @text-color'
although this will be technical and these wizards should be used by
non-technical users (actually this is kind of problematic for Boostrap
variables, since they are intimidating because they are so many). It's a
bit problematic, since I don't know if in the Flamingo Wizard we should
provide all the Bootstrap varibles. The skin is not using all the structure
Bootstrap is providing. For example, in our panels we don't have a
dedicated footer, etc.
I would like to propose only **some** of the bootstrap variables. I have
already started to pick some of them, and just playing with it with
automatic preview. It's quite fun actually.
If we have this API colorthemes variables we will be on the safe side if
Bootstrap is changing again the syntax (like in the case of 2.x, 3.x, 4.x,
etc.). If they change it again we just adapt it in the
xwiki-platform-flamingo-themes wizard, but we will not need to change in
all our applications.
Ok but that means we do not choose Bootstrap as our new UI standard, but we
create our own.
>
> Thanks,
> Caty
>
>
> On Thu, Jun 12, 2014 at 7:09 PM, Guillaume "Louis-Marie" Delhumeau <
> gdelhumeau(a)xwiki.com> wrote:
>
> > BTW, I first planned to implement this for RC1.
> >
> > Do you see, guys, any inconvenient for writing such an application +
> modify
> > the administration-ui in a RC?
> >
> > If there is, then I need a milestone 3, or pushing it for 6.2.
> >
> > Thanks,
> > Guillaume
> >
> >
> > 2014-06-12 10:21 GMT+02:00 Marius Dumitru Florea <
> > mariusdumitru.florea(a)xwiki.com>gt;:
> >
> > > On Thu, Jun 12, 2014 at 11:10 AM, Guillaume "Louis-Marie"
Delhumeau
> > > wrote:
> > > > 2014-06-12 10:06 GMT+02:00 Marius Dumitru Florea <
> > > > mariusdumitru.florea(a)xwiki.com>gt;:
> > > >
> > > >> On Thu, Jun 12, 2014 at 10:41 AM, Guillaume
"Louis-Marie" Delhumeau
> > > >> wrote:
> > > >> > Hi Marius,
> > > >> >
> > > >> >
> > > >> > 2014-06-11 21:26 GMT+02:00 Marius Dumitru Florea <
> > > >> > mariusdumitru.florea(a)xwiki.com>gt;:
> > > >> >
> > > >> >> There are currently many places (both in platform and
in
> > extensions)
> > > >> >> where we use color theme properties such as
> > > >> >> $theme.pageContentBackgroundColor .
> > > >> >
> > > >> >
> > > >> > For them, I have written a retro-compatibility component
that
> > computes
> > > >> the
> > > >> > color themes variables from the style.css generated by
Flamingo.
> It
> > > >> > actually does a mapping between bootstrap variables and old
color
> > > theme
> > > >> > variables. It is not perfect, but at least it does not break
the
> > whole
> > > >> UI.
> > > >> >
> > > >> >
> > > >> >> Does FlamingoThemeCode.ThemeClass
> > > >> >> have completely different properties? I hope not.
I'm looking at
> > the
> > > >> >> ColorThemeClass and most of its properties seem pretty
generic,
> > i.e.
> > > >> >> skin independent. Which ones are skin dependent?
> > > >> >>
> > > >> >
> > > >>
> > > >> > First, the preview section is completely skin dependent
(see:
> > > >> >
> > > >>
> > >
> >
>
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/C…
> > > >> > ).
> > > >>
> > > >> My question was not about the UI. I was talking strictly about
the
> > > >> 'data'. A color theme is defined by a map of (property,
value)
> pairs.
> > > >> The current color theme definition has some properties that are
(I
> > > >> think) widely used. You propose a new color theme definition
that
> has
> > > >> different properties. The reason is, you say, because the
current
> > > >> color theme properties are skin dependent. I don't find this
true,
> at
> > > >> least not entirely. Most of the current color theme properties
seem
> > > >> skin independent to me, that's why I asked you to list the
> properties
> > > >> that you view as skin dependent.
> > > >>
> > > >> >
> > > >>
> > > >> > Then, the new theme editor will propose to customize a set
of
> > > variables
> > > >> > specific to bootstrap, just like:
> > > >> > http://fancyboot.designspebam.com/
> > > >> >
> > > >> > We are exposing the BS variables because it is flexible and
> > powerful.
> > > >> > Mixing old color theme variables and bootstrap variables
will not
> > > >> resulting
> > > >> > to a consistent set of variables, so that is why I am
proposing to
> > > >> separate
> > > >> > the 2 cases.
> > > >>
> > > >> So the reason is not because the current color theme properties
are
> > > >> skin dependent but because we want to use the bootstrap
'properties'
> > > >> (some of which are in the current color theme but with a
different
> > > >> name?).
> > > >>
> > > >
> > > > Yes.
> > > >
> > > > The alternative is to not expose BS variables but only our already
> > > defined
> > > > variables and have an internal mapping between our variables and the
> > > > bootstrap ones. It would be less flexible, but we would still have
> the
> > > > textarea field to write LESS code if it is not enough. This
> alternative
> > > is
> > > > only about changing the UI, and not the data.
> > >
> > > I don't have a strong opinion. Since we're gong to standardise our
UI
> > > around BS then I guess it's fine to use directly the BS variables for
> > > the new color themes.
> > >
> > > Thanks,
> > > Marius
> > >
> > > >
> > > >
> > > >>
> > > >> Thanks,
> > > >> Marius
> > > >>
> > > >> >
> > > >> > BTW, old color themes are still compatibles with Flamingo,
because
> > we
> > > >> have
> > > >> > a binding between the old color theme variables and the
bootstrap
> > > >> > variables, but it is far from perfect.
> > > >> >
> > > >> >
> > > >> >>
> > > >> >> Also,
> > > >> >>
> > > >>
> > >
> >
>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
> > > >> >> shows that FlamingoThemeCode.ThemeClass has only two
properties?
> > > >> >> body-bg and text-color, both present with a different
name in
> > > >> >> ColorThemeClass.
> > > >> >>
> > > >> >
> > > >> > When I have posted the link above, I only wanted to show you
the
> > > >> > modifications done on SkinAction.java. Of course, ThemeClass
will
> > not
> > > >> have
> > > >> > only two properties! This commit is a first step to have a
proof
> of
> > > >> concept.
> > > >> >
> > > >> > If you want to have the list of bootstrap variables, you
could see
> > > there:
> > > >> > http://getbootstrap.com/customize/#less-variables
> > > >> >
> > > >> > Of course we won't expose all these variables: it would
be
> confusing
> > > for
> > > >> > the end user. We have to chose some of them. If the user
wants to
> > > >> customize
> > > >> > variables that are not exposed, she can do that with the
textarea
> > > field
> > > >> > where she can write LESS code.
> > > >> >
> > > >> >
> > > >> >>
> > > >> >> Thanks,
> > > >> >> Marius
> > > >> >>
> > > >> >> On Wed, Jun 11, 2014 at 6:43 PM, Guillaume
"Louis-Marie"
> Delhumeau
> > > >> >> wrote:
> > > >> >> > Hi devs.
> > > >> >> >
> > > >> >> > I am implementing the Color Theme Editor for
Flamingo! And this
> > is
> > > a
> > > >> >> > preview:
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
>
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
> > > >> >> >
> > > >> >> > Since the current color theme application is
strongly linked to
> > > >> Colibri,
> > > >> >> > and the new application will be strongly linked to
Flamingo, I
> > > propose
> > > >> >> the
> > > >> >> > following:
> > > >> >> >
> > > >> >> > 1/ move xwiki-platform-colorthemes in
xwiki-platform-colibri
> and
> > > state
> > > >> >> that
> > > >> >> > this application is only compatible with
colibri-based skin.
> > > >> >> > 2/ create the new application in
xwiki-platform-flamingo
> > > >> >> > 3/ the new color theme application will actually
propose more
> > than
> > > >> colors
> > > >> >> > (fonts, less code, etc...), so I propose to call
it
> > > >> >> > xwiki-platform-flamingo-themes.
> > > >> >> > 4/ in the administration, we have a page that
propose which
> color
> > > >> theme
> > > >> >> we
> > > >> >> > want to use. Since the new application will not be
compatible
> > with
> > > the
> > > >> >> old
> > > >> >> > one, I propose to add an extension point (such as
what we have
> to
> > > >> >> configure
> > > >> >> > search suggest sources) in order to propose the
themes
> > > corresponding
> > > >> to
> > > >> >> the
> > > >> >> > selected skin (ie: xobjects of
ColorThemes.ColorThemeClass for
> > > colibri
> > > >> >> and
> > > >> >> > skins based on colibri, and xobjects of
> > > FlamingoThemeCode.ThemeClass
> > > >> for
> > > >> >> > flamingo).
> > > >> >> > 5/ modify SkinAction that currenlty executes
velocity code on a
> > > skin
> > > >> file
> > > >> >> > if the mime type is CSS or JS, to also execute
velocity on
> files
> > > >> suffixed
> > > >> >> > by .less.vm, because I need it for my application.
To see what
> it
> > > >> looks
> > > >> >> > like, please look at
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
> > > >> >> > . The alternative is to create a new action which
is too much
> > IMO.
> > > >> >> > 6/ when colibri will be deprecated on removed from
XE, we will
> do
> > > the
> > > >> >> same
> > > >> >> > for the old color theme application.
> > > >> >> >
> > > >> >> > WDYT?
> > > >> >> >
17 Jun
17 Jun
7:25 a.m.
New subject: [xwiki-devs] [Proposal] Link the color theme application to the skin
+1
Thanks,
Marius
On Mon, Jun 16, 2014 at 6:02 PM, vincent(a)massol.net <vincent(a)massol.net> wrote:
Ok after reading carefully and after talking to Guillaume, here’s what I propose:
- For 6.1:
* Our goal is to have a usable Flamingo skin, which means a polished skin UI, especially
for view/edit/admin modes.
* The following features will not be complete for 6.1:
** The App Bar (Applications Panel) will only work in medium size for the moment and
displayed on the right for now
** The Color Theme editor is the current one (the Colibri one). It works for Flamingo
too, the only limitation (acceptable IMO for 6.1) is that the preview is done on the
Colibri look
** We don’t change the icon set and still use Silk for 6.1.
- For 6.2:
* GuillaumeD starts a discussion thread about whether to standardize on the Bootstrap
HTML + Bootstrap HTML Classes + Bootstrap theme variables or create our own: XWiki HTML +
XWiki HTML Classes + XWiki theme variables. Note that if we use our own, we should still
strive to copy Boostrap as much as possible to benefit from all the thoughts they gave to
it.
* Guillaume/Caty make a proposal to support multiple icon sets and make a proposal for a
new icon set, that support different sizes in particular.
* Guillaume implements the new Theme Editor based on the result of the discussion
mentioned above.
* Guillaume/caty implement the support for multiple icon sets + the new icon set.
WDYT?
Thanks
-Vincent
On 16 Jun 2014 at 13:08:00, Guillaume Louis-Marie Delhumeau
(gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
2014-06-16 12:51 GMT+02:00 Ecaterina Moraru
(Valica) :
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs IMO the biggest problem are the applications that
are using the colorthemes
variables.
So from what I understood you propose to deprecate the colorthemes
variables in favor of Bootstrap variables. My question is how do we do it?
So instead of using '$theme.textColor' I would need to use '@text-color'
?
The problem is that one is Velocity, while the other is LESS.
We could have velocity variables too, like
$bootstrapTheme.get('text-color').
Do we plan to
support and compile all css, across all applications. From what I know now
we only compile the style.css -> style.less.
Because of performances reasons, I think it is better to not offer this
feature everywhere.
Not sure how much work you have for the RC1, but for me is kind of risky.
Also because we need to reach an agreement.
Yes it seems the most careful choice.
So IMO we could make just the wizards/previewers skin dependent and keep
the ColorThemesClass generic.
The approach could be to have something like:
* xwiki-platform-colorthemes that contains the API colorthemes we propose
to use across our applications. ColorThemes name might be a bit
restrictive, since they are actually API variables used to customize the UI
across elements ( we could extend it to support IconThemes, PanelsThemes,
etc. but that's another discussion). This way we share the ColorThemeClass.
* xwiki-platform-colibri-colorthemes that could contain only the wizard.
This is indeed skin dependent because of the layout. It will be also
dependent of platform-colorthemes since it's using it's variables.
* xwiki-platform-flamingo-themes that will contain the prototype preview
you are working on. Here we will provide a tab for the standard XWiki
colortheme variables and other tabs that customize the Bootstrap values.
Maybe here we could write a mapping like '$theme.textColor = @text-color'
although this will be technical and these wizards should be used by
non-technical users (actually this is kind of problematic for Boostrap
variables, since they are intimidating because they are so many). It's a
bit problematic, since I don't know if in the Flamingo Wizard we should
provide all the Bootstrap varibles. The skin is not using all the structure
Bootstrap is providing. For example, in our panels we don't have a
dedicated footer, etc.
I would like to propose only **some** of the bootstrap variables. I have
already started to pick some of them, and just playing with it with
automatic preview. It's quite fun actually.
If we have this API colorthemes variables we will be on the safe side if
Bootstrap is changing again the syntax (like in the case of 2.x, 3.x, 4.x,
etc.). If they change it again we just adapt it in the
xwiki-platform-flamingo-themes wizard, but we will not need to change in
all our applications.
Ok but that means we do not choose Bootstrap as our new UI standard, but we
create our own.
>
> Thanks,
> Caty
>
>
> On Thu, Jun 12, 2014 at 7:09 PM, Guillaume "Louis-Marie" Delhumeau <
> gdelhumeau(a)xwiki.com> wrote:
>
> > BTW, I first planned to implement this for RC1.
> >
> > Do you see, guys, any inconvenient for writing such an application +
> modify
> > the administration-ui in a RC?
> >
> > If there is, then I need a milestone 3, or pushing it for 6.2.
> >
> > Thanks,
> > Guillaume
> >
> >
> > 2014-06-12 10:21 GMT+02:00 Marius Dumitru Florea <
> > mariusdumitru.florea(a)xwiki.com>gt;:
> >
> > > On Thu, Jun 12, 2014 at 11:10 AM, Guillaume "Louis-Marie"
Delhumeau
> > > wrote:
> > > > 2014-06-12 10:06 GMT+02:00 Marius Dumitru Florea <
> > > > mariusdumitru.florea(a)xwiki.com>gt;:
> > > >
> > > >> On Thu, Jun 12, 2014 at 10:41 AM, Guillaume
"Louis-Marie" Delhumeau
> > > >> wrote:
> > > >> > Hi Marius,
> > > >> >
> > > >> >
> > > >> > 2014-06-11 21:26 GMT+02:00 Marius Dumitru Florea <
> > > >> > mariusdumitru.florea(a)xwiki.com>gt;:
> > > >> >
> > > >> >> There are currently many places (both in platform and
in
> > extensions)
> > > >> >> where we use color theme properties such as
> > > >> >> $theme.pageContentBackgroundColor .
> > > >> >
> > > >> >
> > > >> > For them, I have written a retro-compatibility component
that
> > computes
> > > >> the
> > > >> > color themes variables from the style.css generated by
Flamingo.
> It
> > > >> > actually does a mapping between bootstrap variables and old
color
> > > theme
> > > >> > variables. It is not perfect, but at least it does not break
the
> > whole
> > > >> UI.
> > > >> >
> > > >> >
> > > >> >> Does FlamingoThemeCode.ThemeClass
> > > >> >> have completely different properties? I hope not.
I'm looking at
> > the
> > > >> >> ColorThemeClass and most of its properties seem pretty
generic,
> > i.e.
> > > >> >> skin independent. Which ones are skin dependent?
> > > >> >>
> > > >> >
> > > >>
> > > >> > First, the preview section is completely skin dependent
(see:
> > > >> >
> > > >>
> > >
> >
>
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/C…
> > > >> > ).
> > > >>
> > > >> My question was not about the UI. I was talking strictly about
the
> > > >> 'data'. A color theme is defined by a map of (property,
value)
> pairs.
> > > >> The current color theme definition has some properties that are
(I
> > > >> think) widely used. You propose a new color theme definition
that
> has
> > > >> different properties. The reason is, you say, because the
current
> > > >> color theme properties are skin dependent. I don't find this
true,
> at
> > > >> least not entirely. Most of the current color theme properties
seem
> > > >> skin independent to me, that's why I asked you to list the
> properties
> > > >> that you view as skin dependent.
> > > >>
> > > >> >
> > > >>
> > > >> > Then, the new theme editor will propose to customize a set
of
> > > variables
> > > >> > specific to bootstrap, just like:
> > > >> > http://fancyboot.designspebam.com/
> > > >> >
> > > >> > We are exposing the BS variables because it is flexible and
> > powerful.
> > > >> > Mixing old color theme variables and bootstrap variables
will not
> > > >> resulting
> > > >> > to a consistent set of variables, so that is why I am
proposing to
> > > >> separate
> > > >> > the 2 cases.
> > > >>
> > > >> So the reason is not because the current color theme properties
are
> > > >> skin dependent but because we want to use the bootstrap
'properties'
> > > >> (some of which are in the current color theme but with a
different
> > > >> name?).
> > > >>
> > > >
> > > > Yes.
> > > >
> > > > The alternative is to not expose BS variables but only our already
> > > defined
> > > > variables and have an internal mapping between our variables and the
> > > > bootstrap ones. It would be less flexible, but we would still have
> the
> > > > textarea field to write LESS code if it is not enough. This
> alternative
> > > is
> > > > only about changing the UI, and not the data.
> > >
> > > I don't have a strong opinion. Since we're gong to standardise our
UI
> > > around BS then I guess it's fine to use directly the BS variables for
> > > the new color themes.
> > >
> > > Thanks,
> > > Marius
> > >
> > > >
> > > >
> > > >>
> > > >> Thanks,
> > > >> Marius
> > > >>
> > > >> >
> > > >> > BTW, old color themes are still compatibles with Flamingo,
because
> > we
> > > >> have
> > > >> > a binding between the old color theme variables and the
bootstrap
> > > >> > variables, but it is far from perfect.
> > > >> >
> > > >> >
> > > >> >>
> > > >> >> Also,
> > > >> >>
> > > >>
> > >
> >
>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
> > > >> >> shows that FlamingoThemeCode.ThemeClass has only two
properties?
> > > >> >> body-bg and text-color, both present with a different
name in
> > > >> >> ColorThemeClass.
> > > >> >>
> > > >> >
> > > >> > When I have posted the link above, I only wanted to show you
the
> > > >> > modifications done on SkinAction.java. Of course, ThemeClass
will
> > not
> > > >> have
> > > >> > only two properties! This commit is a first step to have a
proof
> of
> > > >> concept.
> > > >> >
> > > >> > If you want to have the list of bootstrap variables, you
could see
> > > there:
> > > >> > http://getbootstrap.com/customize/#less-variables
> > > >> >
> > > >> > Of course we won't expose all these variables: it would
be
> confusing
> > > for
> > > >> > the end user. We have to chose some of them. If the user
wants to
> > > >> customize
> > > >> > variables that are not exposed, she can do that with the
textarea
> > > field
> > > >> > where she can write LESS code.
> > > >> >
> > > >> >
> > > >> >>
> > > >> >> Thanks,
> > > >> >> Marius
> > > >> >>
> > > >> >> On Wed, Jun 11, 2014 at 6:43 PM, Guillaume
"Louis-Marie"
> Delhumeau
> > > >> >> wrote:
> > > >> >> > Hi devs.
> > > >> >> >
> > > >> >> > I am implementing the Color Theme Editor for
Flamingo! And this
> > is
> > > a
> > > >> >> > preview:
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
>
http://design.xwiki.org/xwiki/bin/download/Proposal/ColorThemeforFlamingo/f…
> > > >> >> >
> > > >> >> > Since the current color theme application is
strongly linked to
> > > >> Colibri,
> > > >> >> > and the new application will be strongly linked to
Flamingo, I
> > > propose
> > > >> >> the
> > > >> >> > following:
> > > >> >> >
> > > >> >> > 1/ move xwiki-platform-colorthemes in
xwiki-platform-colibri
> and
> > > state
> > > >> >> that
> > > >> >> > this application is only compatible with
colibri-based skin.
> > > >> >> > 2/ create the new application in
xwiki-platform-flamingo
> > > >> >> > 3/ the new color theme application will actually
propose more
> > than
> > > >> colors
> > > >> >> > (fonts, less code, etc...), so I propose to call
it
> > > >> >> > xwiki-platform-flamingo-themes.
> > > >> >> > 4/ in the administration, we have a page that
propose which
> color
> > > >> theme
> > > >> >> we
> > > >> >> > want to use. Since the new application will not be
compatible
> > with
> > > the
> > > >> >> old
> > > >> >> > one, I propose to add an extension point (such as
what we have
> to
> > > >> >> configure
> > > >> >> > search suggest sources) in order to propose the
themes
> > > corresponding
> > > >> to
> > > >> >> the
> > > >> >> > selected skin (ie: xobjects of
ColorThemes.ColorThemeClass for
> > > colibri
> > > >> >> and
> > > >> >> > skins based on colibri, and xobjects of
> > > FlamingoThemeCode.ThemeClass
> > > >> for
> > > >> >> > flamingo).
> > > >> >> > 5/ modify SkinAction that currenlty executes
velocity code on a
> > > skin
> > > >> file
> > > >> >> > if the mime type is CSS or JS, to also execute
velocity on
> files
> > > >> suffixed
> > > >> >> > by .less.vm, because I need it for my application.
To see what
> it
> > > >> looks
> > > >> >> > like, please look at
> > > >> >> >
> > > >> >>
> > > >>
> > >
> >
>
https://github.com/gdelhumeau/xwiki-platform/commit/49aca5733f4a820f3d1327c…
> > > >> >> > . The alternative is to create a new action which
is too much
> > IMO.
> > > >> >> > 6/ when colibri will be deprecated on removed from
XE, we will
> do
> > > the
> > > >> >> same
> > > >> >> > for the old color theme application.
> > > >> >> >
> > > >> >> > WDYT?
> > > >> >> >
3744
days inactive
3750
days old
14 comments
6 participants
participants (6)
-
Caleb James DeLisle -
Ecaterina Moraru (Valica) -
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne -
vincent＠massol.net