[VOTE] Is it OK to edit a standard color theme

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

vmassol
Administrator
Hi Edy,

> On 26 Apr 2018, at 14:13, Eduard Moraru <[hidden email]> wrote:
>
> Hi, Vincent,
>
> On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <[hidden email]> wrote:
>
>> Hi Edy,
>>
>> Thanks for your input, see below.
>>
>>> On 26 Apr 2018, at 11:42, Eduard Moraru <[hidden email]> 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.

For me XWiki has a huge advantage over any other software we know: it’s the ability to track changes to configuration and code. Not a lot of software do this. For ex, imagine I change a setting in JIRA or in Jenkins. There’s no way you’ll know about it, nor be able to see the diff of what was changed, nor be able to roll it back. That’s an enormous advantage and we shouldn’t remove it.

>
>>
>> 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.

It’ll work, even if we update existing color themes. It’s just that users won’t get the changes by default as soon as they start customizing a theme.

If we want, it would be not too hard to add a button in the Color Theme sheet to revert to the factory default (I think it was proposed by Guillaume too), to make it more user-friendly than having to go to the history view to do that.

Thanks
-Vincent

>
> So +0.5 for approach 2.
>
> Thanks,
> Eduard
>
>
>>
>> Thanks
>> -Vincent
>>
>>> Thanks,
>>> Eduard
>>>
>>> On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea <
>>> [hidden email]> wrote:
>>>
>>>> On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne <
>>>> [hidden email]>
>>>> 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)
>>>>> <[hidden email]> wrote:
>>>>>> On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
>>>>> [hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <[hidden email]
>>>
>>>>>>> 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&F > 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 <[hidden email]>
>>>> 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 <
>>>>> [hidden email]>
>>>>>>> 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

Reply | Threaded
Open this post in threaded view
|

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

Thomas Mortagne
Administrator
On Fri, Apr 27, 2018 at 11:05 AM, Vincent Massol <[hidden email]> wrote:

> Hi Edy,
>
>> On 26 Apr 2018, at 14:13, Eduard Moraru <[hidden email]> wrote:
>>
>> Hi, Vincent,
>>
>> On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <[hidden email]> wrote:
>>
>>> Hi Edy,
>>>
>>> Thanks for your input, see below.
>>>
>>>> On 26 Apr 2018, at 11:42, Eduard Moraru <[hidden email]> 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.
>
> For me XWiki has a huge advantage over any other software we know: it’s the ability to track changes to configuration and code. Not a lot of software do this. For ex, imagine I change a setting in JIRA or in Jenkins. There’s no way you’ll know about it, nor be able to see the diff of what was changed, nor be able to roll it back. That’s an enormous advantage and we shouldn’t remove it.

Yes we need to show more of these reset button is use cases like
theses (default themes, default configuration, etc.).

>
>>
>>>
>>> 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.
>
> It’ll work, even if we update existing color themes. It’s just that users won’t get the changes by default as soon as they start customizing a theme.
>
> If we want, it would be not too hard to add a button in the Color Theme sheet to revert to the factory default (I think it was proposed by Guillaume too), to make it more user-friendly than having to go to the history view to do that.
>
> Thanks
> -Vincent
>
>>
>> So +0.5 for approach 2.
>>
>> Thanks,
>> Eduard
>>
>>
>>>
>>> Thanks
>>> -Vincent
>>>
>>>> Thanks,
>>>> Eduard
>>>>
>>>> On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea <
>>>> [hidden email]> wrote:
>>>>
>>>>> On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne <
>>>>> [hidden email]>
>>>>> 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)
>>>>>> <[hidden email]> wrote:
>>>>>>> On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
>>>>>> [hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <[hidden email]
>>>>
>>>>>>>> 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&F > 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 <[hidden email]>
>>>>> 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 <
>>>>>> [hidden email]>
>>>>>>>> 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
>



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

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

Eduard Moraru
In reply to this post by vmassol
On Fri, Apr 27, 2018 at 12:05 PM, Vincent Massol <[hidden email]> wrote:

> Hi Edy,
>
> > On 26 Apr 2018, at 14:13, Eduard Moraru <[hidden email]> wrote:
> >
> > Hi, Vincent,
> >
> > On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <[hidden email]>
> wrote:
> >
> >> Hi Edy,
> >>
> >> Thanks for your input, see below.
> >>
> >>> On 26 Apr 2018, at 11:42, Eduard Moraru <[hidden email]> 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.
>
> For me XWiki has a huge advantage over any other software we know: it’s
> the ability to track changes to configuration and code. Not a lot of
> software do this. For ex, imagine I change a setting in JIRA or in Jenkins.
> There’s no way you’ll know about it, nor be able to see the diff of what
> was changed, nor be able to roll it back. That’s an enormous advantage and
> we shouldn’t remove it.
>

Of course, but I'm not sure how is that related to what I said.
Configuration is and still will be editable and traceable in history. My
concern is only about *code*, specifically code that is written, maintained
and periodically released by someone other than the person currently
editing it, thus introducing a high potential for conflicts. I share your
grief for software not keeping a history of changes done in the configs.


>
> >
> >>
> >> 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.
>
> It’ll work, even if we update existing color themes. It’s just that users
> won’t get the changes by default as soon as they start customizing a theme.
>

Thinking about this, how would they reset to the latest version? If they
delete the page (hoping it will be re-added on the upgrade), I'm not sure
if they will get it or if EM will consider that if it is deleted, then the
user wants to keep it deleted.


>
> If we want, it would be not too hard to add a button in the Color Theme
> sheet to revert to the factory default (I think it was proposed by
> Guillaume too), to make it more user-friendly than having to go to the
> history view to do that.
>

Indeed, a reset to defaults that would actually reset to the latest
extension version of that document (suggested by Caty offline) would be
indeed a nice feature for configuration docs. This should also cover the
above case of restoring an edited and deleted page.

Thanks,
Eduard


>
> Thanks
> -Vincent
>
> >
> > So +0.5 for approach 2.
> >
> > Thanks,
> > Eduard
> >
> >
> >>
> >> Thanks
> >> -Vincent
> >>
> >>> Thanks,
> >>> Eduard
> >>>
> >>> On Thu, Apr 26, 2018 at 10:37 AM, Marius Dumitru Florea <
> >>> [hidden email]> wrote:
> >>>
> >>>> On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne <
> >>>> [hidden email]>
> >>>> 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)
> >>>>> <[hidden email]> wrote:
> >>>>>> On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
> >>>>> [hidden email]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <
> [hidden email]
> >>>
> >>>>>>> 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&F > 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 <[hidden email]>
> >>>> 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 <
> >>>>> [hidden email]>
> >>>>>>> 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
>
>
Reply | Threaded
Open this post in threaded view
|

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

Eduard Moraru
In reply to this post by Guillaume Delhumeau
On Thu, Apr 26, 2018 at 3:40 PM, Guillaume Delhumeau <
[hidden email]> wrote:

> 2018-04-26 14:13 GMT+02:00 Eduard Moraru <[hidden email]>:
>
> > Hi, Vincent,
> >
> > On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <[hidden email]>
> > wrote:
> >
> > > Hi Edy,
> > >
> > > Thanks for your input, see below.
> > >
> > > > On 26 Apr 2018, at 11:42, Eduard Moraru <[hidden email]>
> 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".
>
>
Yeah, you're right. Themes do go almost entirely into a configuration
domain rather than a code domain, specifically since they have dedicated UI
for each configurable variable. The LESS part is more for advanced stuff
that a regular user would normally ignore.

So it would more about configuring which "demo" configurations you want to
use.

Thanks,
Eduard

>
> >
> >
> > > 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 <
> > > > [hidden email]> wrote:
> > > >
> > > >> On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne <
> > > >> [hidden email]>
> > > >> 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)
> > > >>> <[hidden email]> wrote:
> > > >>>> On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
> > > >>> [hidden email]>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <
> > [hidden email]
> > > >
> > > >>>>> 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&F > 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 <[hidden email]>
> > > >> 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 <
> > > >>> [hidden email]>
> > > >>>>> 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
> > > >>>
> > > >>
> > >
> > >
> >
>
>
>
> --
> Guillaume Delhumeau ([hidden email])
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
>
12