Forgot your password?
typodupeerror
KDE GUI Open Source Linux

The Road To KDE Frameworks 5 and Plasma 2 89

Posted by Unknown Lamer
from the greenspun's-tenth-rule dept.
jrepin wrote in with a link to an article about the steps being taken toward a Qt5 based KDE 5 and Plasma Workspaces 2. From the article: "KDE's Next Generation user interfaces will run on top of Qt5. On Linux, they will run atop Wayland or Xorg as display server. The user interfaces move away from widget-based X11 rendering to OpenGL. Monolithic libraries are being split up, inter-dependencies removed, and portability and dependencies cut by stronger modularization. For users, this means higher quality graphics, more organic user interfaces and availability of applications on a wider range of devices. Developers will find an extensive archive of high-quality, libraries and solutions on top of Qt."
This discussion has been archived. No new comments can be posted.

The Road To KDE Frameworks 5 and Plasma 2

Comments Filter:
  • Remote desktop? (Score:4, Insightful)

    by Anonymous Coward on Wednesday January 23, 2013 @12:29PM (#42670331)

    NX is already pretty much unusable with compositing DMs, do they have a solution for remote desktop connections?

  • by Enderandrew (866215) <enderandrew AT gmail DOT com> on Wednesday January 23, 2013 @01:26PM (#42671003) Homepage Journal

    KDE 4.0 was missing a lot of expected 3.5 features, but a lot of the bad reputation it received were from terrible Kubuntu packages. The Kubuntu maintainers admitted they didn't understand the new build process or what they were doing. Canonical pushed it way too early and pushed crappy packages, but KDE took the blame. Early KDE builds on openSUSE, Arch, Fedora, etc. didn't have the same problems.

    And honestly, I think only a year later (KDE 4.2) they had a great desktop for everyone.

    The shift from KDE 3 to 4 (and Qt 3 to 4) meant a massive rewrite, and having to reinvent most of their core features.

    KDE 5 sounds more like an evolution than revolution, so it should be smoother this time around.

  • by loufoque (1400831) on Wednesday January 23, 2013 @01:50PM (#42671363)

    The summary essentially says "KDE is going to look better". Where are the screenshots?

  • by Tough Love (215404) on Wednesday January 23, 2013 @02:44PM (#42672009)

    KDE devs: Please do not screw up Kmail more than it already is. In fact, please put serious thought into restoring the good old filesystem-based folder database and just do away with that horrible Akonadi mistake that is dog slow, when it works at all. Running critical apps on top of a full blown database may look like a good idea on a Presenter slide, but in reality it is just cruel and unusual punishment.

    I know this isn't strticly related to Qt5, but just try to keep it in mind ok? Thxbai.

  • by Anonymous Coward on Wednesday January 23, 2013 @02:49PM (#42672081)

    KDE 4.0 was missing a lot of expected 3.5 features, but a lot of the bad reputation it received were from terrible Kubuntu packages.

    KDE 4.10 is still missing a lot of expected 3.5 features. I'm sure it's much closer to feature parity now (I'm assuming you can finally manage your system-level wireless connections in KDE, maybe fonts in KOffice even use decent kerning), but go back to KDE 3.5 and just look at the printing system. Seriously, just look at all of the things you can do to a printed document. Now look at the KDE4 one. Maybe KDE5 will fix this...

  • by NotBorg (829820) on Wednesday January 23, 2013 @04:01PM (#42672845)
    One of the interesting bullet points:

    Reduction of duplication with Qt by removing classes and using their Qt alternatives

    A lot of classes were rewritten way back in the day when the licensing of Qt was under fire. Once those issues went away there really wasn't much point in continuing the duplication of effort. Bringing the two back together is long overdue. In the long run it could bring greater stability to KDE applications since more developers will be working on improving the same framework instead of two independent but close frameworks. This is good for both Qt and KDE.

White dwarf seeks red giant for binary relationship.

Working...