|
|
Subscribe / Log in / New account

Trinity Desktop Environment: Keeping KDE 3 alive

November 22, 2011

This article was contributed by Bruce Byfield

At this point, the Trinity Desktop Environment (TDE) hardly needs a conventional review. After all, as the numbering of the new 3.5.13 release suggests, TDE is a continuation of the KDE 3 series, and anyone who is even remotely interested must have seen the basic desktop many times. Instead, TDE raises some questions. For instance, how well can a desktop first released nearly a decade ago adapt to modern computing? Just as importantly, what are its chances of survival, and what directions might its development take in the future? To judge from the new release, these are important questions.

The latest version of TDE is available as packages for recent releases of Debian, Ubuntu, Red Hat, and Fedora. However, packages for releases made in the last month or so, such as Fedora 16, are not yet available, while packages for Slackware, openSUSE and Mandriva are mentioned as being in development. Alternatively, you can download a Kubuntu Live CD or build TDE from source.

If you install TDE, note that its packages are not interchangeable with packages from other sources for the KDE 3 series. Nor can KDE 4 releases run them. Installing TDE requires dependencies not found in any version of mainstream KDE, including patched versions of the libcaldav and libcarddav libraries and the version of Qt3 that Trinity maintains as separate projects.

Thankfully, all Trinity packages have a -trinity suffix attached to them, and the desktop maintain settings in a ~/.trinity directory separate from the ~/.kde directory used by KDE 4, so TDE can coexist safely beside other versions of KDE. The largest problem you are likely to encounter is finding TDE at the login screen, where it is listed under "TDE" rather than "KDE" or "Trinity," as you might first expect.

Running TDE

For long time KDE users, TDE is a step back in time. The first login starts with the KPersonalizer wizard, complete with Konqi, the now seldom-used dragon mascot of KDE. However, this nostalgia is not an unalloyed delight.

The first impression is that TDE is generally faster than KDE 4. This impression waivers when you open KDE 4 apps and seems inconsistent when running applications not designed for a specific desktop, but the general impression remains for routine operations like logging in or out.

[TDE desktop]

If you are familiar with the KDE 3 release series, the next thing you are likely to notice is how little it has visibly changed, even though 3.5.13 is the third TDE release, 3.5.12 having been released in October 2010, and 3.5.11 in April 2010. Perhaps the most visible improvements in the 3.5.13 version, which was released November 1, is a Monitor and Display dialog that supports multiple monitors, the option to run a KDE-4-style menu, and a few themes. You have to go into the repositories to notice the addition of a few TDE-specific applications, such as kbookreader, kdbusnotification, kmymoney, and kstreamripper. Otherwise, most of the enhancements in the new release are behind the scenes, and largely unnoticeable. Ranging from bug-fixes to improvements in security, these enhancements are welcome, but, to the casual eye, TDE seems pretty much identical to the last of the KDE 3 series.

Although interface differences are obvious, in terms of basic features TDE compares favorably with the latest KDE 4 releases. In fact, although rearrangement of configuration options make comparisons difficult, TDE's Control Center actually appears to have more administrative options than the latest KDE 4.7 release, especially for hardware peripherals. For many, an interface designed to the standards of a decade ago might seem at first a small price to pay for the speed and administration tools.

[TDE control center]

However, TDE also has some serious shortcomings. For example, according to the release notes, Bluetooth functionality is absent. So, too, is the ability to edit HTML messages and display images in KMail, which is the subject of a $2500 bounty. TDE is also at an obvious disadvantage in its lack of counterparts to advanced KDE 4 features such as Folder Views and Activities. Nor does it integrate any online applications or services into the desktop, the way that an increasing number of desktop environments do.

In addition, TDE would benefit from the ability to migrate email, addresses, and settings from other versions of KDE. Non-KDE applications such as Firefox can be used interchangeably in TDE and KDE, but not KDE-specific applications. Start KMail in TDE, for example, and you have to configure it separately from other versions of the same application. Admittedly, migration of information might be difficult, since KDE 4 applications such as KMail and Amarok store information in databases, but, without some sort of assistance, TDE installations are practical mainly on a fresh machine or else as experiments not intended for serious work.

Even more seriously, while the last releases of the KDE 3 series had a reputation for stability, TDE's patches seem to have taken a toll. Every now and then on my Debian installation, TDE takes three or four times as long as usual to log out. Random crashes also occur. For some reason, too, changing the theme creates a new panel on the left side of the screen, while logging in always starts the audio mixer.

Questions of viability

Judging by the ongoing complaints about the KDE 4 series, a market should exist for a continuation of KDE 3. Yet, for some reason, TDE remains a niche project. It has only four main developers, although, according to project lead Timothy Pearson, others have reported bugs and submitted patches. The same names appear over and over on TDE's mailing lists, and the project's Community Styles and Themes page includes just a single contribution.

Furthermore, in the last eleven months, the project's download page has averaged just 214 visits per month, with a high of 492 in February 2011. Even with the new release, this month's visits were only 252 with the month two-thirds over — and probably not all of those visits were followed by an installation.

Little wonder, then, that the project's home page includes a plea for help in every aspect of development. The current team has undertaken an ambitious project with limited resources, and is running hard just to stay in the same place.

That might lead to misgivings about TDE's viability, but there are some other things to consider. The project has managed to do three releases, with a fourth planned for April 2012. It has also successfully navigated major design decisions, avoiding switching to the Qt4 framework by taking over the maintenance of Qt3, and continuing to rely on DCOP, invoking D-Bus only when necessary for such operations as running KDE 4 applications.

Moreover, project members are well aware that much remains to be done. Asked about the priorities for the future, Pearson mentions a replacement for HAL, but emphasizes that the main concern will be bug-fixes. "TDE inherited a lot of bugs from KDE 3.5.10, and has added some of its own over the years," he acknowledged. The next release, he added, "is going to primarily be a bug fix release, although I imagine some new features will probably creep in between now and the release date."

Despite the challenges, Pearson remains optimistic that TDE will survive and define itself. Since forking from KDE 3, he said,

The two projects' goals have diverged significantly. We are not trying to compete with KDE 4 (or any other desktop for that matter) — instead, we are working on an alternative desktop environment with a different perspective on human-computer interaction compared to the environments currently available.

In other words, like Xfce, TDE is designed for those who view the desktop primarily as a place from which to launch local applications. To those who use online applications or services, or whose workflow now depends on enhanced features like KDE 4's Activities and alternative desktop arrangements, that may seem like an obsolete goal. Yet the continuing mutter of controversy about KDE 4 suggests that there are at least some who wish to continue working as they already have for a decade.

For these reasons, in its own quixotic way, TDE seems likely to struggle on, at least for the immediate future. For those who were happy with KDE 3, and opposed to the direction of KDE 4, the project seems a perfect opportunity for getting involved and making a difference.

Index entries for this article
GuestArticlesByfield, Bruce


to post comments

KMail2 doesn't store information in databases

Posted Nov 24, 2011 8:04 UTC (Thu) by wstephenson (guest, #14795) [Link] (10 responses)

For the nth time, Bruce, KMail2/Akonadi's use of a database is only a cache.

People generally understand that computers store persistent data in files despite having to put them into volatile memory to work with them, so what's so hard to communicate that we *store* data in the same standard file formats KDE 3 used, and run it through an off the shelf database for quick access and querying, rather than maintaining our own 'database' code inside the KMail source tree?

KMail2 doesn't store information in databases

Posted Nov 24, 2011 8:37 UTC (Thu) by anselm (subscriber, #2796) [Link] (7 responses)

If it is »only a cache« it should be easy to switch off or replace with a »no-actual-caching« implementation that doesn't require a database server. That does not appear to be the case.

KMail2 doesn't store information in databases

Posted Nov 24, 2011 14:47 UTC (Thu) by wstephenson (guest, #14795) [Link] (6 responses)

Possible but undesirable. An email client that has to parse an entire mbox or maildir or go out to the IMAP server every time you enter a folder would only be useful for trivial amounts of mail. Even pine and mutt have email header and addressbook caches, and those are provided by 3rd party database libraries. When you consider KDE's Akonadi is not just tightly coupled to KMail or even email, having a standalone server process to allow PIM data to be accessed from the mailer, the clock calendar popup, the biff replacement, or the IM client, with the minimum amount of unshared state eating up your RAM begins to look like a good idea.

KMail2 doesn't store information in databases

Posted Nov 24, 2011 15:01 UTC (Thu) by anselm (subscriber, #2796) [Link] (5 responses)

Funnily enough, I don't see a big performance difference between the KMail of KDE 3.5 and that of KDE 4.x. (Actually, I'd expect my KDE 4.x KMail to be quite a bit faster than my KDE 3.5 KMail because it is running on a much beefier machine. Something must be eating up the difference, I wonder what that might be …)

KMail2 doesn't store information in databases

Posted Nov 25, 2011 21:49 UTC (Fri) by jospoortvliet (guest, #33164) [Link] (4 responses)

KMail1 had its own internal database, KMail2 re-uses MySQL. I guess MySQL, which is after all a more generic database, is not as fast as the internal database of KMail1 was.

There are probably also still quite some opportunities for performance improvements since much of this is new while KMail1 had been optimized for years.

But essentially, there is no difference in KMail1 and KMail2 except that the backend of KMail1 is abstracted out and uses MySQL (or other backends, they are plugins after all) instead of a home-brewn solution.

Sounds like an improvement to me. I am very much aware that currently, it doesn't feel like that with the stability and esp performance issues and all, but a change for the good often consists of one step backwards, two steps forwards.

KMail2 doesn't store information in databases

Posted Nov 26, 2011 11:44 UTC (Sat) by wazoox (subscriber, #69624) [Link] (3 responses)

Question: using MySQL as a desktop application backend strikes me as unnecessarily heavy; what did bring people NOT to use some variation of Berkeley DB, or one of many DBM implementations (dbm, Tokyo Cabinet, HamsterDB, etc)?

KMail2 doesn't store information in databases

Posted Nov 27, 2011 10:12 UTC (Sun) by wstephenson (guest, #14795) [Link] (2 responses)

Akonadi uses the QtSql api, which supports database plugins. MySQL is the default; sqlite and Postgres are options. We found that the heavily multiprocess and -threaded approach used on desktop builds ran into threading problems with sqlite. For the embedded/mobile builds where some components are run in-process for a smaller footprint, sqlite is used. Postgres support just needs more work and optimisation as has been done for MySQL, to reduce its footprint to the bare minimum needed. I'm not sure why BDB wasn't chosen.

KMail2 doesn't store information in databases

Posted Nov 28, 2011 9:10 UTC (Mon) by anselm (subscriber, #2796) [Link] (1 responses)

Presumably because BDB doesn't support SQL directly. You could try implementing an SQL engine on top of BDB but you would just be reinventing SQLite, which is essentially an SQL engine on top of BDB.

KMail2 doesn't store information in databases

Posted Nov 28, 2011 13:39 UTC (Mon) by nix (subscriber, #2304) [Link]

What? There's no BDB involved in SQLite. It uses fairly conventional database data structures to store data, not a key/value hash.

KMail2 doesn't store information in databases

Posted Nov 24, 2011 15:54 UTC (Thu) by jnareb (subscriber, #46500) [Link] (1 responses)

BTW. what happens with unsaved changes when application crashes in KDE4?

KMail2 doesn't store information in databases

Posted Nov 25, 2011 21:52 UTC (Fri) by jospoortvliet (guest, #33164) [Link]

Same as in KDE3. Actually, probably not. In KDE3 a KMail crash could corrupt your database. In KDE4, well, I think it's harder to corrupt MySQL than the home-brewn database from KMail1 so I'd say it is more resilient to crashes and such.

And I'm assuming here that the *backend* of KMail2 crashes. KMail1 had everything (UI, database, plugins for mail retrieval etc) lumped together in one process, KMail2 has the backend abstracted away in a proper, C++ only, clean system with plugins for retrieval, caching and storage of data.

Trinity Desktop Environment: Keeping KDE 3 alive

Posted Nov 24, 2011 10:24 UTC (Thu) by mst@redhat.com (subscriber, #60682) [Link] (3 responses)

> TDE is also at an obvious disadvantage in its lack of counterparts to advanced KDE 4 features such as Folder Views and Activities. Nor does it integrate any online applications or services into the desktop, the way that an increasing number of desktop environments do.
Looks like a feature.

Trinity Desktop Environment: Keeping KDE 3 alive

Posted Nov 25, 2011 21:54 UTC (Fri) by jospoortvliet (guest, #33164) [Link] (2 responses)

Not being able to do something is a feature? Sure, that's why most people still run DOS 1.0 - fewer features so it HAS to be better. It doesn't even run on modern computers so it's rock stable - nobody will ever experience a crash!

Trinity Desktop Environment: Keeping KDE 3 alive

Posted Nov 27, 2011 21:19 UTC (Sun) by droundy (subscriber, #4559) [Link]

I think the advantage of not having folder views or activities lies in ease of use... while it's possible that activities are useful for something, I haven't discovered what.

Trinity Desktop Environment: Keeping KDE 3 alive

Posted Nov 28, 2011 2:42 UTC (Mon) by JoeF (guest, #4486) [Link]

It depends on what you want to do.
I am running Slackware 12.2 with KDE 3.5.10. My highly customized Slackware system does all I need it to do. There is simply no need for me to throw out my configuration just to use KDE4 (and spend considerable time to create a configuration that serves my needs.) I am likely going to install Trinity, to get the fixes and features they built in without the major surgery for an update to KDE4.

Trinity Desktop Environment: Keeping KDE 3 alive

Posted Nov 25, 2011 22:01 UTC (Fri) by jospoortvliet (guest, #33164) [Link]

I think it's awesome that the Trinity team takes advantage of the Freedom the community offers to keep something alive which many consider dead. Maybe Bruce could've mentioned the possible security risks of running such a huge, old codebase with so few maintainers, but aside from that I think Trinity is fine.

I am unsure about their effort to port Trinity to Qt4 - I fear they end up rewriting so much (eg to model-view etc) that it is not different from what mainstream KDE did in this regard. But maybe they decide to port it to Qt5 and QML some day, that'd be interesting :D

In any case, I'm happy packages are available for a number of distro's (which btw includes openSUSE) so people can try it out. I think many will notice their fond memories of KDE3 might be a bit over-stated when faced with reality, but for some use cases it'll do fine.

I do btw also appreciate efforts like the Kor alternative shell for KDE 4:
http://kde-apps.org/content/show.php/Kor+Testudo+Shell?co...

Meanwhile I'll happily use both Plasma Desktop (and play with GNOME Shell while it matures to being useable) - fits me better.


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds