[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Widget and windeco themes for Plasma Next
From:       mutlu_inek <mutlu_inek () yahoo ! de>
Date:       2014-04-25 12:49:11
Message-ID: 1398430151.22984.YahooMailNeo () web28802 ! mail ! ir2 ! yahoo ! com
[Download RAW message or body]

Dear KDE developers and designers,

I have read your debate about window and windeco themes for Plasma Next. I found many \
of the arguments used against new styles unconvincing and felt like I had to write a \
reply. There are at least three issues that underly the opposition to broader \
changes. One has to do with release cadence, one with the idea of incremental changes \
and the third with the perception of a lack of quality when it comes to QtCurve. \
Let's deal with them one by one:


A) The Question of Which Release(s) to Introduce Changes in:

The argument by those skeptical of vast visual changes goes as follows:
- The first release should show continuity (I believe in the sense of being \
                conservative and trusted).
- The second release can have a completely new design and be (in a way) experimental, \
                hinting at the newity of the new Plasma.
- By then, the new theme would be tested.

BUT:
The first release is a kind-of "beta" release, one not for a general audience. This \
is the very kind of release in which you introduce new stuff that you are not sure of \
being polished. Why introduce a completely new theme in the second release, if that \
is the one that is supposed to be generally consumed? Where is the testing happening? \
In the second release? Or by the few people who choose to change their defaults? I'm \
not sure this is well-thought out. Even less so, if making a QStyle theme might take \
"years."


B) The Idea of Incremental Changes:

The argument about this is:
We don't want to shock our users by suddenly changing their UIs to something they \
might not like as much as Oxygen. Thus, we change one element at a time.

BUT:
Fist, continuing my point about releases above: The first release is not for general \
consumption. Screenshots of that release (whether changes are small or large) will be \
around for many months before a release for a general public is made and by then it's \
fairly known what it will look like. Secondly, and more importantly, incremental \
changes are either going to look bad (flat mixed with 3D, gray mixed with the new \
blue colors, etc.), making all releases until change is achieved look weird in one \
way or another. And introducing changes gradually does not help test these changes, \
as they belong together. Crude example: You cannot test a flat button in a 3D Design, \
but you'd have to make the entire design flat to test the button. And thirdly, \
artists will have trouble doing incremental releases. They will have to modify the \
old designs or the new ones (or both) to make them clash less. Changes to the new \
designs in order to make the transition fell less bad will have to be undone and will \
be met by criticism from people who got used to these temporary compromises. All this \
will result in extra work, much lower motivation for artists, weird compromises, a \
false sense of 'continuity' and a lack of real testing of the new design.


C) Quality-related Worries Regarding QtCurve:

The main argument here is that QtCurve-based styles may not look as perfect as a \
QStyle theme and cannot do all things a QStyle theme might be able to do. Thus we \
need a QStyle theme.

BUT:
If the claims that a) the designers don't know C++ and that b) making a QStyle-based \
theme is very hard, possibly taking years) are true, then it will be unlikely that we \
will see this wonderful group of designers make a new style for all UI elements. \
Also, it would mean that we won't have a new style until waaay later, meaning not \
only not for the first or second, by maybe not even for the third or fourth releases. \
Maybe we won't have a new style at all, but have to stick with Oxygen for much \
longer. Or did someone volunteer to work on a QStyle for years based on the proposals \
by our designer? Likely not. This might also mean that we will probably lose some of \
the spirit the design groups currently has, maybe even the group itself. Why would \
anyone invest all this time creating, debating, etc. if it will take years to look \
good? Maybe by then, other styles will be chosen, so we can expect that it is not \
that unlikely that nothing will come out of the work put in now. The biggest problem \
here, however, is the assumption that a new style needs to be so complex that QtCurve \
                has to fall short. What we need to do it answer the following \
                questions:
- What does a new style need to do in terms of features? What are necessary features \
                for the vision(s) of the designers?
- What is QtCurve able to do?
- What are the exact shortcomings of QtCurve? What is bad about it beyond personal \
                "feelings?" We need to name things properly.
- How big is this ominous "benchmark problem"? Sounds a bit like FUD (though it may \
not be, but then we need numbers).

If the result is that QtCurve can actually do a lot of what is wanted and if the \
designers are happy with it, why not use the first release that's not meant for a \
general public to experiment rather than promise slow changes that will look so-so at \
best and a beautiful design years down the road (if the designers stick around)? \
After all, the wonderful dynamics of the design group grew out of the ability to play \
around with things freely.



All in all, I think that it's important to use the dynamics of the design group and \
give it some credit for what it doing. I also think that KDE needs to test the design \
choices in a meaningful way (i.e. together) and make use of the fact that the first \
release is not meant for distros to ship to their normal users. Of course, all this \
depends on whether QtCurve can ever be enough. If not, there probably won't be a new \
style any time soon. If yes, the designers and developers need to think about how to \
use it well in order to make a great product. And we might hold it in our hands very \
soon, rather than years later.


Let me add that I believe that I'm sure it's going to be a great release, however you \
decide on this issue. But the debate was simply too vague and too much based on \
erroneous arguments, 'perceptions,' and assumptions without any backing up that I \
thought I try to take it apart.

Keep up the great work and thank you for the desktop and applications I have been \
using for way more than a decade. :)

Cheers, mutlu
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]