I'm giving up on a custom laptop environment for Fedora 19

August 2, 2013

Despite what I wrote before and even yesterday, I've now completely given up on my cheerful plans for a fully custom laptop environment. The short version of why is in my tweet:

I surrender to the forces of the modern monolithic Linux desktop w/o applet programs. I'm now using a hacked Cinnamon + dmenu on my laptop.

(I'm not really happy about giving up this way but I'm pretty sure it's the least bad alternative.)

A usable laptop environment needs any number of applets (in the broad sense). Beyond networking, there's power management and battery monitoring, screen brightness, sound volume if you care about sound at all, and several others I'm not thinking of. For at least power management the information display is just the tip of the functionality iceberg.

In the Gnome 2 days all of these applets were provided by actual programs and they embedded themselves into the 'system tray' using a common protocol. Every desktop environment generally rolled its own set of them but that was just because of look and feel and library issues, not because they were incompatible with each other. And it was easy to run the applets yourself with a suitable system tray (which you want for other reasons too). That's all changed now. Modern Linux desktops have become monolithic, where the desktop 'shell' has swallowed all or almost all of those applets; this is the case for both Gnome 3 and Cinnamon and perhaps for KDE as well (I haven't looked closely at it). Sometimes the desktop shell handles everything internally and sometimes part of the job has been handed off to other programs.

In other words, running a custom desktop on a laptop is no longer just a matter of finding all of the applet binaries and running them yourself. Now you need additional information displays at least and possibly programs that actively manage things. Just how many bits and pieces I was going to have to assemble only became obvious to me when I brought my fvwm-based environment up on my actual laptop and started trying to add power status handling, a screen brightness control, and so on and so forth.

(It didn't help that various other bits broke on the actual laptop, like the trackpad's configuration. Attempts to fix this were creating a increasingly frankestein'd setup, with bits bashed in from all over and interacting badly.)

People run non-mainline desktop environments on laptops so all of this is a solved problem. But it's not a cleanly and quickly solved problem, neatly bundled up in the form of one or more obvious programs; instead it was clear to me that it was going to be a do-it-yourself project. Such a project would be justifiable on a machine that I use a lot, where a custom environment would be a lot better (once I had a good one), but my laptop is not such a machine. It sees only occasional use (although enough to make it a machine I want to be productive on). Spending days and a lot of frustration on this is not a sensible use of my time, however much part of me wishes otherwise.

Cinnamon is not my ideal environment but it is much better than Gnome 3 (for a start, it believes in multiple copies of an application at once), and using a mainline environment like Cinnamon means that someone else has worried about all of these integration issues. It also turns out that I can customize it into an acceptably decent simulation of the important productive bits of my old Gnome 14 environment.

(I'm not sure why I settled on Cinnamon instead of, say, XFCE. I think it just looked better when I took a superficial look at all of them. It's been my default tolerable Fedora environment on my test Fedora VMs for a while, although that has its drawbacks.)

Written on 02 August 2013.
« The problem with a custom laptop environment: designing it
The pragmatic issues around HTTP error codes mattering (or not) »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Aug 2 01:39:25 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.