I can think of a few names (Alan Day, Andre Klapper...) but I don't know them all. They are usually blamed for "not listening" but a design team can only listen so much. We can discuss the merits of their design (I believe they're wrong in a few places) but they're definitely putting design first, which is the right thing to do. The same goes for the Elementary guys.So you call KDE community working without leadership, which is right, but still they try to work as good a possible together. Who would be the leadership of GNOME?
Actually not just the core applications. Because Ubuntu has put good care to adopt the two main toolkits (GTK+ and Qt) to ease the discrepancies AND adapt the few important foreigners (Firefox/Thunderbird and LibreOffice), so they belong in the same look and feel and overall design (global menu, HUD, etc.)As far as I know the only project having strict guidelines and a leadership is Unity and the core applications.
No, KDE is unusable because it puts coding before UI/UX design.Does it make a project unusable, just because its community is very open?
Unfortunately, design can't be made out of the bazaar's model. It's a cathedral type of discipline. It requires a focused small team with strong leadership and professionally trained people focusing on the different areas of the project. There's no such thing as "open design" except for the part when the team exposes its work and leaves it to coders to implement it openly (actually this is not accurate; coders should be very close to the design team in order to accomplish the best possible implementation, but I'm trying to keep things simple here). A design team can be open to suggestions, and even show all the process' progress like in a permanent "open doors day", but can't be driven democratically or meritocratically. A project developed by a large community with focus away from design has a very tiny chance of being usable.
Of course, you might say lots of people use KDE so KDE is usable. So is the terminal, but I hope to agree that we're talking ordinary people here, not geeks who can use anything you throw at them.
I'll be happy with an 80% consistent DE and applications. KDE isn't remotely close.Apart from that, you will never be able to use 100% consistent software, because if you want that you would have to ditch all other applications not explicitly designed for that environment, because it may differ in its design.
I mentioned that already in this same thread. That's one of their design decisions I believe they're not in a position to take. IF they were strong enough they might convince application developers to go with them, but nowadays cross-platform development imposes limitations that must be observed by DE designers. That makes decisions like the CSD from Gnome an exercise in a vacuum, going nowhere. A modern DE design should try to encompass different toolkits under the same umbrella and try to interfere as little as possible with current app development conventions. At least until their own SDK becomes so ubiquitous that app developers accept it as THE way to develop. THEN it's possible to introduce "revolutionary" changes. But even then, it's wise to observe cross-platform conventions as much as possible. Ubuntu has been doing that right with Unity. (We'll see what happens with Unity 8 and the convergent SDK, which will address the desktop this year.)For example Gnome client side window decoration may look beautiful with applications that support it, but all other application with no support for it differ which is again not consistency.
I'm not quite sure you know what design is...And I have to disagree with "UI design first, then implementation", as Plasma Workspaces for example try to move to QML, where application logic and design implementation can be separated very well. Furthermore the trend is going to having one application with multiple interfaces for different from factors. Starting with the UI design first does not make that much sense to me.
I know exactly what you meant. And I intentionally told you KDE needs to put all these things you mention together under a strong leadership after a thorough design phase, executed by well paid designers (not by coders). That won't happen obviously.With "people need to separate" I did not mean the people of the KDE community, but people here judging KDE software, as they do not separate between different applications, workspaces (DEs) and UX elements (icons, theme, etc.).
Again: you don't understand design. There shouldn't exist a "KDE usability project". Usability and UX are crucial parts of design that can't be left to a side project. The design represents the very seeds of the whole project. Not a single line of code should be written without a purpose explicitly expressed in a design. KDE (the DE and its whole community) is fundamentally flawed because of this mentality, precisely.I hope the KDE usability project reaches more developers and will therefore succeed. There will always be individual developers that refuse to accept guidelines, but that will exist in every open community and guidelines are guidelines not rules.
You have a serious problem understanding design. It's not about looks or developer guidelines (those are minuscule parts of the design process). It would take a lot to explain what design is in a short forum reply, so allow me to suggest some learning on the subject. (No offense intended. You don't have to know what design is to live happily, but if you want to talk about it, then you definitely do have to.)In terms of themes KDE software comes with pretty great consistency: The oxygen theme looks pretty good for KDE/QT/GTK applications.
There are of course exceptions like firefox or libre office that use strange toolkits and therefore do not support gradients used by the oxygen theme.
Here one can again see one fundamental problem with "design vs. consistency": The oxygen gradients are beautiful imho, but not all toolkits support it. So from a design point of view it is nice, but it will add a bit of inconsitency. Same goes for the aforementioned Gnome client side decorations.