Trinity and the Challenges of Continuing KDE 3

This morning, while having my usual Cafe Latte (albeit this time in Berlin instead of at home sweet home in Nijmegen), I read about the Trinity project, which is an effort to revive KDE 3. I think this project nicely shows the advantages of Free Software. While the vast majority of KDE contributors agrees that KDE 3 is a dead end, technologically, these two guys (according to the somewhat sparse information on the website) are trying to continue to support and feature development on KDE3. Now I see a couple of real challenges for this project:

  • Maintainance – KDE 3 is a large codebase. You need a good amount of people with domain knowledge of many different areas to effectively maintain a project like KDE. I see some of the first roadmap tasks for Trinity are updating the build system to deal with all the updated developer tools (e.g. newer autotools versions).
  • Upstream Support – Official support for Qt3 ended on July, 1st 2007. nearly three years ago. Now this is not necessarily a problem (as Qt, too is Free Software), but it puts additional stress on the maintainance team — you have to provide support for Qt as well, not only KDE. This is also true for many other upstream components
  • Community Support – KDE has many applications, and their developers take conscious decisions wether or not to support a specific version. Moreover, developers take great pride in their creations. Patches made to those components (even if it’s just maintainance) should be reviewed by their developers (who also happen to know the codebase best, have domain knowledge, and so on). Now the resources of these subprojects are also limited, and many decided to effectively end of life the support for their KDE 3 versions and fully concentrate on the KDE 4 version.
  • Interoperability – In KDE 4, we introduced a couple of new technologies, D-Bus as our inter-process-communication mechanism, and the FreeDesktop icon naming scheme for Oxygen, KDE4’s artwork pillar. This was (and is) not possible with KDE3, and is actually only the tip of the iceberg of many improvements that have gone into KDE4, and which cannot be taken advantage of by programs based on KDE 3.
  • Testing & QA – While the whole KDE project switched to KDE 4, we realised that releasing KDE 3 would be a lot harder in the future, since we heavily rely on the community testing the code before releases. This assures that the code is of sufficient quality and actually works. This process is not quite trivial, it needs testing, but also reviewing of changes that go into the codebase. For reviewing code you need familiarity with the APIs used by it, the actual codebase that’s being changed, and on top of that domain knowledge of the area your program is used in (for example if you’re writing a mail client, you should know mail protocols, and so on.) Again, you need a larger team to assure sufficient quality of the code you release.

For the above reasons, the KDE community has decided to not do releases of KDE 3 anymore. Technologically, it’s a dead end since many architectural, structural and environmental aspects of KDE 3 couldn’t be solved in KDE 3. If we just kept releasing KDE 3, we wouldn’t be able to assure sufficient quality and enough support so people wouldn’t be left out in the rain. Or put in other words, it would give KDE a bad name. The KDE3 branch in our SVN source code repository remains frozen for new features, bugfix patches are allowed but make very little sense, since there’s no plan to release new versions of KDE 3.x. That’s why the Trinity developers are using a work branch.

Those are challenges the Trinity team is facing now. Some of them can be solved by pouring enough manpower, tender love and care into it. Others aren’t easily solvable (think IPC) within KDE 3. Whether or not the Trinity team will succeed in maintaining and developing KDE 3 remains to be seen, but it’s certainly not an easy task. Then again, easy tasks are boring, and the Trinity team is validating the Free Software development and licensing model. In any event, the KDE community supports the efforts (for example by offering infrastructure in the form of source code repositories), and would like to see Trinity as another blooming subproject inside the KDE community.

Posted in KDE

17 thoughts on “Trinity and the Challenges of Continuing KDE 3

  1. Maybe in hindsight it would have been better to do a straight port of the whole KDE3 to Qt4 and then refactor from there. Sure it would have taken a year or two more to get where KDE is now, but you wouldn’t have lost so many people and so much momentum in the user/distro space. And projects like Trinity would have a much better starting point.

    1. @Tom: problem is, Qt3 and Qt4 are different enough to make a straight port with feature parity plain impossible, for instance the item views like those used in the file manager between Qt3 and Qt4 have exactly zero in common (and is a good thing even since this fixed some serious shortcomings)

      1. That’s what Qt3Support is for.

        Now it’s true that even porting to Qt3Support is far from trivial (I’m speaking from experience there), that a badly done port can be buggy and crashy (I’ve seen that too) and that doing both that and what we now know as KDE 4 would have meant to have 2 big efforts. But I don’t believe it would have been impossible.

        Of course, what some people would have preferred would have been to do ONLY the straight port to Qt3Support, and then gradually replace Qt3Support with native Qt 4 stuff without any changes in functionality, but not to do major changes at all. At this stage, I’m not sure whether this would have been a good idea. It would have eliminated a lot of frustrations with KDE 4.0, and some feature regressions which still persist, but it would also have prevented many of the improvements KDE 4 is now being praised for. It would also have made KDE 4 extremely boring both for developers and for users.

        I am maintaining an application (Kompare) which got ported using the “straight port” method (basically, it was planned to be scrapped in favor of a development branch which never reached production status, and I saved it from being removed in 4.0.0 by rushing a port of the same old KDE 3 code to KDE 4). It still uses some Qt3Support and kde3support stuff (some has been eliminated, but there’s still some left) and it has basically no new features compared to the KDE 3 version. It even has almost the exact same bugs as the KDE 3 version. But it also didn’t lose any features, which is IMHO important. There’s always a tradeoff.

  2. Two guys cannot keep KDE3 alive. But two guys could port their favourite stuff to Qt4/KDE4, e.g. Kicker or Superkaramba or KDevelop-plugins or missing features in application XYZ.
    I think trinity is useless, there will be a time when nobody wants to use the KDE3-versions any longer, and these two guys won’t stop that.

    1. I agree completely. I think their time would be much better spent fixing the problems they perceive with KDE4 or implement the features they think are missing in KDE4 rather than a probably futile effort to prop of KDE 3.5. There is no reason they can’t get everything they like from KDE 3.5 in KDE 4, and doing so would be a LOT less effort than trying to just maintain KDE 3.5, not to mention implement new features and bugfixes.

  3. @Tom: Well porting to Qt4 alone wouldn’t have done it. A working port of KDE 3.5 would have needed a port of the build system, too (hello CMake :-), next virtually all people (regardless what they think about KDE 4) were and are bored by the KDE 3.5 artwork (hello Oxygen :-)… And of course quite some parts of KDE 4 (applications) were a first “just get in compile and run on Qt 4” with the help of Qt3Support in Qt4, so exactly that what many people demaned.

    So in any case a strict functional port to Qt4 of any piece would have required several more things beside “just trying to compile on Qt4” and I doubt if people would have liked this approach more.

  4. What KDE3 applications are not ported to QT4 yet and how much effort would it take?

    When KDE4 was announced there were many promises e.g. platform independence. Why aren’t the MAC OS X and Windows port stable yet and what still needs to be done there?

    What can be done to improve the translation status of KDE4 applications?

    What happened to Raptor?

    When will Plasma be crash-free for normal use? KDE 4.6?

    How can contributions to KDE4 be simplified? How to simple set a KDE4 built environment with TRUNK that “just works”?


    1. > What KDE3 applications are not ported to QT4 yet and how much effort would it take?

      It depends also on you also; there are people whose normal KDE use involves applications that were ported to KDE4.
      Do you still have kde3 application which you use?

      > When KDE4 was announced there were many promises e.g. platform independence.
      > Why aren’t the MAC OS X and Windows port stable yet

      The fact that KDE4 is more platform independent than KDE3 does not imply it will compile,
      work, and produce packages of itself without anybody doing the job.
      There are some people working on the Windows port, but quite less on the Mac one.

      > and what still needs to be done there?

      I guess you should ask to the kde-windows and kde-mac teams.

      > What can be done to improve the translation status of KDE4 applications?

      There were translations as well in KDE3, I don’t see what it has to do with this blog…
      Anyhow, back to your question: the way is always the same, ie contact and work with
      the translation team of your language:
      (Note also the trunk statistics reflect the development version, which not all the teams
      translate everyday; you might want to look at the “stable” statistics for the current
      stable serie, ie KDE 4.4.x.)

      > What happened to Raptor?


      > When will Plasma be crash-free for normal use? KDE 4.6?

      Note also kicker had “normal use” crashes, and a couple got fixed with quite late versions like KDE 3.5.10.

      > How can contributions to KDE4 be simplified? How to simple set a KDE4 built environment with TRUNK that “just works”?

      Just follow the instructions on http.// ?

  5. I think that KDE4 is still a development (not stable) project. Nearly every user interface feature, which is simple and transparent in KDE3.5, is difficult or not implemented in KDE4. I could attach here a huge list of absolutely necessary features that are not implemented in KDE4, but I want to be concise. It is very difficult to configure the desktop in KDE4, and it still crashes from time to time. The last version I tested is KDE4.3.5 and it is still MUCH WORSE than KDE3.5.

    Look at the Mozilla team. Any feature of Firefox 1 is realized in Firefox 2 and any feature of Firefox 2 is realized in Firefox 3. It was an ethically wrong decision to issue KDE4.0, while you knew that it did not support EVERY feature of KDE3.5. Surely, you can force users to use KDE4 finally, but it is like a rape.

    1. So I guess it never occurred to you that the problem might be that you are using KDE 4.3, when KDE 4.4 is the current version and KDE 4.5 is just around the corner? In 4.4 I only get plasma crashes when first loading buggy scripted widgets, and there were a lot of features in both 4.4 or 4.5.

    2. KDE 4 will never support every feature that KDE 3.5 did. 4 does however contain a number of features that 3.5 never had, and can do many of the things that 3.5 could do, but in a much more elegant way. You have to take into account that 3 and 4 are just very different beasts, and that with KDE 3.5 technology, many things we do today, and we’ve come to rely on were simply not possible.

      As to forcing people to use something, that statement is ridiculous. Firstly, KDE never forced anybody to use the 4 version. In fact, we’ve been very clear as to the status of the 4 series, and have since the release of 4.0 spent ridiculous amounts of time on improving its stability and completeness — and that’s very visible. If your distro automatically updates you to a version you don’t want, choose another distro or pay more attention to the software you’re installing.

      As to comparing anything here to rape, that’s completely out of proportion, please tone down.

  6. KDE 4.4 is nowhere close to prime time, and never should have been released yet. Anyone working on developing the KDE 4.x platform should know it or they are fooling themselves. If KDE 4.x is up to 4.4 and yet still crashes as much as it does, then the KDE folks are not using a proper quality control and revision system. This platform is not ready for 4.0 status, let alone 4.4/4.5 status. It hasn’t been properly tested and patched for those revision numbers.

    I’m the founder and lead developer of a KDE based distro. Our distro is still using KDE 3.5 because many of our users practically hate KDE 4.x because of lack of usability/features & serious crashes. KDE 4.x is bloated and performs poorly compared to KDE 3.5.x. We applaud the Trinity team for their efforts in maintaining KDE 3.5.x at least until KDE 4 is no longer performing like a late alpha/early beta. I’m not against change or progress, but change just for the sake of “progress” is an exercise in vanity, and changing version numbers does not make a project stable. Especially if the newer product simply cannot do what the former can do, or is many times less stable than the previous version!

    Even though we are a small and very recent distro, we are now looking to see if there’s some way our 4 person dev team can help the Trinity project. I would encourage other dev teams look into doing the same thing until KDE actually releases a product worthy of normal use by Linux users.

    KDE should pull KDE 4.x out of production and maintain/support KDE 3.5.x until KDE 4.x is truly a stable, feature-rich product that is actually ready to use.

    1. If you decide to provide KDE 3.5, that’s fine as I mention in my above blog already. I’m also outlining some problems when shipping KDE 3.5. Ultimately, it’s a trade-off of course: Is supporting KDE 3.5 and Qt3 on your own more effective than working with the rest of the ecosystem on 4? This is a question only you, and your users can answer. For the vast majority of others, the answer is the latter.

      Can you give some example bugnumbers your users suffer most from, or haven’t those been reported and triaged yet? You can just lean back and wait until others have solved all your problems. For others to work on those issues you seem to be facing, your participation is needed, though. So I’m not sure your attitude of vague statements about quality, and “armchair developer” statements such as telling others to pull software which is in use for nearly two and a half years by millions of people. How would one be able to do that, by the way? And if one did, how would not releasing updates help any users at all?

      I personally find my KDE 4 desktop to be working well and stable. Of course that is highly dependant on the use case, and on the underlying platform. Stability seems to vary between various distributions, so if ReveLinux has problems with KDE 4, comparing your underlying stack (Xorg and driver versions, among others) to other distros might give you some clue. Especially graphics performance seems to vary a lot (in general, I find the newest Free drivers for intel and ATI working best).

      1. This is not the place or platform to report specific bugs.

        My point is simply that most of the Linux community in general knows that KDE 4.x was released before it was ready. Can you honestly tell us that KDE 4 is as intuitive, feature rich, and generally ready for prime-time as KDE 3.5.x? I understand how anyone close the the project would feel pride with the work they’ve done so far, and I wouldn’t take anything away from that. I’m not here to tear down the accomplishments of KDE 4. However, it is my opinion along with many other people that it was rushed out the door before it possessed the level of usability of the existing platform.

        KDE 4 has great potential that we hope is achieved soon.
        When you quoted statistics on how many people are using KDE 4.x, does it account for how many users felt they had little or no choice because their current apps would no longer be maintained or supported on the older platform?

        I say these things because I want KDE 4 to succeed, not tear it down.
        I’m also attempting to point out that there’s an element of group-think surrounding the KDE project, and it’s causing those involved with the project to be blinded to some important things. I know it is hard for some people to listen to what I’m saying with an open mind, and it will likely turn off some folks. However, we need to have an open & honest discussion if we want KDE & Linux in general to achieve greatness.

        KDE users loudly voiced their disapproval when KDE 4.x was initially released, and the din gradually faded as users came to believe and/or accept that they had to settle with the options presented to them when their distros moved to the new platform in the name of progress. If you doubt my claims about how users felt, Google is your friend. ;)

        This article says it all in the following paragraph:

        The Trinity Project Picks Up Where KDE 3.5.10 Left Off
        Posted by Danny on Tuesday, May 25, 2010
        Labels: KDE 3.5.10, Kubuntu, Legacy, Linux News, old school

        “Hey, pst! Yes, you! I know you’ve been crying yourself to sleep at night ever since those mean, mean people developing the K Desktop Environment decided to radically change the way your favorite DE worked and release the dreaded “4” version. Good news! There’s no more need to get over it and move on with your life, as, apparently, the God of open source decided to bring you a fork of KDE 3.”

        Did the folks at KDE know about and listen to the real user feedback, or was it filtered by their own perceptions?
        If we all want KDE 4 to be great, then we have to be open to criticism and feedback from end users.
        My end users are telling me that KDE 4.x makes their computing experience more difficult instead of improving their computing experience. If you use Google, you will see that the feedback says KDE 4 is improving but isn’t ready for prime-time yet.

        Trinity is one of many responses that can take place when a new platform disorients and/or alienates users.

        Just for the record, we don’t “lean back and wait until others have solved all our problems”, my devs have contributed to both our upstream distro and to KDE. As founder of our distro, I insist on my devs doing so :)
        This post is one of many ways that we are active and contribute to the community, in the form of open discussion as well as code and bug reports. These types of honest discussions are just as important as any other process in the open source community as a whole. I donate money to projects we rely on as well. ;)

        We are a small distro and not publicly released yet, but we believe in open source.
        Open source also needs to have open discussion in order to ultimately succeed. :)

        1. Can you honestly tell us that KDE 4 is as intuitive, feature rich, and generally ready for prime-time as KDE 3.5.x?

          In the majority of aspects, it’s even a lot better. So yes.

  7. I hope they succeed, as I really like KDE 3 and I think KDE 4 is going in the wrong direction in so many different ways.
    I will be one of their users, as I want to go back to KDE. I tried for a while to use KDE 4, but had to switch to FVWM since KDE 3 doesn’t build for me anymore.

    Thanks for the effort!

Comments are closed.