Exploring Desktop Environments — 2

Reasonable choices to break away from GTK seem limited to the following options:

  • Trinity Desktop Environment
  • KDE Plasma
  • LXQt
  • A window manager such as IceWM
  • Some hodge-podge combination of software

For many years KDE 3.x and then the Trinity Desktop Environment (TDE) were the default desktop environment (DE) in the house network. That ended with moving away from using multiple distros and migrating Slackware from 32-bit to 64-bit.

During that period there were some VNC (krdc) issues with TDE, a useful tool in the house network. There were XDG compliance issues that caused problems when using TDE software in other DEs. During that period TDE development and bug reports seemed to idle. Compiling TDE packages was becoming a struggle because there was no substantial Slackware community support. Rooted in KDE 3.5, TDE inherited the same design overhead of the modern KDE Plasma — too many foundation requirements to build individual software tools. Another cause for not using TDE was accepting a role as a Linux admin where the MATE desktop was used. Eating the proverbial dog food to remain knowledgeable seemed pragmatic.

One way or another TDE got lost in the shuffle. Possibly at that time the project seemed to have little future. These days the admin role is history and there is no need to eat dog food.

Of course, TDE is alive and well. While there was a lull in the release schedule as previously described, the TDE folks have averaged about one release per year. Commendable.

There is much offered by KDE with respect to being productive and providing a consistent environment. Plasma has come a long way since the early confusing days of KDE 4. Many people report a memory footprint favorable with other DEs. Yet like the original KDE and TDE, Plasma is a quagmire of dependencies and frameworks. Unlike other desktop environments, significant disk space is required to support a full Plasma environment. Flat interfaces now are common but frustrating. Discouraging is the long running dispute about root access to KDE tools. Then there is Akonadi. Some roaming users affected by many online services likely want to continually synchronize data, but many people are not part of that group. Browsing the web indicates otherwise satisfied KDE users reluctantly admitting Akonadi still has problems after a decade of development. There seems to be many related frustrating stories.

Perhaps some kind of minimal or base KDE install will lead to possibilities.

This past summer LXQt 1.1 received some light poking in the house network. LXQt is intended to be lightweight and not as full featured as the original KDE or the current Plasma. The project looks promising but has not been fully tested here. Even if LXQt is palatable as a desktop environment, many additional software packages are needed to be productive.

Slackware is released with several window managers, but window manager environments have not seen life in the house network in many years. IceWM can be considered a rudimentary desktop environment because the software package includes a panel, task bar, system tray, and a few additional tools. Like LXQt, if IceWM becomes palatable as a foundation for a desktop environment, many software packages are needed to be productive.

Possibly the final result will a hodge-podge combination of all of the above.

Posted: Category: Usability Tagged: General, GTK

Next: Exploring Desktop Environments — 3

Previous: Exploring Desktop Environments — 1