On Fri, Apr 27, 2018 at 11:05 AM, Vincent Massol <vinc...@massol.net> wrote: > Hi Edy, > >> On 26 Apr 2018, at 14:13, Eduard Moraru <enygma2...@gmail.com> wrote: >> >> Hi, Vincent, >> >> On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <vinc...@massol.net> wrote: >> >>> Hi Edy, >>> >>> Thanks for your input, see below. >>> >>>> On 26 Apr 2018, at 11:42, Eduard Moraru <enygma2...@gmail.com> 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 < >>>> 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) >>>>>> <vali...@gmail.com> 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 >>>> >>>>>>>> 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 <vinc...@massol.net> >>>>> 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 > -- Thomas Mortagne
