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 ([email protected](mailto:[email protected])) 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 < > > [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 > > > > 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 > > > > >> 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 > > > > >> >> 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? > > > > >> >> > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
