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
