3 Jun
2014
3 Jun
'14
6:06 p.m.
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
4 Jun
4 Jun
9:01 a.m.
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 <
gdelhumeau(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
10:01 a.m.
Hi Guillaume,
Very nice.
+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).
Thanks,
Caty
On Wed, Jun 4, 2014 at 10:01 AM, Denis Gervalle <dgl(a)softec.lu> 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 <
gdelhumeau(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:19 a.m.
Hi Caty,
2014-06-04 10:01 GMT+02:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>om>:
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 <dgl(a)softec.lu> wrote:
http://xwiki-contrib.github.io/bootstrap-customizer-prototypes/prototypeB/
_______________________________________________
devs mailing list
devs(a)xwiki.org
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
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 <
gdelhumeau(a)xwiki.com> wrote:
http://xwiki-contrib.github.io/bootstrap-customizer-prototypes/prototypeA/
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:
(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:
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:53 a.m.
On Wed, Jun 4, 2014 at 10:19 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Hi Caty,
2014-06-04 10:01 GMT+02:00 Ecaterina Moraru (Valica) <valicac(a)gmail.com>om>:
of
http://xwiki-contrib.github.io/bootstrap-customizer-prototypes/prototypeA/
http://xwiki-contrib.github.io/bootstrap-customizer-prototypes/prototypeB/
_______________________________________________
devs mailing list
devs(a)xwiki.org
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?
It will became more and more reliable, since those legacy CSS will be
improved.
I do not think it is a big problem, but it deserve a warning on the editor.
The sample pages proposed by Cathy will not exhibit those legacy issues as
well.
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 <dgl(a)softec.lu> 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 > 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 <
> gdelhumeau(a)xwiki.com> 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:
> > (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:
> >
> > 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks,
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
10:14 a.m.
Hi Denis,
2014-06-04 9:01 GMT+02:00 Denis Gervalle <dgl(a)softec.lu>lu>:
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.
Good idea.
Moreover, for those having very
slow computer, having a way to disable the automatic refresh will be nice
to have.
There is one :)
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 ?)
I have to think about it, but I have the feeling that it would be hard to
implement.
Thanks,
On Tue, Jun 3, 2014 at 6:06 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
Thanks,
Guillaume
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:50 a.m.
On Wed, Jun 4, 2014 at 10:14 AM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
http://xwiki-contrib.github.io/bootstrap-customizer-prototypes/prototypeB/
Thanks,
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
Hi Denis,
2014-06-04 9:01 GMT+02:00 Denis Gervalle <dgl(a)softec.lu>lu>:
Maybe, combined with Cathy idea to provide some sample pages demonstrating
feature, we could have some special code in those page to provide that
functionality. Obviously, it will not work on any pages, but at least on
those ones. This will be helpful to easily find the feature to adapt.
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.
Good idea.
Moreover, for those having very
slow computer, having a way to disable the automatic refresh will be nice
to have.
There is one :)
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 ?)
I have to think about it, but I have the feeling that it would be hard to
implement.
Thanks,
On Tue, Jun 3, 2014 at 6:06 PM, Guillaume "Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
http://xwiki-contrib.github.io/bootstrap-customizer-prototypes/prototypeA/
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:
(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:
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3757
days inactive
3758
days old
6 comments
3 participants
participants (3)
-
Denis Gervalle -
Ecaterina Moraru (Valica) -
Guillaume "Louis-Marie" Delhumeau