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
