Slashdot Mirror
KDE Frameworks 5.3 and Plasma 2.1 – First Impressions
jones_supa writes Ken Vermette has done a write-up on his experience with the new KDE desktop encompassing Frameworks 5.3 and Plasma 2.1. For starters, some patience is still needed for apps to be ported to KF5, and most of them will be KF4-based for now. Many of the widgets you may have used don't exist yet either, but the good news is that the Plasma goodies which do make an appearance are universally improved. The new search widget is shockingly fast and the notifications tray has been reworked. Visual outlook of desktop has been simplified and things don't feel so tightly packed together anymore. The system settings application has been completely regrouped more by goal than underlying mechanics. Unfortunately the desktop stability leaves a lot to desire: there was several crashes and Plasma had at one point managed to forget colour and wallpaper settings. However the developers seem to be knowing what they are doing, and there's a real feeling that this software will reach rock-solid stability very quickly given the state of it as it stands.
The title is wrong. Its plasma 5.1.1
Ehhhhhh...... Gnome has always had that "pretty but vacuous" look to it, kinda like one of my ex.
...Steve
Visually, kde5 is really nice, but not nice enough or stable enough or feature rich enough to upgrade from 4 at the moment.
Im sure the people who grew up on kde 3 said the same about kde4 when it came out but early adopters like me put up with it because it was shiny and had not realised how powerful kde 3 was.
Not quite the typical 3 step list leading to profit, but here it goes:
1. Developer: This is so cluttered and ugly. Nobody needs all these features. Lets get rid of the old and do something new - it will be clean, pretty and well designed.
2. User: But now I can't do xxxxx - this sucks! You are idiots!
3. Developer: Ok, We'll add this back in.
4. User: Ok, better. Can you add yyyyy too?
5. Developer: Sure. And how about feature zzzzz as well?
6. User: Awesome. Its finally usable.
7: New Developer: This is so cluttered and ugly. Nobody needs all these features. Lets get rid of the old and do something new - it will be clean, pretty and well designed.
So sorry if I don't get too excited...
Peter.
KDE on wayland is not complete yet. There has been work for kwin, but one thing is sure: if you want to use it on wayland, you will need, as usual, systemd. Of course, the author points out that this does not imply you will also need to install a web server and a ntp daemon, and that the dependency is on the API not on the program itself, but then show me an alternative implementation i can use. You know, systemd brings nice new APIs and so on, but then I read about the next thing systemd broke. Its in the man page of the shutdown command that this should work.
The tree widgets on the left are mismatched: some solid lines, some spaces with alphanumeric characters; the alpha characters are black, yet the lines are gray visual noise that creates visual processing and cognitive load for no reason, adding nothing.
The parenthetical text at the top has a title whose margin (left whitespace to other widgets) is significantly different from the text below it; there are spaces between the parentheses and the text, which no text or print style guide in the world endorses because it separates the parenthetical indicators from the parenthetical text, when they should be tightly bound for clarity.
The window title preserves the absurd convention of using both the binary name and a descriptive title together, and separates them with a typographical element (an em-dash) which is inappropriate in a label or design element because it is asynchronous—it indicates a delay in interpretation and pronunciation (as the em-dash just a few words ago in this paragraph does) and thus suggests long-form reading, which is not the intent for at-a-glance window titles (unless you don't want them to be very usable).
The title of the list widget, "Information Modules" is superfluous and redundant; the user starting an "About" dialogue expects to see "information" from the start, and they do not need to know about implementation ("modules").
The resize handle contrasts significantly with the window background, drawing undue attention to this particular area of the window above others (why is it "louder" than the window title, for example? Window controls should be secondary to window content and all at the same visual "volume" for usability).
In short—they still don't get it; they are signaling, in conventional ways that most users process subconsciously, thought habits and forms of attention that are not contributing to efficiency and use, but rather detracting/distracting from it. This is the same old KDE with poor, unprofessional design that leads to cognitive clutter. It's not that KDE has "too much going on" but rather that KDE has "too much going on that isn't actually functional and adds nothing to users ability to get things done).
Yuck.
STOP . AMERICA . NOW
KDE4's apps still work under it, too. I'm using it fine, though I'm missing the "IM Presence" widget for kde-telepathy.
I actually haven't been seeing crashes or other serious problems so far since about the last couple of releeases (KF5.4), just missing "KF5-native" features from KDE4.
Hacker Public Radio is our Friend
Eric Raymond wrote a horrifically amusing screed about why open source interfaces suck so bad, back in 2004. It was called "The Luxury of Ignorance", it laid out fairly good guidelines for how to do an interface *well*, and Gnome has ignored *everey single one* of the guidelines. I'm asking about this KDE, did they follow *any* of these guidelines?
= So, if you are out there writing GUI apps for Linux or BSD or whatever, here are some questions you need to be asking yourself:
* What does my software look like to a non-technical user who has never seen it before?
* Is there any screen in my GUI that is a dead end, without giving guidance further into the system?
* The requirement that end-users read documentation is a sign of UI design failure. Is my UI design a failure?
* For technical tasks that do require documentation, do they fail to mention critical defaults?
* Does my project welcome and respond to usability feedback from non-expert users?
* And, most importantly of all...do I allow my users the precious luxury of ignorance?
= Postscript, 26 Feb 2004: I added the new fifth question based on an excellent suggestion in LWN's comments on the story.
= And here are some more design rules, from Nico Kadel-Garcia:
** Can you gracefully and easily duplicate your tools and configuration for a similar installation? Is it documented? (RedHat and CUPS is no help with this, either, most of the print-drivers wend their way from the foomatic and other tools into the CUPS setups without a lot of hint of how it works.) [For cups, the answer is "you can duplicate it easily, but it's a *secret*"! Every configuration should be built and recompiled from the source tarball! What are you, a n00b?]
** Is installing this toolset likely to replace or break something already in place (such as LPD based printing packages)? If so, explain how to gracefully do the transition.
** Are there settings you can do from the command line or hand-editing config files that cannot be done from the GUI? Are they documented anywhere? Does using the GUI erase these settings? (The answer for CUPS is "Yes, you can flush all sorts of hand-edited things this way!". This was an incredible problem for NeXT stations and remains a big freeware GUI problem, although most try harder to address this. Webmin is an excellent example of how to do it right in most cases!)
** Are all your important features mentioned? The automatic flat text->Postscript conversion is one such feature, and despite its presence in the tarball tools and default use the CUPS claim it's not theirs and not their problem.
Grammar nazi mode: actually I think you'll find the plural of ex is oxen.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
Seems like you're wrong, they added support for systemd dbus calls, but no dependency on systemd libs. It will use it if it's there, but doesn't require it.
This message has a small description of what they did. Too bad other developers don't want to be this conscious and prefer to link with systemd libs, needed or not.