Customizing Everything I Touch: The Lucid Login Screen

This post is purposefully dense, due to my lack of time/typing budget.  If you need clarification, please leave a comment.

Directions (shortcut):
  you$ sudo -u gdm dbus-launch gnome-appearance-properties -p background

Directions (original):
  you$ sudo -u gdm dbus-launch bash

  gdm$ cp wallpaper.png /var/lib/gdm

  gdm$ gconf-editor

  (set /desktop/gnome/background/picture_filename to /var/lib/gdm/wallpaper.png)

  gdm$ exit

The changes will take effect once all users log out (or possibly, the user on :0.)

Commentary:
The directions above copy the wallpaper to /var/lib/gdm (which is the home directory of the gdm user) to protect it against corruption.  If you don't care, you can run the single command `sudo -u gdm dbus-launch gconf-editor` and set picture_filename to any file on the system.

In either case, dbus-launch is necessary so that there's a session bus running as the gdm user, which gconf needs to successfully run.  Otherwise, AFAICT, it tries to connect to your own session bus, which the gdm user isn't allowed to do.

This edits the keys in /var/lib/gdm/.gconf, a config source set by /var/lib/gdm/gconf.path, which is wedged into the regular paths by inclusion from /etc/gconf/2/path.

Validity:
Tested on Ubuntu 10.04 LTS, Lucid Lynx; most likely, this applies to 9.10/Karmic and later Gnome 2.x-based Ubuntu releases.  (IIRC, Karmic is when the new, non-themable GDM landed in Ubuntu.)  The general philosophy probably applies to other contemporary Gnome environments, but the details may differ as there's a lot of Debian-ness in the GConf paths.

Autostart in Gnome 2: the missing docs [Updated 10/10]

I've been trying to understand the autostart mechanism in Gnome 2 for a small program I'm working on.  This may continue to be a supported system in gnome-3, since it seems to be standardized by freedesktop.org and not the Gnome "Let's just rewrite around our bugs and drop features" team.

Without further ado or bitterness, here's a brief but technical dive into the modern autostart system on Gnome 2, as observed on a Lucid Lynx system (originally installed as Intrepid Ibex, I believe.)  [Updated: autostart itself is also a freedesktop standard.]

Groupthink

I don't fit in; I never have.  Some of it is by my choice, but in the tech communities that I've found, I still don't fit in, and I've often wondered why.  It seems the short answer is right there in my blog description: "Frequently contrarian and occasionally cynical."

Dealing with Ambiguity

Apple and their fans tend to view their products as the top of the market, with price and attitude to match (and this is helped by their competitors trying to undercut them with unrefined but cheap ripoffs).  Yet they clearly market heavily, which suggests according to the Advertising Curve that there's room above Apple for a better product, for even more money.

Which naturally leads to the question: considering an Apple product like the iPod Touch, what would be better, and in particular, enough better that you could actually sell them?

Bias

The topic of alternative keyboard layouts inevitably comes up from time to time on programmers' forums: is Dvorak really better than Qwerty?  Is it objectively proven?  If nobody has proven it, why would anyone switch?  Also if it's unproven, why aren't there any satisfactory studies?

It is this latter point that fascinates me.  We have studies by August Dvorak, inventor of the Dvorak keyboard layout, which purportedly show that it's faster than Qwerty.  We also have studies by Strong, commissioned by the GSA in 1956, which claim to show the opposite; supporters of the Dvorak keyboard claim that Strong was biased in favor of Qwerty, and most accept that Dvorak may have been biased in favor of his own creation.

How does one design and execute an unbiased study in a world where only the biased even care about the outcome?  If such a study were performed, would the 'losing' side accept the results?  Or would the study get ignored (or contested) for all time?  If an alternative keyboard were, in fact, proven to be better than the existing choice, how many people would actually switch?

Pagelib Retrospective

I have always been in love with magic: one of the first languages I taught myself once I was old enough to understand what I was doing was Perl, and it fit me like a skin-tight sci-fi spacesuit that we thought we were all going to wear in the future, back in the 1980's.  Steve Yegge's rant about Perl was entertaining, but I can't say as I identified with it much, since references weren't hard for me, nor do I have his problem of forgetting everything when I don't use the language for a while.  Maybe I don't drink enough.

Still, being in love with magic and DWIM doesn't mean that there aren't any hazards.  It's rather like fairy-tale magic, which can result in nasty, surprising, unexpected consequences if used without the utmost care.  This is a story about me exercising a complete and utter lack of care, utmost or otherwise.

Quickie: The Cross Platform Quandry

When an app runs on multiple platforms, it seems like there are two basic designs that they can choose to follow.  Either they try to integrate with each platform, or they try to appear the same on each platform.

It's not clear to me that either of these ways are correct.  Obviously, in the case where the differences between the platforms are hidden to the greatest degree possible, the app doesn't match the look and feel of platform-native applications.  This is the situation with old Mozilla builds that drew virtually all the UI themselves: the chosen GTK+ theme had no effect on Linux.  An app that looks "the same everywhere" can look like it belongs with at most one platform.

Meanwhile, since Mac users in particular are vocal about their dislike for using non-Mac-like apps, most modern cross-platform apps have switched to trying to integrate with each platform.  Firefox has a different theme and adjusts its button order on the various platforms; likewise, GIMP for Windows switches its button order to match the Windows custom of putting Cancel in the corner instead of OK.

As a habitual user of Firefox, Gimp, and Pidgin on both Linux and Windows, this second approach turns out to be less-than-ideal for people who frequently switch platforms.  In this case, the "same" app behaves differently on the different platforms, and I have to remember which platform I'm on so that I can hit the correct buttons.  Of course, this doesn't always happen, so frequently in Windows Gimp, I spend a couple of minutes selecting the perfect color, only to hit Cancel by mistake.  Another frequent source of mistakes is the way that Pidgin's tray icon toggles the buddy list with a double-click on Windows, but a single-click on Linux.  I'm frequently opening-then-closing Linux Pidgin with a double-click.

One last problem with writing a cross-platform app for Linux/BSD specifically is that these are not all-in-one platforms.  An app like Firefox that's written in GTK and follows the Gnome HIG is still going to fail to integrate with the KDE desktop on the points where their respective conventions differ.

Given these difficulties, it's not surprising that most apps aren't cross-platform.  The ones which are face the choice of whether they should integrate with platforms and appear different in the details to people who work on multiple platforms, or whether they should look the same everywhere and look alien or second-class on each platform.

Perfectly Flexible

Sometimes, a stakeholder doesn't like the idea of requiring a Programmer to make lengthy changes to a project's code if the requirements were to change at some future date. The proposed solution is always simple: The System just needs to be more flexible.

Having been the unsuspecting Programmer on a couple of these projects, I can report that the simple solution does not work.

On XML and data formats

In many discussions of XML, there seems to be a faction of programmers who are completely dead-set against XML.  They'll insist on JSON, or YAML, or any other cool technology that isn't supported in that 5-year-old version of whatever language your company is still running.  The usual complaints leveled against XML-based formats are verbosity and the complexity of the DOM.  (Sometimes, leading or trailing whitespace on element contents in pretty-printed XML will bite a project, but this never seems to come up in internet flamewars.)

The really young, or maybe just incurably naive, programmers will even chime in that anything that can be done in XML can be done, or even done better, in JSON.  I even thought this once, until I tried to write a generic XML-to-JSON converter, which showed me how wrong I was.

Functional vs. Object Oriented

By the time I reached my first programming job, I had learned a number of languages well enough to program in, and thought of myself as a pretty good programmer.  Then I met Brian, who frequently talked about Lisp, but had trouble articulating the advantages himself.  (This turns out to be a common problem.)  He introduced me to the SICP videos, and I found Slava Akhmechet's "The Nature of Lisp" essay on defmacro.org at about the same time.  Certain things about Perl and Javascript suddenly made sense, filling me with newfound wonder.

What I thought I knew about OOP as taught in college—Encapsulation, Polymorphism, and Inheritance—seemed like a sham.