On Friday 07 March 2014 15:12:43 Jos Poortvliet wrote: > 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).
I agree that the split is a good thing, and it seems we're all on the same page here. As for the more general System Settings discussion: Please have a look at this thread in the VDG forum where we're discussing the issues you're mentioning: http://forum.kde.org/viewtopic.php?f=285&t=119951 Feel free to join this brainstorming if you like! Cheers, Thomas _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
