Re: [xwiki-devs] [NEW API] XAR entry type

[Thomas Mortagne]

On Thu, Apr 26, 2018 at 5:00 PM, Thomas Mortagne
 wrote:
> On Thu, Apr 26, 2018 at 4:34 PM, Eduard Moraru  wrote:
>> On Thu, Apr 26, 2018 at 3:35 PM, Thomas Mortagne 
>> wrote:
>>
>>> On Thu, Apr 26, 2018 at 1:45 PM, Eduard Moraru 
>>> wrote:
>>> > Hi, Thomas,
>>> >
>>> > I'm having some difficulties understanding the available types and their
>>> > intent.
>>> >
>>> >- default: used to force the default. Edit and delete are not allowed
>>> >and a 3-way merge is applied to the document during upgrades.
>>> >
>>> > Shouldn't the default upgrade action be "keep new", specially if edit and
>>> > delete is restricted on the page? The assumption would be that it's a
>>> code
>>> > page and any unsaved modifications (e.g. as a fork extension) should be
>>> > overridden by the new version of the extension's code.
>>>
>>> On upgrade side I much prefer to have the default being what always
>>> been the default and introduce new behavior in new types. Also think
>>> this is what we want for the majority of pages, there is stuff that
>>> you could add to a page without really thinking about it as a
>>> customization, that you will want to keep and which are not dangerous
>>> for merge (like comments, restrict access to some application, etc.).
>>>
>>
>> I do get where you are coming from. However, if you consider that "default"
>> restricts editing, you should normally not end up with unwanted stuff like
>> comments on a code page.
>
> Commenting is not an edit related action from the UI point of view and
> does not require edit right so you don't get any kind of protection
> (except if you disable comments in your page of course).
>
> Also it's more comment than you think to get comments on some

Yes I meant "it's more common", too close :)

> application home page and others not-supposed-to-be-edited entry point
> pages :)
>
>>
>> Regarding rights, that's a more realistic problem we have in the current
>> model. Until we come up with a solution that does not store rights as
>> objects inside the page, we don't have much choice.
>> However, this opens up another question: How does this (setting rights on a
>> code page that has "default" type) work with the lack of edit rights on the
>> page (i.e. you would not be able to set the rights in the first place,
>> because the page can't be edited)?
>
> Keep in mind that for spaces the right setup is associated to admin
> right/action and I don't plan to affect that right now.
>
>> Or maybe when you say "not allowed to
>> edit/delete", you simply refer to the small "warning" curtain in the UI
>> that only discourages the user to do the operation, but he can force it
>> anyway?
>
> I'm referring to what the type indicates.
>
> On actual behavior side the current plan (target 10.4) is to have the 
> following:
> * basic user: edit/delete rights are directly affected by the type setting
> * advanced user: warning
>
> Plus some configuration to change that (right level behavior for
> everyone, warning for everyone, etc.) except for superadmin which can
> always force it (with a warning by default).
>
>>
>>
>>> Simply to keep merging as safe as possible you get a string warning
>>> when going trough standard editing of those pages where you could have
>>> an impact on what constitute the hearth of what this page is supposed
>>> to do.
>>>
>>> >
>>> >- configuration: a document containing configuration. Edit is allowed
>>> >and the document is never upraded.
>>> >
>>> > Normally, configuration is among the only things you might actually want
>>> to
>>> > make a choice on, as someone running an upgrade. It does not make much
>>> > sense to never upgrade a configuration document, specifically when you
>>> have
>>> > just added a new feature. Thinking of package managers (i.e. apt's dpkg),
>>> > they allow specifying beforehand or even answering interactively on the
>>> > action to take (merge/new/old) for the configuration files of a package
>>> > being upgraded. Also, the general default for config files is "merge" and
>>> > not "keep old".
>>>
>>> There is different ways of seeing this. First dpkg is not really an
>>> accurate comparison IMO, I think you missed the fact that
>>> "configuration" here is for configuration data only usually, the
>>> assumptions is that the class and administration UI for example would
>>> be in a different documents so you do get new properties during
>>> upgrade. But the behavior supposedly stay the same after upgrade, i.e.
>>> it's not modified by a change in the provided default configuration
>>> (the idea being to allow the extension author to change default
>>> configuration for new install without disturbing old ones). This is
>>> exactly what happen with application that are using generated
>>> configuration page right now, one of the ideas behind this type is
>>> that you can use it instead of a (sometimes complex) 

Re: [xwiki-devs] [NEW API] XAR entry type

[Thomas Mortagne]

On Thu, Apr 26, 2018 at 4:34 PM, Eduard Moraru  wrote:
> On Thu, Apr 26, 2018 at 3:35 PM, Thomas Mortagne 
> wrote:
>
>> On Thu, Apr 26, 2018 at 1:45 PM, Eduard Moraru 
>> wrote:
>> > Hi, Thomas,
>> >
>> > I'm having some difficulties understanding the available types and their
>> > intent.
>> >
>> >- default: used to force the default. Edit and delete are not allowed
>> >and a 3-way merge is applied to the document during upgrades.
>> >
>> > Shouldn't the default upgrade action be "keep new", specially if edit and
>> > delete is restricted on the page? The assumption would be that it's a
>> code
>> > page and any unsaved modifications (e.g. as a fork extension) should be
>> > overridden by the new version of the extension's code.
>>
>> On upgrade side I much prefer to have the default being what always
>> been the default and introduce new behavior in new types. Also think
>> this is what we want for the majority of pages, there is stuff that
>> you could add to a page without really thinking about it as a
>> customization, that you will want to keep and which are not dangerous
>> for merge (like comments, restrict access to some application, etc.).
>>
>
> I do get where you are coming from. However, if you consider that "default"
> restricts editing, you should normally not end up with unwanted stuff like
> comments on a code page.

Commenting is not an edit related action from the UI point of view and
does not require edit right so you don't get any kind of protection
(except if you disable comments in your page of course).

Also it's more comment than you think to get comments on some
application home page and others not-supposed-to-be-edited entry point
pages :)

>
> Regarding rights, that's a more realistic problem we have in the current
> model. Until we come up with a solution that does not store rights as
> objects inside the page, we don't have much choice.
> However, this opens up another question: How does this (setting rights on a
> code page that has "default" type) work with the lack of edit rights on the
> page (i.e. you would not be able to set the rights in the first place,
> because the page can't be edited)?

Keep in mind that for spaces the right setup is associated to admin
right/action and I don't plan to affect that right now.

> Or maybe when you say "not allowed to
> edit/delete", you simply refer to the small "warning" curtain in the UI
> that only discourages the user to do the operation, but he can force it
> anyway?

I'm referring to what the type indicates.

On actual behavior side the current plan (target 10.4) is to have the following:
* basic user: edit/delete rights are directly affected by the type setting
* advanced user: warning

Plus some configuration to change that (right level behavior for
everyone, warning for everyone, etc.) except for superadmin which can
always force it (with a warning by default).

>
>
>> Simply to keep merging as safe as possible you get a string warning
>> when going trough standard editing of those pages where you could have
>> an impact on what constitute the hearth of what this page is supposed
>> to do.
>>
>> >
>> >- configuration: a document containing configuration. Edit is allowed
>> >and the document is never upraded.
>> >
>> > Normally, configuration is among the only things you might actually want
>> to
>> > make a choice on, as someone running an upgrade. It does not make much
>> > sense to never upgrade a configuration document, specifically when you
>> have
>> > just added a new feature. Thinking of package managers (i.e. apt's dpkg),
>> > they allow specifying beforehand or even answering interactively on the
>> > action to take (merge/new/old) for the configuration files of a package
>> > being upgraded. Also, the general default for config files is "merge" and
>> > not "keep old".
>>
>> There is different ways of seeing this. First dpkg is not really an
>> accurate comparison IMO, I think you missed the fact that
>> "configuration" here is for configuration data only usually, the
>> assumptions is that the class and administration UI for example would
>> be in a different documents so you do get new properties during
>> upgrade. But the behavior supposedly stay the same after upgrade, i.e.
>> it's not modified by a change in the provided default configuration
>> (the idea being to allow the extension author to change default
>> configuration for new install without disturbing old ones). This is
>> exactly what happen with application that are using generated
>> configuration page right now, one of the ideas behind this type is
>> that you can use it instead of a (sometimes complex) configuration
>> generation logic.
>>
>> But yes there is not only one kind of configuration and the point of
>> me listing the quick types I introduced in 10.3 is also to ask for new
>> ones to have a good coverage of various common use cases even if
>> 

Re: [xwiki-devs] [NEW API] XAR entry type

[Eduard Moraru]

On Thu, Apr 26, 2018 at 3:35 PM, Thomas Mortagne 
wrote:

> On Thu, Apr 26, 2018 at 1:45 PM, Eduard Moraru 
> wrote:
> > Hi, Thomas,
> >
> > I'm having some difficulties understanding the available types and their
> > intent.
> >
> >- default: used to force the default. Edit and delete are not allowed
> >and a 3-way merge is applied to the document during upgrades.
> >
> > Shouldn't the default upgrade action be "keep new", specially if edit and
> > delete is restricted on the page? The assumption would be that it's a
> code
> > page and any unsaved modifications (e.g. as a fork extension) should be
> > overridden by the new version of the extension's code.
>
> On upgrade side I much prefer to have the default being what always
> been the default and introduce new behavior in new types. Also think
> this is what we want for the majority of pages, there is stuff that
> you could add to a page without really thinking about it as a
> customization, that you will want to keep and which are not dangerous
> for merge (like comments, restrict access to some application, etc.).
>

I do get where you are coming from. However, if you consider that "default"
restricts editing, you should normally not end up with unwanted stuff like
comments on a code page.

Regarding rights, that's a more realistic problem we have in the current
model. Until we come up with a solution that does not store rights as
objects inside the page, we don't have much choice.
However, this opens up another question: How does this (setting rights on a
code page that has "default" type) work with the lack of edit rights on the
page (i.e. you would not be able to set the rights in the first place,
because the page can't be edited)? Or maybe when you say "not allowed to
edit/delete", you simply refer to the small "warning" curtain in the UI
that only discourages the user to do the operation, but he can force it
anyway?


> Simply to keep merging as safe as possible you get a string warning
> when going trough standard editing of those pages where you could have
> an impact on what constitute the hearth of what this page is supposed
> to do.
>
> >
> >- configuration: a document containing configuration. Edit is allowed
> >and the document is never upraded.
> >
> > Normally, configuration is among the only things you might actually want
> to
> > make a choice on, as someone running an upgrade. It does not make much
> > sense to never upgrade a configuration document, specifically when you
> have
> > just added a new feature. Thinking of package managers (i.e. apt's dpkg),
> > they allow specifying beforehand or even answering interactively on the
> > action to take (merge/new/old) for the configuration files of a package
> > being upgraded. Also, the general default for config files is "merge" and
> > not "keep old".
>
> There is different ways of seeing this. First dpkg is not really an
> accurate comparison IMO, I think you missed the fact that
> "configuration" here is for configuration data only usually, the
> assumptions is that the class and administration UI for example would
> be in a different documents so you do get new properties during
> upgrade. But the behavior supposedly stay the same after upgrade, i.e.
> it's not modified by a change in the provided default configuration
> (the idea being to allow the extension author to change default
> configuration for new install without disturbing old ones). This is
> exactly what happen with application that are using generated
> configuration page right now, one of the ideas behind this type is
> that you can use it instead of a (sometimes complex) configuration
> generation logic.
>
> But yes there is not only one kind of configuration and the point of
> me listing the quick types I introduced in 10.3 is also to ask for new
> ones to have a good coverage of various common use cases even if
> extension can also come with their own type too.
>
> >
> >- home: a wiki home page. Edit is allowed and the document is upgraded
> >only if it's not been customized.
> >- demo: a document which purpose is to provide demo data. Edit and
> >delete are allowed and the document is upgraded only if it's not been
> >customized.
> >
> > I don't really understand the distinction between "home" and "demo".
> AFAICS
> > from the definition, "home" is not supposed to be deleted, but why would
> we
> > want to enforce such a restriction? If we are talking about wiki
> homepages,
> > we can already configure that in the wiki descriptor as "Main.WebHome" is
> > not really a fixed entrypoint/API.
>
> Yes in theory the wiki home page is configurable but I really doubt
> this actually happen much and it's not very nice to delete the wiki
> home page for various reasons. Now it was a quickly introduce type
> because I had this use case in mind but we could decide to make it a
> demo and rely on another system to check if the page is the 

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Guillaume Delhumeau]

2018-04-26 14:13 GMT+02:00 Eduard Moraru :

> Hi, Vincent,
>
> On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol 
> wrote:
>
> > Hi Edy,
> >
> > Thanks for your input, see below.
> >
> > > On 26 Apr 2018, at 11:42, Eduard Moraru  wrote:
> > >
> > > Hi,
> > >
> > > I'm sorry, but nothing related to configuration inside pages looks very
> > > "wiki-like" to me.
> >
> > [snip]
> >
> > > You should not need a developer
> > > (possibly the original developer of the project/customizations) in
> order
> > to
> > > make a really basic operation such as an upgrade. Maybe I'm saying
> > > "sometimes less is more"? :)
> >
> > I’m just reacting to this part, hence the snipping :)
> >
> > For me approach 1 is both the complex approach by far and completely
> > unwiki-like. The wiki way is to be able to make easy edits and be able to
> > rollback, see diffs, etc. That’s natural and fast. That’s why wikis are
> > great and this is what we do everywhere in XWiki, including
> configurations
> > since all configs are stored inside wiki pages (XWikiPreferences,
> *Config,
> > etc). And we’re not going to change that now.
> >
>
> You missed something from those snips where I explained the way I saw this
> and what might cause some confusion:
>
> "IMO, the important part to distinguish the fact that the configuration
> part (for a regular, non-dev) is choosing *which* color theme to use, while
> the customization (i.e. coding, done by someone that understands CSS/LESS,
> in this case) part is editing/customizing your own version of a color
> theme."
>
> i.e. Themes are not configuration, but actual code.
>

That is actually sad. We already have the "Skin" concept as the "complex
stuff people are not supposed to touch". As opposed to this, I have always
seen the "Theme" as the "little stuff you can change easily to change some
color of the big skin". I agree that themes can now contain a bit of "less"
code. But if both Skin and Themes are seens as "complex stuff regular users
should not change (because it's code)", it's very sad for the
user-friendlyness, and it's probably time to make things better.

Copying a theme when someone wants to edit is indeed breaking the wiki
workflow and it's again something complex. I would prefer a simple button
in the theme to "revert colors to factory default".


>
>
> > It would be the first time we copy something before allowing changing it
> > and that’s not logical and not consistent.
> >
>
> The whole discussion is about not allowing to edit something, which is a
> first indeed, but we are moving in that direction, so of course there will
> be some changes to the way XWiki works.
>
>
> >
> > In addition we would make a bigger mess since not only users would be
> > directed to making copies of color themes pages but they would still be
> > able to make modifications to current color theme pages…
>
>
> > The more I think about it, the more I’m convinced that approach 2 is both
> > the simplest (and I agree that “less is more” :)) and the most logical.
> >
> > You mentioned upgrade being a problem but I don’t think this is correct
> > since approach 2 means that the color theme pages are “demo” pages
> meaning
> > that there will never be any upgrade conflict. When we do new XWiki cycle
> > versions, we will still be able to provide new color themes and since
> those
> > are new (like Iceberg this year) users will be able to switch to them
> > easily (there’s no upgrade issue either here).
> >
>
> Going again through the page types (specifically the "demo" one) and
> through the options, I agree that, at least of the Color Themes case,
> approach 2 should do the job. Of course, all of this being possible with
> the contract that we don't update color themes and we always publish new
> ones, of which I'm a bit skeptical.
>
> So +0.5 for approach 2.
>
> Thanks,
> Eduard
>
>
> >
> > Thanks
> > -Vincent
> >
> > > Thanks,
> > > Eduard
> > >
> > > On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea <
> > > mariusdumitru.flo...@xwiki.com> wrote:
> > >
> > >> On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne <
> > >> thomas.morta...@xwiki.com>
> > >> wrote:
> > >>
> > >>> So it seems that 2) is currently leading with Ecaterina and Vincent.
> > >>>
> > >>> Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think
> > >>> about delete ?).
> > >>>
> > >>>
> > >>
> > >>> Marius, does your proposal means you are more for 1) but with the
> > >>> difference that the default color theme would be allowed for edit ?
> > >>>
> > >>
> > >> Yes, but I'm ok with 2)
> > >>
> > >>
> > >>>
> > >>> Any other point of view input ?
> > >>>
> > >>> On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica)
> > >>>  wrote:
> >  On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
> > >>> thomas.morta...@xwiki.com>
> >  wrote:
> > 
> > > On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <
> vinc...@massol.net
> > 

Re: [xwiki-devs] [NEW API] XAR entry type

[Thomas Mortagne]

On Thu, Apr 26, 2018 at 1:45 PM, Eduard Moraru  wrote:
> Hi, Thomas,
>
> I'm having some difficulties understanding the available types and their
> intent.
>
>- default: used to force the default. Edit and delete are not allowed
>and a 3-way merge is applied to the document during upgrades.
>
> Shouldn't the default upgrade action be "keep new", specially if edit and
> delete is restricted on the page? The assumption would be that it's a code
> page and any unsaved modifications (e.g. as a fork extension) should be
> overridden by the new version of the extension's code.

On upgrade side I much prefer to have the default being what always
been the default and introduce new behavior in new types. Also think
this is what we want for the majority of pages, there is stuff that
you could add to a page without really thinking about it as a
customization, that you will want to keep and which are not dangerous
for merge (like comments, restrict access to some application, etc.).
Simply to keep merging as safe as possible you get a string warning
when going trough standard editing of those pages where you could have
an impact on what constitute the hearth of what this page is supposed
to do.

>
>- configuration: a document containing configuration. Edit is allowed
>and the document is never upraded.
>
> Normally, configuration is among the only things you might actually want to
> make a choice on, as someone running an upgrade. It does not make much
> sense to never upgrade a configuration document, specifically when you have
> just added a new feature. Thinking of package managers (i.e. apt's dpkg),
> they allow specifying beforehand or even answering interactively on the
> action to take (merge/new/old) for the configuration files of a package
> being upgraded. Also, the general default for config files is "merge" and
> not "keep old".

There is different ways of seeing this. First dpkg is not really an
accurate comparison IMO, I think you missed the fact that
"configuration" here is for configuration data only usually, the
assumptions is that the class and administration UI for example would
be in a different documents so you do get new properties during
upgrade. But the behavior supposedly stay the same after upgrade, i.e.
it's not modified by a change in the provided default configuration
(the idea being to allow the extension author to change default
configuration for new install without disturbing old ones). This is
exactly what happen with application that are using generated
configuration page right now, one of the ideas behind this type is
that you can use it instead of a (sometimes complex) configuration
generation logic.

But yes there is not only one kind of configuration and the point of
me listing the quick types I introduced in 10.3 is also to ask for new
ones to have a good coverage of various common use cases even if
extension can also come with their own type too.

>
>- home: a wiki home page. Edit is allowed and the document is upgraded
>only if it's not been customized.
>- demo: a document which purpose is to provide demo data. Edit and
>delete are allowed and the document is upgraded only if it's not been
>customized.
>
> I don't really understand the distinction between "home" and "demo". AFAICS
> from the definition, "home" is not supposed to be deleted, but why would we
> want to enforce such a restriction? If we are talking about wiki homepages,
> we can already configure that in the wiki descriptor as "Main.WebHome" is
> not really a fixed entrypoint/API.

Yes in theory the wiki home page is configurable but I really doubt
this actually happen much and it's not very nice to delete the wiki
home page for various reasons. Now it was a quickly introduce type
because I had this use case in mind but we could decide to make it a
demo and rely on another system to check if the page is the configured
home page before warning about it.

> For application homepages, I fail to see
> the need to edit them, so I believe they should use "demo" instead of
> "home".

Did you mean default ? "demo" does not make sense for application home
page since you don't want to edit them as you said. Most application
home pages will use default type for me.

And yes those are not the target of "home" type. I did not really had
any other use case in mind than Main.WebHome when I introduced it but
assume other pages could be in a similar situation :)

>
> IMO, "Main.WebHome" should be set to "demo" since that is what it really
> is. We expect the admin to edit it with his needs.

I still prefer to protect the wiki home page against delete by default
but not strongly enough to not be OK with your proposal if other think
it's better like this.

>
> AFAIU, "demo" makes sense and "configuration" is mostly something that the
> admin might choose, with a default of "merge".
>
> Thanks,
> Eduard

Any other type you can think of that would worth being introduced in

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Eduard Moraru]

Hi, Vincent,

On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol  wrote:

> Hi Edy,
>
> Thanks for your input, see below.
>
> > On 26 Apr 2018, at 11:42, Eduard Moraru  wrote:
> >
> > Hi,
> >
> > I'm sorry, but nothing related to configuration inside pages looks very
> > "wiki-like" to me.
>
> [snip]
>
> > You should not need a developer
> > (possibly the original developer of the project/customizations) in order
> to
> > make a really basic operation such as an upgrade. Maybe I'm saying
> > "sometimes less is more"? :)
>
> I’m just reacting to this part, hence the snipping :)
>
> For me approach 1 is both the complex approach by far and completely
> unwiki-like. The wiki way is to be able to make easy edits and be able to
> rollback, see diffs, etc. That’s natural and fast. That’s why wikis are
> great and this is what we do everywhere in XWiki, including configurations
> since all configs are stored inside wiki pages (XWikiPreferences, *Config,
> etc). And we’re not going to change that now.
>

You missed something from those snips where I explained the way I saw this
and what might cause some confusion:

"IMO, the important part to distinguish the fact that the configuration
part (for a regular, non-dev) is choosing *which* color theme to use, while
the customization (i.e. coding, done by someone that understands CSS/LESS,
in this case) part is editing/customizing your own version of a color
theme."

i.e. Themes are not configuration, but actual code.


> It would be the first time we copy something before allowing changing it
> and that’s not logical and not consistent.
>

The whole discussion is about not allowing to edit something, which is a
first indeed, but we are moving in that direction, so of course there will
be some changes to the way XWiki works.


>
> In addition we would make a bigger mess since not only users would be
> directed to making copies of color themes pages but they would still be
> able to make modifications to current color theme pages…


> The more I think about it, the more I’m convinced that approach 2 is both
> the simplest (and I agree that “less is more” :)) and the most logical.
>
> You mentioned upgrade being a problem but I don’t think this is correct
> since approach 2 means that the color theme pages are “demo” pages meaning
> that there will never be any upgrade conflict. When we do new XWiki cycle
> versions, we will still be able to provide new color themes and since those
> are new (like Iceberg this year) users will be able to switch to them
> easily (there’s no upgrade issue either here).
>

Going again through the page types (specifically the "demo" one) and
through the options, I agree that, at least of the Color Themes case,
approach 2 should do the job. Of course, all of this being possible with
the contract that we don't update color themes and we always publish new
ones, of which I'm a bit skeptical.

So +0.5 for approach 2.

Thanks,
Eduard


>
> Thanks
> -Vincent
>
> > Thanks,
> > Eduard
> >
> > On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> >
> >> On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne <
> >> thomas.morta...@xwiki.com>
> >> wrote:
> >>
> >>> So it seems that 2) is currently leading with Ecaterina and Vincent.
> >>>
> >>> Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think
> >>> about delete ?).
> >>>
> >>>
> >>
> >>> Marius, does your proposal means you are more for 1) but with the
> >>> difference that the default color theme would be allowed for edit ?
> >>>
> >>
> >> Yes, but I'm ok with 2)
> >>
> >>
> >>>
> >>> Any other point of view input ?
> >>>
> >>> On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica)
> >>>  wrote:
>  On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
> >>> thomas.morta...@xwiki.com>
>  wrote:
> 
> > On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol  >
> > wrote:
> >> To give my opinion, I’m hesitating about 2 approaches:
> >>
> >> Approach 1: “standard"
> >> ==
> >>
> >> * We should have “Default Color Theme” be a copy from the Iceberg
> >>> color
> > theme page. I think I’d prefer the copy to be done at runtime; for
> >>> example
> > if the currently defined color theme page doesn’t exist when going to
> >>> the
> > L > Themes admin page, create it by copying Iceberg. This provides
> a
> >>> self
> > healing feature if the color theme page has been removed/doesn’t
> >>> exist/etc.
> >>
> >> * Predefined color theme pages should be considered “standard” and a
> > warning message displayed if a user wants to edit them. BTW would be
> >>> nice
> > to have a feature to have a customized message per “type”. For
> example
> >>> for
> > color theme pages we would display a message saying that the user
> >> should
> > copy the page to customize it instead of editing 

Re: [xwiki-devs] [NEW API] XAR entry type

[Eduard Moraru]

Hi, Thomas,

I'm having some difficulties understanding the available types and their
intent.

   - default: used to force the default. Edit and delete are not allowed
   and a 3-way merge is applied to the document during upgrades.

Shouldn't the default upgrade action be "keep new", specially if edit and
delete is restricted on the page? The assumption would be that it's a code
page and any unsaved modifications (e.g. as a fork extension) should be
overridden by the new version of the extension's code.

   - configuration: a document containing configuration. Edit is allowed
   and the document is never upraded.

Normally, configuration is among the only things you might actually want to
make a choice on, as someone running an upgrade. It does not make much
sense to never upgrade a configuration document, specifically when you have
just added a new feature. Thinking of package managers (i.e. apt's dpkg),
they allow specifying beforehand or even answering interactively on the
action to take (merge/new/old) for the configuration files of a package
being upgraded. Also, the general default for config files is "merge" and
not "keep old".

   - home: a wiki home page. Edit is allowed and the document is upgraded
   only if it's not been customized.
   - demo: a document which purpose is to provide demo data. Edit and
   delete are allowed and the document is upgraded only if it's not been
   customized.

I don't really understand the distinction between "home" and "demo". AFAICS
from the definition, "home" is not supposed to be deleted, but why would we
want to enforce such a restriction? If we are talking about wiki homepages,
we can already configure that in the wiki descriptor as "Main.WebHome" is
not really a fixed entrypoint/API. For application homepages, I fail to see
the need to edit them, so I believe they should use "demo" instead of
"home".

IMO, "Main.WebHome" should be set to "demo" since that is what it really
is. We expect the admin to edit it with his needs.

AFAIU, "demo" makes sense and "configuration" is mostly something that the
admin might choose, with a default of "merge".

Thanks,
Eduard


On Wed, Apr 25, 2018 at 7:49 PM, Thomas Mortagne 
wrote:

> By the way this is not only about XWiki Standard. We also need to
> think about entry type in contrib extensions you know.
>
> On Mon, Apr 23, 2018 at 1:40 PM, Thomas Mortagne
>  wrote:
> > As I indicated it would be better if you could send other mail to
> > discuss those pages separately (there is already one for the the
> > themes) :)
> >
> > On Mon, Apr 23, 2018 at 12:39 PM, Ecaterina Moraru (Valica)
> >  wrote:
> >> Dashboard.WebHome should be editable.
> >> FlamingoThemes.* should be editable in order for users to set custom
> logos.
> >> XWiki.DefaultSkin should be editable for the same logo reason.
> >>
> >> Thanks,
> >> Caty
> >>
> >> On Mon, Apr 23, 2018 at 1:27 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> >> wrote:
> >>
> >>> Hi devs,
> >>>
> >>> When dealing with extension pages protection we ended up with a very
> >>> visible issue: EVERYONE customize the home page so it does not make
> >>> much sense to warn every user trying to edit it that it's dangerous
> >>> and might break the extensions.
> >>>
> >>> Since it's not the only use case 10.3 introduce the concept of XAR
> >>> entry type which allow controlling a bit more edit/delete and upgrade
> >>> behavior. See http://extensions.xwiki.org/
> xwiki/bin/view/Extension/XAR+
> >>> Module+Specifications#Hpackage.xml
> >>> for more details.
> >>>
> >>> On component side it's possible to decide the default type of a page
> >>> reference (that's where "Main.WebHome" type come from currently). It's
> >>> also possible to override the upgrade behavior for a specific type or
> >>> even a specific reference for more exotic use cases.
> >>>
> >>> So it's now possible to control the type you want for a page at XAR
> >>> descriptor level. I already typed a few page, for example
> >>> "Main.WebHome" is now of type "home" which means "it's OK to edit it
> >>> and you should only upgrade it if no customization have been made".
> >>>
> >>> Cool home page is covered but we now entered a new era of endless
> >>> debates to decide of what type some page should be and what other
> >>> types to introduce :)
> >>>
> >>> We are not going to discuss all these in this mail so everyone with a
> >>> doubt should start a discussion for a standard page (or a set of
> >>> standard page which are obviously very similar like color themes).
> >>>
> >>> Currently, protected page produce a warning that you can force. The
> >>> plan in 10.4 is to keep the warning only for advanced completely
> >>> prevent basic user to modify protected pages by default and also allow
> >>> configuring all that (indicate in your profile that you don't want to
> >>> be bothered with that, override edit/delete right even for advanced
> >>> users, 

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Guillaume Delhumeau]

I vote for option 2 (but I'm fine with option 3 too)

2018-04-26 11:54 GMT+02:00 Vincent Massol :

> Hi Edy,
>
> Thanks for your input, see below.
>
> > On 26 Apr 2018, at 11:42, Eduard Moraru  wrote:
> >
> > Hi,
> >
> > I'm sorry, but nothing related to configuration inside pages looks very
> > "wiki-like" to me.
>
> [snip]
>
> > You should not need a developer
> > (possibly the original developer of the project/customizations) in order
> to
> > make a really basic operation such as an upgrade. Maybe I'm saying
> > "sometimes less is more"? :)
>
> I’m just reacting to this part, hence the snipping :)
>
> For me approach 1 is both the complex approach by far and completely
> unwiki-like. The wiki way is to be able to make easy edits and be able to
> rollback, see diffs, etc. That’s natural and fast. That’s why wikis are
> great and this is what we do everywhere in XWiki, including configurations
> since all configs are stored inside wiki pages (XWikiPreferences, *Config,
> etc). And we’re not going to change that now.
>
> It would be the first time we copy something before allowing changing it
> and that’s not logical and not consistent.
>
> In addition we would make a bigger mess since not only users would be
> directed to making copies of color themes pages but they would still be
> able to make modifications to current color theme pages…
>
> The more I think about it, the more I’m convinced that approach 2 is both
> the simplest (and I agree that “less is more” :)) and the most logical.
>
> You mentioned upgrade being a problem but I don’t think this is correct
> since approach 2 means that the color theme pages are “demo” pages meaning
> that there will never be any upgrade conflict. When we do new XWiki cycle
> versions, we will still be able to provide new color themes and since those
> are new (like Iceberg this year) users will be able to switch to them
> easily (there’s no upgrade issue either here).
>
> Thanks
> -Vincent
>
> > Thanks,
> > Eduard
> >
> > On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea <
> > mariusdumitru.flo...@xwiki.com> wrote:
> >
> >> On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne <
> >> thomas.morta...@xwiki.com>
> >> wrote:
> >>
> >>> So it seems that 2) is currently leading with Ecaterina and Vincent.
> >>>
> >>> Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think
> >>> about delete ?).
> >>>
> >>>
> >>
> >>> Marius, does your proposal means you are more for 1) but with the
> >>> difference that the default color theme would be allowed for edit ?
> >>>
> >>
> >> Yes, but I'm ok with 2)
> >>
> >>
> >>>
> >>> Any other point of view input ?
> >>>
> >>> On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica)
> >>>  wrote:
>  On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
> >>> thomas.morta...@xwiki.com>
>  wrote:
> 
> > On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol  >
> > wrote:
> >> To give my opinion, I’m hesitating about 2 approaches:
> >>
> >> Approach 1: “standard"
> >> ==
> >>
> >> * We should have “Default Color Theme” be a copy from the Iceberg
> >>> color
> > theme page. I think I’d prefer the copy to be done at runtime; for
> >>> example
> > if the currently defined color theme page doesn’t exist when going to
> >>> the
> > L > Themes admin page, create it by copying Iceberg. This provides
> a
> >>> self
> > healing feature if the color theme page has been removed/doesn’t
> >>> exist/etc.
> >>
> >> * Predefined color theme pages should be considered “standard” and a
> > warning message displayed if a user wants to edit them. BTW would be
> >>> nice
> > to have a feature to have a customized message per “type”. For
> example
> >>> for
> > color theme pages we would display a message saying that the user
> >> should
> > copy the page to customize it instead of editing it.
> >>
> >> * The Color Theme UI should also be improved a bit to have a
> >>> “Customize”
> > button on color theme pages that would perform a copy to let the user
> > customize a theme.
> >>
> >> Approach 2: “demo"
> >> 
> >>
> >> * Consider all color themes to be demo content and once the user
> >>> starts
> > modifying them don’t merge them anymore
> >> * When we want to provide modified color themes, introduce new theme
> > pages
> >> * Don’t provide a “Default Color Theme” page. Directly set “Iceberg”
> >>> to
> > be the default CT.
> >>
> >> Analysis
> >> ===
> >>
> >> Approach 2 is more wiki style and simpler for sure. Users can use
> >> the
> > diff feature and the rollback feature if they want to go back to the
> > original versions.
> >>
> >> I think I’m leaning more towards 2 ATM.
> >
> > So you think delete is OK too, right ?
> >
> 
>  For me 

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Vincent Massol]

Hi Edy,

Thanks for your input, see below.

> On 26 Apr 2018, at 11:42, Eduard Moraru  wrote:
> 
> Hi,
> 
> I'm sorry, but nothing related to configuration inside pages looks very
> "wiki-like" to me.

[snip]

> You should not need a developer
> (possibly the original developer of the project/customizations) in order to
> make a really basic operation such as an upgrade. Maybe I'm saying
> "sometimes less is more"? :)

I’m just reacting to this part, hence the snipping :)

For me approach 1 is both the complex approach by far and completely 
unwiki-like. The wiki way is to be able to make easy edits and be able to 
rollback, see diffs, etc. That’s natural and fast. That’s why wikis are great 
and this is what we do everywhere in XWiki, including configurations since all 
configs are stored inside wiki pages (XWikiPreferences, *Config, etc). And 
we’re not going to change that now.

It would be the first time we copy something before allowing changing it and 
that’s not logical and not consistent.

In addition we would make a bigger mess since not only users would be directed 
to making copies of color themes pages but they would still be able to make 
modifications to current color theme pages…

The more I think about it, the more I’m convinced that approach 2 is both the 
simplest (and I agree that “less is more” :)) and the most logical.

You mentioned upgrade being a problem but I don’t think this is correct since 
approach 2 means that the color theme pages are “demo” pages meaning that there 
will never be any upgrade conflict. When we do new XWiki cycle versions, we 
will still be able to provide new color themes and since those are new (like 
Iceberg this year) users will be able to switch to them easily (there’s no 
upgrade issue either here).

Thanks
-Vincent

> Thanks,
> Eduard
> 
> On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
> 
>> On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne <
>> thomas.morta...@xwiki.com>
>> wrote:
>> 
>>> So it seems that 2) is currently leading with Ecaterina and Vincent.
>>> 
>>> Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think
>>> about delete ?).
>>> 
>>> 
>> 
>>> Marius, does your proposal means you are more for 1) but with the
>>> difference that the default color theme would be allowed for edit ?
>>> 
>> 
>> Yes, but I'm ok with 2)
>> 
>> 
>>> 
>>> Any other point of view input ?
>>> 
>>> On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica)
>>>  wrote:
 On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
>>> thomas.morta...@xwiki.com>
 wrote:
 
> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol 
> wrote:
>> To give my opinion, I’m hesitating about 2 approaches:
>> 
>> Approach 1: “standard"
>> ==
>> 
>> * We should have “Default Color Theme” be a copy from the Iceberg
>>> color
> theme page. I think I’d prefer the copy to be done at runtime; for
>>> example
> if the currently defined color theme page doesn’t exist when going to
>>> the
> L > Themes admin page, create it by copying Iceberg. This provides a
>>> self
> healing feature if the color theme page has been removed/doesn’t
>>> exist/etc.
>> 
>> * Predefined color theme pages should be considered “standard” and a
> warning message displayed if a user wants to edit them. BTW would be
>>> nice
> to have a feature to have a customized message per “type”. For example
>>> for
> color theme pages we would display a message saying that the user
>> should
> copy the page to customize it instead of editing it.
>> 
>> * The Color Theme UI should also be improved a bit to have a
>>> “Customize”
> button on color theme pages that would perform a copy to let the user
> customize a theme.
>> 
>> Approach 2: “demo"
>> 
>> 
>> * Consider all color themes to be demo content and once the user
>>> starts
> modifying them don’t merge them anymore
>> * When we want to provide modified color themes, introduce new theme
> pages
>> * Don’t provide a “Default Color Theme” page. Directly set “Iceberg”
>>> to
> be the default CT.
>> 
>> Analysis
>> ===
>> 
>> Approach 2 is more wiki style and simpler for sure. Users can use
>> the
> diff feature and the rollback feature if they want to go back to the
> original versions.
>> 
>> I think I’m leaning more towards 2 ATM.
> 
> So you think delete is OK too, right ?
> 
 
 For me delete is ok too. IMO we should provide just a few themes by
 default, and the user should be able to uninstall and install what
>> themes
 he wants (ideally he would be able to preview them live).
 
 I don't like the copying part very much. Users like to have a base to
>>> start
 from, but they also have history as a fallback.

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Eduard Moraru]

Hi,

I'm sorry, but nothing related to configuration inside pages looks very
"wiki-like" to me. We're not talking about content pages here, but rather
about a preset/pack of preferences (I would actually call them more code
than configuration, to be honest, since we're talking about CSS and LESS)
which have an identity. Once you start changing their values, they lose
their identity and you can't call them "Iceberg" or "Charcoal" (etc.)
anymore. Once you customize them, they are "CustomIceberg" or "MyIceberg"
(etc.), if you really want to preserve a hint of the base of your
customizations.

IMO, we should have a distinction between the default color themes and the
user contributed ones (this also includes customized copies of default
ones). I believe this would actually help the user in getting a better
understanding of what is going on instead of asking them to digg through
the document history, look at diffs, etc. Nobody wants to do that.

I don't like (-0) the idea of DefaultColorTheme being a useless copy of
Iceberg. If we want, we could store in an unexposed property of the
FlamingoThemes application what is the default color theme, so that the
user can have a "default" option or a "Reset to default" when choosing what
theme to use. Also, new versions of XWiki could update that property's
value (as part of the code), for when we will want to introduce a new
"default" theme for future versions of XWiki. I believe users need to be
able to see and easily experience new features, without asking them to drop
their customizations or write code (i.e. compared to what they would get if
they intall a new/clean XWiki instance with the latest version).

I do like (+1) the other 2 bullet points of Approach 1 ("standard").
Hitting "Customize" when using a standard theme should generate you a copy
for your customization which you can then select from the list and apply.
Heck, we could even make a nice distinction in the UI (or at least in the
Select input) between the standard themes and the custom(-ized) ones.

IMO, the important part to distinguish the fact that the configuration part
(for a regular, non-dev) is choosing *which* color theme to use, while the
customization (i.e. coding, done by someone that understands CSS/LESS, in
this case) part is editing/customizing your own version of a color theme.
Should be easy to make the choice if we look at it this way, since it would
be similar to what we do for other parts of XWiki that need either
configuration (i.e. choosing *what* to use) and that might need also some
customization (i.e. modifying or defining *how* that choice will perform
its job).


General note/rant/reiteration: I am very much in favor of resisting the
urge to "edit everything" (that's what actually got us to the current
"problem"), even if it is a wiki at heart, since no software maintainers
can provide you any time of support or upgrade paths that can factor in the
fact that you are just barging in and making a beautiful mess of the code
they developed. IMO, we just need to draw the line where the software ends
and the wiki begins, otherwise users will be trapped/stuck with outdated
and un-upgradable XWiki versions and will be regretting their choice. We
need to think of the admins as well, and not only from the POV of the dev
that wants to make everything possible. You should not need a developer
(possibly the original developer of the project/customizations) in order to
make a really basic operation such as an upgrade. Maybe I'm saying
"sometimes less is more"? :)


Thanks,
Eduard

On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> wrote:
>
> > So it seems that 2) is currently leading with Ecaterina and Vincent.
> >
> > Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think
> > about delete ?).
> >
> >
>
> > Marius, does your proposal means you are more for 1) but with the
> > difference that the default color theme would be allowed for edit ?
> >
>
> Yes, but I'm ok with 2)
>
>
> >
> > Any other point of view input ?
> >
> > On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica)
> >  wrote:
> > > On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
> > thomas.morta...@xwiki.com>
> > > wrote:
> > >
> > >> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol 
> > >> wrote:
> > >> > To give my opinion, I’m hesitating about 2 approaches:
> > >> >
> > >> > Approach 1: “standard"
> > >> > ==
> > >> >
> > >> > * We should have “Default Color Theme” be a copy from the Iceberg
> > color
> > >> theme page. I think I’d prefer the copy to be done at runtime; for
> > example
> > >> if the currently defined color theme page doesn’t exist when going to
> > the
> > >> L > Themes admin page, create it by copying Iceberg. This provides a
> > self
> > >> healing feature if the color theme page has been 

Re: [xwiki-devs] [Proposal] Weblate as XWiki's translation platform

[Thomas Mortagne]

>From what I remember https://crowdin.com/ quota for OpenSource plan
was too low for XWiki.

On Wed, Apr 25, 2018 at 10:15 PM, Sergiu Dumitriu  wrote:
> On 04/24/2018 09:44 AM, Clément Aubin wrote:
>> On 04/23/2018 12:18 PM, Adel Atallah wrote:
>>> Hello everyone,
>>
>> Hi,
>>
>> AFAICS Weblate looks nice, but haven't we looked at other alternatives ?
>>
>> Here are some of them :
>>
>> * http://jabylon.org/ (uses Java, so it might be easier to integrate)
>> * http://zanata.org/
>> * http://pootle.translatehouse.org/
>> * https://pontoon.mozilla.org/
>
> I've been quite happy with https://crowdin.com/ , which handles
> ApplicationResources.properties very well, but isn't ideal for the .xml
> translations. It's free for open source projects.
>
> The problem with the .xml files is that apart from the translatable
> content, which it handles well, it tries to commit the exact same XML
> markup as in the "source" file, which doesn't really work for XWiki. As
> a workaround, I just cat|sed the contents of the XML files and upload it
> as a non-github-tracked resource. The alternative is to
> rebase-interactive each pull request it creates to discard the commits
> that try to re-format the XML files, but that gets tedious after a while.
>
>> Also, I think that it has already been discussed, either on
>> https://xwiki.markmail.org/search/?q=weblate or on IRC, but being able
>> to use xwiki.org as an identity provider on our translation platform
>> would be neat, so it could be something to look for in the possible
>> solutions.
>>
>>> As you may already know, we have thought about replacing the l10n platform
>>> which is becoming too slow. Weblate seems to be a good replacement choice,
>>> as it will able contributors to have their name in the commits and it has
>>> every features needed to make translations.
>>>
>>> One problem is that XWiki doesn't use a standard method to process
>>> translation files. We can solve that by creating some scripts to convert
>>> XWiki translation files into one that Weblate can understand.
>>>
>>> A detailed solution can be found here :
>>> http://design.xwiki.org/xwiki/bin/view/Proposal/WeblateasXWikistranslationplatform
>>
>> We'll indeed need to convert our translation files to a more "standard"
>> format, but I fear that using Python might decrease the maintainability
>> of those scripts.
>>
>> WDYT ?
>>
>>> Feel free to discuss it by responding here or directly in the design page.
>>>
>>> Thanks,
>>>  *Adel Atallah*
>>> *Product developer intern*
>>> adel.atal...@xwiki.com 
>>> tel: +33 (0)6 12 96 35 06
>>>
>>
>> Thanks,
>> Clément
>>
>
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu



-- 
Thomas Mortagne

Re: [xwiki-devs] [VOTE] Is it OK to edit a standard color theme

[Marius Dumitru Florea]

On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne 
wrote:

> So it seems that 2) is currently leading with Ecaterina and Vincent.
>
> Guillaume I'm not sure if you prefer 2) or 3) (i.e. what do you think
> about delete ?).
>
>

> Marius, does your proposal means you are more for 1) but with the
> difference that the default color theme would be allowed for edit ?
>

Yes, but I'm ok with 2)


>
> Any other point of view input ?
>
> On Wed, Apr 25, 2018 at 1:50 PM, Ecaterina Moraru (Valica)
>  wrote:
> > On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> > wrote:
> >
> >> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol 
> >> wrote:
> >> > To give my opinion, I’m hesitating about 2 approaches:
> >> >
> >> > Approach 1: “standard"
> >> > ==
> >> >
> >> > * We should have “Default Color Theme” be a copy from the Iceberg
> color
> >> theme page. I think I’d prefer the copy to be done at runtime; for
> example
> >> if the currently defined color theme page doesn’t exist when going to
> the
> >> L > Themes admin page, create it by copying Iceberg. This provides a
> self
> >> healing feature if the color theme page has been removed/doesn’t
> exist/etc.
> >> >
> >> > * Predefined color theme pages should be considered “standard” and a
> >> warning message displayed if a user wants to edit them. BTW would be
> nice
> >> to have a feature to have a customized message per “type”. For example
> for
> >> color theme pages we would display a message saying that the user should
> >> copy the page to customize it instead of editing it.
> >> >
> >> > * The Color Theme UI should also be improved a bit to have a
> “Customize”
> >> button on color theme pages that would perform a copy to let the user
> >> customize a theme.
> >> >
> >> > Approach 2: “demo"
> >> > 
> >> >
> >> > * Consider all color themes to be demo content and once the user
> starts
> >> modifying them don’t merge them anymore
> >> > * When we want to provide modified color themes, introduce new theme
> >> pages
> >> > * Don’t provide a “Default Color Theme” page. Directly set “Iceberg”
> to
> >> be the default CT.
> >> >
> >> > Analysis
> >> > ===
> >> >
> >> > Approach 2 is more wiki style and simpler for sure. Users can use the
> >> diff feature and the rollback feature if they want to go back to the
> >> original versions.
> >> >
> >> > I think I’m leaning more towards 2 ATM.
> >>
> >> So you think delete is OK too, right ?
> >>
> >
> > For me delete is ok too. IMO we should provide just a few themes by
> > default, and the user should be able to uninstall and install what themes
> > he wants (ideally he would be able to preview them live).
> >
> > I don't like the copying part very much. Users like to have a base to
> start
> > from, but they also have history as a fallback.
> >
> > Also we rarely make changes to ColorThemes, especially since they are not
> > very complex since they should contain only variables. Still it all
> depends
> > on how well the Default Theme is tested initially.
> >
> > Thanks,
> > Caty
> >
> >
> >>
> >> >
> >> > Thanks
> >> > -Vincent
> >> >
> >> >> On 25 Apr 2018, at 11:35, Vincent Massol  wrote:
> >> >>
> >> >> Is this a VOTE or a proposal or a brainstorming? I’m asking since
> >> nobody has voted yet, not even Thomas (except if we consider that
> “prefer”
> >> means +1 and “OK” means +0 ;)).
> >> >>
> >> >> From the answer it seems we might need a new VOTE since several new
> >> points have been added to the discussion. I’m not able to VOTE right
> now.
> >> >>
> >> >> Thanks
> >> >> -Vincent
> >> >>
> >> >>> On 23 Apr 2018, at 12:29, Thomas Mortagne <
> thomas.morta...@xwiki.com>
> >> wrote:
> >> >>>
> >> >>> Hi xwikiers,
> >> >>>
> >> >>> Following new XAR entry type mail here is a question about color
> >> >>> themes we provide in standard XWiki (Cerulean, Charcoal, etc.).
> >> >>>
> >> >>> 1) Standard stuff, if you want a custom color theme create a new one
> >> >>> (would be nice to be able to copy a standard one and propose it when
> >> >>> you try to edit a standard one).
> >> >>>
> >> >>> 2) Demo content, edit and delete it all you want and upgrade won't
> >> >>> touch a customized theme to avoid surprises (background color
> changed
> >> >>> a bit in the standard version which now collide with your logo)
> >> >>>
> >> >>> 3) Same as 2 but delete is bad (same as home page)
> >> >>>
> >> >>> WDYT ?
> >> >>>
> >> >>> I'm think I prefer 1) but I'm OK with 3) if other think it's more
> >> >>> example than standard material. Let's say -0 for 2).
> >> >>>
> >> >>> Thanks,
> >> >>> --
> >> >>> Thomas Mortagne
> >> >>
> >> >
> >>
> >>
> >>
> >> --
> >> Thomas Mortagne
> >>
>
>
>
> --
> Thomas Mortagne
>