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:
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?).
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
> >> <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
_______________________________________________
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