Hi Caty, 2014-06-04 10:01 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
> Hi Guillaume, > > Very nice. > Thanks > +1 for A. > If we have performance problems we could have the 'auto-refresh' options > disabled by default. Also the 'processing' indicator can be a solution to > let the users know they need to be patient. > > Regarding the Preview, we can provide several custom/demo wiki pages that > will contain demo content for the specified variables. > For example, we can have multiple tabs: one for customizing the menus > (provide a menu page), another for customizing forms (provide another form > page), etc. This could improve the performance (some kind of variables > pagination and they will work great also to test our skin/colortheme). > Having different tabs could be a great idea, but it will not improve the performances. The costly operation is the LESS compilation of the skin file, which would be the same in all tabs. > > Thanks, > Caty > > > > On Wed, Jun 4, 2014 at 10:01 AM, Denis Gervalle <[email protected]> wrote: > > > Hi Guillaume, > > > > I'm also +1 for A with the provision that you implement a feedback to the > > user when the browser is processing and the preview is not up to date. I > > was thinking about a gray transparent foreground over the preview for > > example, with may be a CSS based spinner. Moreover, for those having very > > slow computer, having a way to disable the automatic refresh will be nice > > to have. > > > > I really dislike B since it is "artificial" and will surely became out of > > sync. However, the features of editing properties in-place over the > preview > > would be surely easier to do in B. This was a very interesting feature of > > the first theme editor. Do you think that we could find a way to do that > > with A for let say the most common style that is usually changed ? (By > > detection of style in the preview ?) > > > > Thanks, > > > > > > > > On Tue, Jun 3, 2014 at 6:06 PM, Guillaume "Louis-Marie" Delhumeau < > > [email protected]> wrote: > > > > > Good evening, > > > > > > We have discussed recently about the necessity of having a new Color > > Theme > > > Editor for Flamingo. Some of you have suggested to try to integrate in > > > XWiki an existing Bootstrap Customizer such as FancyBoot: > > > http://fancyboot.designspebam.com/ > > > > > > After looking on Google and Github, I could not find any that matches > > this > > > criterias: > > > - Bootstrap 3 support > > > - active > > > - compatible with an XWiki integration > > > > > > That is why I propose to write our own, which could actually take some > > code > > > from existing projects. > > > > > > On my side, I have written 2 prototypes and I have pushed them in a new > > > github repository: > > > https://github.com/xwiki-contrib/bootstrap-customizer-prototypes > > > > > > Prototype A > > > ==== > > > > > > Demo: > > > > > > http://xwiki-contrib.github.io/bootstrap-customizer-prototypes/prototypeA/ > > > (chrome users: please refresh the page if you do not see a color picker > > > when you click on an input box) > > > > > > This prototype opens a real web page inside an iframe, and use the LESS > > > browser compiler to update the CSS. > > > > > > Pros: > > > - it uses LESS so it shows the **real** results > > > - any wiki page can be seen in the preview frame > > > - not so hard time to implement > > > > > > Cons: > > > - it is quite slow, and sometimes the browser gets frozen for a few > > > seconds. > > > > > > Prototype B > > > ==== > > > > > > Demo: > > > > > > http://xwiki-contrib.github.io/bootstrap-customizer-prototypes/prototypeB/ > > > > > > This prototype emulates the behaviour of LESS when we change some > > > variables. The results is displayed in a preview box, but it is a fake > > one. > > > > > > Pros: > > > - The prototype runs quickly in the browser because there is no LESS > > > compiler involved. > > > > > > Cons: > > > - The preview box is not a real page and it cannot show all use-cases. > > > - Will take more time to implement and to maintain because we have to > > > manually emulate what LESS would do in the preview box. > > > > > > I'm +1 for Prototype A. > > > > > > What do you think? > > > > > > Thanks, > > > Guillaume > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > -- > > Denis Gervalle > > SOFTEC sa - CEO > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > An other thing to consider: in my prototype A, I am able to re-compute the CSS generated by LESS. But in XWiki, there are a lot of other CSS that use the old Color Theme mechanism. I have implemented a component which computes a color theme from a LESS file, but it is server-side. So, the preview would not be complete. Only the style.less would be changed in the preview, not the other CSS files. I don't know if it is okay to have a non 100% reliable preview. WDYT? Thanks, Guillaume _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
