Review Request 116648: Split into one KCM for Desktop Effects and one for Compositing

[Jos Poortvliet]

On Friday 07 March 2014 13:37:22 Martin Gräßlin wrote:
> On Friday 07 March 2014 13:07:06 Jens Reuterberg wrote:
> > Sry for perhaps breaking etiquette with review requests.
> 
> No that's just fine, but it would be better if you used the web frontend to
> keep the discussion in one place and you just lost the kwin mailing list :-)
> > The
> > KCM are at this moment a hot topic and one of the many issues
> > is fragmentation vs merging of subject.
> 
> Well this change has nothing to do with the fact that it is a hot topic :-)
> We discussed this month probably even years ago that we want to split this
> KCM. Given that we are approaching alpha 1 I decided to sit down and make
> it happen.
> 
> > The main issue is that the settings are, as it is, an extremely
> > hostile area for new users. The sorting is arbitrary but justified
> > through technical reasons (Like having two separate
> > appearance segments) and the idea of splitting them up into
> > an "advanced" section and a "basic" section has been met with,
> > perhaps to some, healthy skepticism ;)
> 
> In this case it's not really an advanced vs. basic. It's two orthogonal
> things. One KCM is to configure the "effects" - a better name would be
> "plugins" because that's more what it is. The other KCM is a very technical
> thing about how KWin performs the rendering. One could even think about not
> adding it to system settings at all.
> 
> From the experience of the last six years where it was not split we learned
> that most users just want to configure the effects and if they change other
> settings they mostly break it, because they don't understand what it does
> and think they can fine tweak it. They only got those settings because they
> thought it's related to the effects, which it isn't really.
> 
> > But this is just such a split. Having a compositing and desktop
> > effect as two separate areas so that one of them, the more
> > technical section would be held isolated from a user only
> > makes sense if it actually signals this shift:
> > 
> > Having two titles, one "Desktop Effects" and one "Compositing"
> > doesn't tell the user anything except "darn it they split it into
> > two things again for no reason".
> 
> I don't think so, users are interested in the Desktop Effects but not in the
> compositing settings. Those who are will understand why it's changed and
> will approve it.
> 
> > If they have to be split into two, I suggest renaming them into
> > something more correct instead of something precise - like
> > "Eye candy" and "Compositing KWM system", one being
> > extremely childish and fancyful and the other unecessarily
> > technical and complex. Signalling accessability with one, and
> > distance with the other.
> 
> I'm certainly fine with adding better names but "Eye candy" is a no-go. Our
> Effects are not about eye candy - Present Windows is everything but not eye
> candy. If we go for such a name it causes a backslash.
> 
> My suggestion would be to go in the direction of "Windowing System Plugins"
> for Desktop Effects, for Compositing I don't know a better name, just that
> it may not include KWin or KWM :-) But yeah not showing in systemsettings
> is an option. Probably the best fitting name is "Compositor" which is the
> established technical term for this kind of applications.

Too add to this, as I've dabbled trying to 'clean up' systemsettings: the kwin 
systemsettings KCM was actually one of the biggest issues as it mixed hardware 
settings (like render backend etc) with behavioral settings and pure look-
stuff. The plugins still mix behavioral (eg  zoom, present windows, even 
usability ones like magnifier and track mouse) with pure esthetic ones (magic 
lamp, explosion effects).

I am therefor very glad with Martin tackling this as well as the move to QML 
in general as that might make it possible for somebody eve at my skill level 
to make (small) adjustments.

Of course - you could argue the entire approach is wrong here. Instead of 
trying to expose the abilities of our window manager in one or several places 
(which is inevitably what these KCM's do, no matter how you organize them), a 
proper design should start from what an user needs to do (adjust accessibility 
settings, change behavior or theme) and bring things in these areas together 
no matter what underlying application, tool or framework actually does the 
work.

But that would certainly require quite a bit of work and changes all over 
which would then have to be maintained in several places, I suppose. GNOME, to 
their credit, seems to manage to do this - it has never been our strength :(

Also, I can't make such a design (no clue whatsoever) nor do I care much 
personally (I can deal with Kwin,  just fine) so I feel a bit bad about 
dumping this as a problem in this discussion. Still, I think we should be 
aware of it.

To not end on a low note, let me repeat again: Martin, thanks for this change. 
It is a step forward, no matter what comes next (or not).

> Cheers
> Martin