Learning More About KDE's Plasma Next Desktop

[pingufunkybeat]

No you are pointing out that KDE was chosen because its aging UI looks the same way as the aging winXP.

No, I'm pointing out that it was chosen because it is more functional and usable than alternatives. People deploying Linux on a large scale care about practicality over opinions of rabid teenagers and their holy wars.

[Emdek]

There is one big issue with Plasma2, forcing QML, so lots of already existing applets simply won't work without porting from QGraphicsView.
And it won't be easy for more complex stuff...

[Emdek]

@Honton, it has nothing to do with Qt...
It's Plasma team decision, maybe they don't care about third parties anymore (which would be funny since in early days of 4.x they supported / wanted to support lots of existing widgets, like these from Google or Opera), QGraphicsView is still available in Qt5, but Plasma doesn't use it anymore.
It has nothing to do with CLA either, stop pasting the same nonsense in almost each Qt/KDE related thread, it is really annoying.

[Emdek]

@Honton, sure it was, Nokia used to be Platinum sponsor of KDE, whole KDE, not only Plasma.
And the issue with QML is that it is simply still not up to the task, without tons of bindings, sometimes making complex stuff even more complex.
Also there is no such thing as Qt needs in this context, and Digia seems not to favor QML over regular widgets, treating them almost equal.

[mgraesslin]

I meant the Nokia-days of Qt. Nokia DID sponsor Plasma Active as a non-KDE thingy, and this whole crappy ideas of activities. The most ridiculous was the "vacation planning mode".

no, Nokia didn't and I don't even want to know where you got that idea. And to make it quite clear: Qt is not responsible for our teams decision to only do UI in QML and abandon any other language or QGraphicsView. If you think we would do stuff because of the CLA and cannot change the direction of Qt you are completely wrong. I just integrated some patches into Qt to get support for features we want in Plasma.

[GreatEmerald]

Ack, stop replying to Honton, it makes my (and probably quite a few others') ignore list be not as effective.

[danielnez1]

Well. The old Qt4 is dead so KDE is forced to move. You can argue KDE needs to this now, but that is not the same as saying it fits KDE's needs very well. Of course KDE will announce this a beneficial move thoroughly planned with Digia, because that is how marketing works. It is a simple matter of getting away from the rather unmaintained Qt4, not adding features or value to the users. The KF5 lib splitting might be a good idea. Because there is so much old cruft that rightly should have been deprecated a long time ago. This never happened so now it gets the necrosis treatment; Cutting away dead tissue.

I don't get how moving on to Qt 5 is a bad thing. It is just like people migrating to GTK+ 3 form version 2.

Regarding KF5, I thought the main aim of KF5 was to make it easier for App developers to use specific parts of the KDE frameworks without having to pull in large portions of the frameworks.

Gnome and GTK are synchronized, while KDE always is on neck break rollercoaster ride trying to keep up with its CLAed self-governed commercial toolkit.

You have probably touched on the fundamental problem with GTK+, unless you are writing programs targeting GNOME, GTK+ doesn?t offer you much unlike Qt (i.e. decent cross platform support). As for your debunked and tired old CLA arguments, you should find something else to complain about.

[danielnez1]

Gnome and GTK are synchronized. Qt does not give a damn about KDE's release schedule. If you can't see the difference then no one can help you.

I fail to see your point, GTK+ releases are not in sync with other products that use it, i.e. XFCE, GIMP etc. Your clutching at straws... again.

[zanny]

Gnome and GTK are synchronized. Qt does not give a damn about KDE's release schedule. If you can't see the difference then no one can help you.

How is a synchronized release better? It is much better to release a toolkit, go through a few major revisions to iron out bugs and reach feature completeness, and then port your entire desktop environment and application suite to it, than to release a new toolkit version and entire revamp of your entire software catalog same day and expect it all to go dandy.

It also helps that KDE can see much more community participation in the kde5 effort because people are now experienced in qtquick2 and the new qt5 apis like the xorg one. If they were trying to match their applications against a non-finalized toolkit with potential near release breakage it would require a lot more effort.

[TheBlackCat]

How nice, anecdotical evidence. "Look at me, I signed the CLA and got some stuff commited". You working for free does not give you any power.

What, do you have any idea what "anecdotal evidence" even is? There is no anecdote there, you simply got caught lying again.