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.)

Comments on this page:

From at 2013-08-02 06:18:32:

Well, I'm just glad that I don't like most of those applets you talk about (I do most things in console), and those I do care, the informative ones, I have implemented as gDesklets. This way I still use my 10-years-old (holy fsck! how old is that thing?) Enlightenment environment without making drastic changes.

-- dozzie

From at 2013-08-02 10:43:31:

Here is how I do it (admittedly, this setup took a while to grow, but it's zero maintainance now):

power management: statically configured in /etc/rc.local (much more transparent than laptop-mode-tools)

battery monitor: conky (battery display goes red when <8% battery), and a script that makes the power button blink in that case

screen brightness: built-in keys just work (Lenovo X220)

sound volume: built-in keys just work (Lenovo X220), mute-key needs to be ignored, e.g. with xbindkeys

networking: I run dhcpd on eth0 and wlan0 constantly, they pick up on carrier (wpa_supplicant has a static configuration for the networks I use). For manual configuration, I sudo some ip commands. (Your distribution may have something more advanced, Arch would force systemd on me for that.)

touchpad configuration: 5 calls to synclient(1).

additional tweaks: I suspend on lid close (ymmv) with help of acpid. conky also shows CPU usage, memory usage, temperatures, volume, IP addresses and a clock.

dependencies on gnome or other DE: I use gnome-keyring, nothing else.

obligatory screenshot: http://chneukirchen.org/screenshots/2012-09-06-232514_1366x768_scrot.png

Please ask if you are curious about the details.


From at 2013-08-03 04:04:55:

For networking, I highly recommend wicd. It does wired and wireless... Can automatically connect to networks or wait for manual intervention. Has CLI interface, as well as GUI and sets in the system tray of whatever your DE.

Setting that up manually with startup scripts calling wpa_supplicant and dhcpclient was a time-consuming nightmare. wicd takes all the pain out of it, and has few dependencies.

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, View Normal, 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.