2014-06-16 12:51 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
> 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 <
> [email protected]> 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 <
> > [email protected]>:
> >
> > > On Thu, Jun 12, 2014 at 11:10 AM, Guillaume "Louis-Marie" Delhumeau
> > > <[email protected]> wrote:
> > > > 2014-06-12 10:06 GMT+02:00 Marius Dumitru Florea <
> > > > [email protected]>:
> > > >
> > > >> On Thu, Jun 12, 2014 at 10:41 AM, Guillaume "Louis-Marie" Delhumeau
> > > >> <[email protected]> wrote:
> > > >> > Hi Marius,
> > > >> >
> > > >> >
> > > >> > 2014-06-11 21:26 GMT+02:00 Marius Dumitru Florea <
> > > >> > [email protected]>:
> > > >> >
> > > >> >> 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/Capture%20du%202014-04-15%2010%3A47%3A05.png
> > > >> > ).
> > > >>
> > > >> 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/49aca5733f4a820f3d1327c76a7229781886dddf#diff-112
> > > >> >> 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
> > > >> >> <[email protected]> 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/flamingo-theme-editor.png
> > > >> >> >
> > > >> >> > 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/49aca5733f4a820f3d1327c76a7229781886dddf#diff-114
> > > >> >> > . 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
> > > >> >> > [email protected]
> > > >> >> > http://lists.xwiki.org/mailman/listinfo/devs
> > > >> >> _______________________________________________
> > > >> >> devs mailing list
> > > >> >> [email protected]
> > > >> >> http://lists.xwiki.org/mailman/listinfo/devs
> > > >> >>
> > > >> >
> > > >> > Thanks,
> > > >> > Guillaume
> > > >> > _______________________________________________
> > > >> > devs mailing list
> > > >> > [email protected]
> > > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > > >> _______________________________________________
> > > >> devs mailing list
> > > >> [email protected]
> > > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > >>
> > > > _______________________________________________
> > > > devs mailing list
> > > > [email protected]
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > _______________________________________________
> > > devs mailing list
> > > [email protected]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > _______________________________________________
> > devs mailing list
> > [email protected]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
Thanks,
Guillaume
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
