So looks like 2) is the one getting the best upvote/downvote ratio so "demo" it is then.
Thanks for your participation in this debate, if you enjoyed it there is many more to comes I'm sure :) On Thu, Apr 26, 2018 at 2:40 PM, Guillaume Delhumeau <[email protected]> wrote: > 2018-04-26 14:13 GMT+02:00 Eduard Moraru <[email protected]>: > >> Hi, Vincent, >> >> On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <[email protected]> >> wrote: >> >> > Hi Edy, >> > >> > Thanks for your input, see below. >> > >> > > On 26 Apr 2018, at 11:42, Eduard Moraru <[email protected]> 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 < >> > > [email protected]> wrote: >> > > >> > >> On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne < >> > >> [email protected]> >> > >> 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) >> > >>> <[email protected]> wrote: >> > >>>> On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne < >> > >>> [email protected]> >> > >>>> wrote: >> > >>>> >> > >>>>> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol < >> [email protected] >> > > >> > >>>>> 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 <[email protected]> >> > >> 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 < >> > >>> [email protected]> >> > >>>>> 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 ([email protected]) > Research & Development Engineer at XWiki SAS > Committer on the XWiki.org project -- Thomas Mortagne
