KDE 5.0, The Future Is The Past
As you probably already know, Qt 5 Alpha has been released for your consumption by Nokia labs. As we move closer to mid-life for KDE 4.8, we can see KDE 4.9 looming around the corner. With a 4.9 release by the KDE team and an alpha quality build of Qt 5 just a download away, one thing is certain. KDE 5.0 is coming. I’m sure you remember the rough road KDE 4.0 traversed to get where it is today, and while the initial releases upset a lot of users, it was worth it to get where we are today. KDE 4.8 is awesome in every way. It works great on a wide range of hardware, and older hardware too! The KDE 5.0 release, on the other-hand, is filled with mystery. That’s what were here for! Here is a list of things that we would like to see in KDE 5.0.
1 Less Qt, more Plasma!
Don’t get me wrong, Qt is incredible. I use it in my day job to rapidly design interfaces for our products and nothing I’ve ever worked with is quite as good or as easy to use. It’s also good for April Fools jokes! It took me only about 6 hours to re-create Microsoft Outlook in Qt, and sell it as a news story on April 1st. The results are very convincing!
That said, Qt applications are boring in this brave new world of touch. Of course the default Oxygen theme looks great, and in my opinion, better than anything the competition is bringing to the table, but plasma is the technology that will bring KDE full circle between point-&-click and touch-driven interfaces. This is already being accomplished to some degree in the Plasma-Active community and being executed on the Vivaldi tablet.
My gripe with this is not about touch however. Programs like ReKonq, Dolphin and Calligra should all get the Plasma treatment. With Qt, the KDE team will always be stuck in a world of legacy interaction between the app and the user. In order to move forward, Plasma must finally be fully exploited.
2 Overhaul System Settings
KDE is already the king of configurability, but that flexibility comes at a price. Some tasks or configuration options that should be trivial, are not, and in this way I believe that the Gnome Project is doing a few things right. I want on/off switches.
Nothing could be more simple than being able to simply turn a service or feature off, without having to make decisions about how much of it you want to turn off or on. Simply allow me to turn it off. Nepomuk and Akonadi are perfect examples of the need for this. I shouldn’t need to discover ~/.config/akonadi/akonadiserverrc and change;
How does your average user figure this out? They don’t. They just lose cpu cycles to it, unaware of the waste in power and resources. In some cases, on older hardware, the performance impact is so great that a user may abandon KDE altogether and simply decide that KDE is too slow.
Some items in system settings have been fragmented unnecessarily for some time, leading to user confusion, expecialy when configure the look & feel of the environment.