On Fri, Apr 27, 2018 at 12:05 PM, 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. > 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 < > >>> 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 > >
