+1 Thanks, Marius
On Mon, Jun 16, 2014 at 6:02 PM, [email protected] <[email protected]> wrote: > > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
