situation with window decorations

[Aaron J. Seigo]

On August 28, 2009, Lucas Murray wrote:
> settings that are used by people just because they "are ugly" we might
> as well remove a whole pile of other artwork-related stuff from KDE
> since there is far more "ugly" things in trunk than this setting
> (Other KWin decorations, some plasmoids, etc.).

there is a difference, at least in my mind, between (say) the "Redmond" theme 
being ugly and keeping it in there and putting additional features in our 
defaults that make the defaults ugly.

but besides that, yes, i'm all for getting rid of features whose primary 
purpose is to degrade the intended look of our work.

in this case, the answer is to simply use another theme.

> Personally I don't
> find it that ugly at all--it's not beautiful, but it's not ugly
> either.

would Apple ever ship it? would Porsche? no. it's ugly. it breaks the 
consistency and the design precepts.

when we lower our standards like that we get crap results.

when we say "no! we MUST adhere to our own standards!" then in the worst case 
scenario we get our standards and in the best case scenario people will think 
HARD about it instead of just going the path of least resistance (leading to 
crap results) and come up with interesting and better ways of doing it.

Thomas' suggestion, for instance, is pretty interesting. it might work 
perfectly well. we should try it.

but IME we don't get results like that unless we INSIST on minimum standards. 
this feature as currently implemented is a complete cop-out in that regard.

> Also removing a setting that already exists is just enticing people to
> make yet another fork.

you're probably right. but the issue here is that WE are forking OUR OWN code. 
that, i suggest, is amazingly silly. WE should be able to resist that 
temptation.

> If the blending setting is removed from both
> Oxygen and Nitrogen then I guarantee that someone will put it back and
> upload to KDE-Look within a few weeks of the final KDE release.

that's completely fine. just because someone else will do something sub-
optimal doesn't mean we should then find ourselves forced to do the same.

people who want this can use a different window theme and that's totally cool. 
but the average user should not be subjected to this and oxygen should not 
need to support it.

it is the ENTIRE reason we have multiple window decorations.

> Yes it looks ugly, but if someone really wants to make their KDE ugly
> then they will manage to do so whether or not it's available in the
> official packages or not. 

that's fine; but we don't need to make it easy to do so with our default 
tools.

it's a bit like putting broken glass on the floor and then telling people to 
"just avoid stepping on it". not a great solution.

> This also applies to distributions--if they
> want the decorations to look ugly it will be made ugly.

ditto. at least it will be obvious they aren't using oxygen.

> It's pretty
> easy to download new themes from KDE-Look and on the KWin front
> Aurorae (SVG-based decorations) is just going to make things even
> easier.

sure, and that is completely and utterly irrelevant when it comes to the issue 
of our default tools discouraging uglification.

> We have already made our recommendation to distributions and users on
> how KDE should look; they are our default settings. If they want to
> customise then I say let them, it's just another point for us to say
> that we are better than the competition.

this is also completely and utterly missing the point. if they want to change 
the defaults they can use another theme entirely. not oxygen. yes, this 
matters. because:

* if it's harder, fewer will do it

* if they do it but not with oxygen then it's a lot clearer to the end user 
and it stops messing with our public messaging around the oxygen brand

i completely realize that art direction is a bit different than most of the 
topics we're used to as software developers, but that's why we as developers 
really need to listen to those who know about these things a bit more.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090828/2da91949/attachment.sig>