Trinity Desktop Environment: Keeping KDE 3 alive
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]](https://static.lwn.net/images/2011/tde-desktop-sm.png)
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]](https://static.lwn.net/images/2011/tde-control-center-sm.png)
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,
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 | |
---|---|
GuestArticles | Byfield, Bruce |
Posted Nov 24, 2011 8:04 UTC (Thu)
by wstephenson (guest, #14795)
[Link] (10 responses)
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?
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.
Posted Nov 24, 2011 14:47 UTC (Thu)
by wstephenson (guest, #14795)
[Link] (6 responses)
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
)
Posted Nov 25, 2011 21:49 UTC (Fri)
by jospoortvliet (guest, #33164)
[Link] (4 responses)
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.
Posted Nov 26, 2011 11:44 UTC (Sat)
by wazoox (subscriber, #69624)
[Link] (3 responses)
Posted Nov 27, 2011 10:12 UTC (Sun)
by wstephenson (guest, #14795)
[Link] (2 responses)
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.
Posted Nov 28, 2011 13:39 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Nov 24, 2011 15:54 UTC (Thu)
by jnareb (subscriber, #46500)
[Link] (1 responses)
Posted Nov 25, 2011 21:52 UTC (Fri)
by jospoortvliet (guest, #33164)
[Link]
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.
Posted Nov 24, 2011 10:24 UTC (Thu)
by mst@redhat.com (subscriber, #60682)
[Link] (3 responses)
Posted Nov 25, 2011 21:54 UTC (Fri)
by jospoortvliet (guest, #33164)
[Link] (2 responses)
Posted Nov 27, 2011 21:19 UTC (Sun)
by droundy (subscriber, #4559)
[Link]
Posted Nov 28, 2011 2:42 UTC (Mon)
by JoeF (guest, #4486)
[Link]
Posted Nov 25, 2011 22:01 UTC (Fri)
by jospoortvliet (guest, #33164)
[Link]
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:
Meanwhile I'll happily use both Plasma Desktop (and play with GNOME Shell while it matures to being useable) - fits me better.
KMail2 doesn't store information in databases
KMail2 doesn't store information in databases
KMail2 doesn't store information in databases
KMail2 doesn't store information in databases
KMail2 doesn't store information in databases
KMail2 doesn't store information in databases
KMail2 doesn't store information in databases
KMail2 doesn't store information in databases
KMail2 doesn't store information in databases
KMail2 doesn't store information in databases
KMail2 doesn't store information in databases
Trinity Desktop Environment: Keeping KDE 3 alive
Looks like a feature.
Trinity Desktop Environment: Keeping KDE 3 alive
Trinity Desktop Environment: Keeping KDE 3 alive
Trinity Desktop Environment: Keeping KDE 3 alive
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
http://kde-apps.org/content/show.php/Kor+Testudo+Shell?co...