27 Apr
2018
27 Apr
'18
12:14 p.m.
On Thu, Apr 26, 2018 at 3:40 PM, Guillaume Delhumeau <
guillaume.delhumeau(a)xwiki.com> wrote:
will
cycle
Vincent.
Iceberg
by
all
color
logo)
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
2018-04-26 14:13 GMT+02:00 Eduard Moraru
<enygma2002(a)gmail.com>om>:
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
this
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
Hi, Vincent,
On Thu, Apr 26, 2018 at 12:54 PM, Vincent Massol <vincent(a)massol.net>
wrote:
> Hi Edy,
>
> Thanks for your input, see below.
>
> > On 26 Apr 2018, at 11:42, Eduard Moraru <enygma2002(a)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 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 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 be some changes to the way XWiki works.
both
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 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 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.florea(a)xwiki.com> wrote:
> >
> >> On Wed, Apr 25, 2018 at 4:53 PM, Thomas Mortagne <
> >> thomas.mortagne(a)xwiki.com>
> >> wrote:
> >>
> >>> So it seems that 2) is currently leading with Ecaterina and > >>>
> >>> 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)
>>> <valicac(a)gmail.com> wrote:
>>>> On Wed, Apr 25, 2018 at 2:02 PM, Thomas Mortagne <
>>> thomas.mortagne(a)xwiki.com>
>>>> wrote:
>>>>
>>>>> On Wed, Apr 25, 2018 at 12:08 PM, Vincent Massol <
vincent(a)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
> >>> 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
user
use
>>> 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
>>>>> 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 >>
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
>>>> 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
> >>> depends
> >>>> on how well the Default Theme is tested initially.
> >>>>
> >>>> Thanks,
> >>>> Caty
> >>>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> Thanks
> >>>>>> -Vincent
> >>>>>>
> >>>>>>> On 25 Apr 2018, at 11:35, Vincent Massol
<vincent(a)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.mortagne(a)xwiki.com>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>> Hi xwikiers,
> >>>>>>>>
> >>>>>>>> Following new XAR entry type mail here is a
question about > >>>>>>>> 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
>>>>>>>>
>>>>>>>> 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
>>
>