Is there a decent (non-polling) way to get notified when a laptop panel’s backlight brightness changes? HAL exports methods to set and get the brightness level, as well as query the number of possible levels, but there doesn’t appear to be a way to get notified if the level changes. Calling org.freedesktop.Hal.LaptopPanel.GetBrightness() every five or ten seconds or so sounds like an awful idea, of course.

I’ve heard plans to use the XBACKLIGHT randr 1.2 property to do backlight setting, but I don’t think any drivers use this yet. Polling /sys is just as bad (why doesn’t sysfs or procfs support inotify, dammit!), and obviously isn’t portable anyway (not that HAL is particularly portable these days either).

This is a little dumb, but kinda fun. A week or 2 ago I set up a CIA bot in #xfce-commits on Freenode. If you have nothing better to do with your life than watch Xfce commit messages scroll by, feel free to join and idle with the rest of us losers.

Hey all… we just released the 1st beta leading up to 4.6. Go check it out. Full list of changes here.

I suppose others have written in broad terms about Xfconf, Xfce 4.6’s new configuration storage/retrieval system, but I guess an in-depth explanation is overdue and is probably up to me.

First, some background.

Xfce has used a configuration system called MCS (Multi-Channel Settings) for some time now, since 4.0 was released near the end of 2003. It’s inflexible and very monolithic. Only a single application (xfce-mcs-manager) is allowed to actually modify settings; all other applications can only query values. That means that the GUI settings dialogs have to run in the xfce-mcs-manager process. The GUI dialogs are implemented in shared libraries that are linked into the xfce-mcs-manager process at runtime. To add more confusion as to its purpose, xfce-mcs-manager also acts as an XSETTINGS manager, automatically proxying the settings stored in a “special” channel.

I had a few loosely-defined goals when designing Xfconf.

• Keep the familiar “channels” concept from MCS, but make the namespaces for settings storage inside channels hierarchical.

• The configuration storage daemon should be able to run without a GUI environment, and the client library shouldn’t have GUI dependencies.

• Get the XSETTINGS manager out of the configuration daemon.

• Integrate “kiosk mode” functionality directly into the configuration storage mechanism.

• Native support for arrays/structs in the configuration store.

• Provide a client library that’s easy to use and exposes commonly-used functionality.

• No client application is special: any app can read or write any setting.

There were probably others, but those seem to be the ones that stick out in my mind after the fact.

MCS used a protocol involving a special X window, X selections, and X window properties to pass settings around at runtime. Obviously this kind of thing isn’t suitable for a configuration system that can run without a GUI, or even on a non-X11 system. So, that was right out. Given momentum over the past couple years, D-Bus seemed to make the most sense as an IPC method. So, the D-Bus API for Xfconf was born. (Please note that I don’t consider this frozen until we release 4.6.0 final. I’ll do my best not to remove or change existing interfaces, though.)

The rest of the story might sound rather gconf-like, and I guess it probably is. There’s a settings daemon (xfconfd) and a client library (libxfconf). Apps use the client library to fetch settings from and store settings to xfconfd. The daemon stores the settings on disk in a format of its choosing and manages the D-Bus interface. D-Bus gives us a few nice things for free; for example, xfconfd starts via D-Bus activation, so there’s no need to include it in any startup scripts or have client applications specifically start it. D-Bus also ensures that two instances of xfconfd aren’t running, fighting over the config store (well, unless you start a separate session bus daemon).

As for settings themselves, you have a channel that holds an arbitrary number of hierarchical properties. Channel names are simple ASCII text strings, like “xfwm4” or “xfce4-desktop”. Property names look a bit like path names and are, as I said, hierarchical. You can use this to logically organise properties inside your application. Xfdesktop is a good example of this, prefixing menu-related preferences with “/desktop-menu/” and backdrop-related prefs with “/backdrop/”. Xfwm4 is a terrible example of this, with all preferences prefixed with “/general/” for no apparent reason.

Anyhow, we support a variety of different data types: basically all of those supported and marshalable by dbus-glib, plus special 16-bit signed and unsigned types (though those two are pretty hacky at the moment and I’d like to be able to do those in a better way). The client library, libxfconf, lets you set commonly-used data types directly, and also has a generic interface for setting the others.

One thing I really like about libxfconf is its incredibly flexible support for array properties. Any property can be set to an array of values rather than a single value. The values in the array need not even be of the same type. Libxfconf has native support for setting array types, and also can directly map C structs to and from array types, automatically.

A final bit of usefulness is in libxfconf’s bindings mechanism. Libxfconf can “bind” an Xfconf property to a GObject property in your application. If the GObject property changes, then libxfconf will automatically update the value in the Xfconf store. If the value in the Xfconf store changes, libxfconf will automatically update the GObject property. This can greatly simplify the Xfconf code in your application. In your settings dialog, you simply have a single line of code to – for example – connect a GtkCheckButton’s “toggled” property to a boolean Xfconf property. If the user toggles the checkbox, Xfconf gets updated automatically. If the setting gets changed outside the application somehow while the settings dialog is open, the dialog gets updated automatically too. You can also use this functionality on the other “end” of the equation, too: if you use GObjects in your application, and your settings map to GObject properties on those objects, you can bind the properties there, too, and not have to manually take action when the user sets a setting in the settings dialog. Unfortunately, libxfconf only supports setting scalar properties now (not arrays), except for the special case of the GdkColor struct. Hopefully this will change in a future release.

We also include an “xfconf-query” application in the xfconf package, written mostly by Stephan Arts, which is a simple command-line Xfconf client. As you might guess, you can use it to query the values of Xfconf properties from the command-line, or from scripts. However, despite the “query” part of its name, it can modify Xfconf properties as well.

In Xfce 4.4 and below, we had the “XfceKiosk” system, which would allow you to lock down a desktop install so certain settings can and can’t be changed by particular users. It worked decently well, but was sometimes confusing to configure, and the application had to do special things to support it. Xfconf integrates a “locking” system whereby the system administrator can install a normally-formatted Xfconf configuration file with directives that instruct xfconfd to consider some properties unmodifiable by the user (and allows the sysadmin to set defaults too). This takes the burden away from applications to support a particular locking framework, as it’s natively built into the configuration system. (Unfortunately, as of this writing, the locking system isn’t working properly. It’ll definitely be finished by 4.6.0 final.)

So, I guess that’s it. If you’d like to get started with Xfconf, a good place to look would be the API documentation (please note that the API will not be frozen until 4.6.0 final). Otherwise, feel free to ask questions on the xfce4-dev mailing list.

After a good two and a half years of being lazy, I’ve finally found some time to work on the Mailwatch plugin, and I have a new release ready too!

There’s lots of chewy goodness in this release. Here are some useful links:

• Mailwatch website

• Source tar.bz2

• Release notes

• Full ChangeLog

As always, please report bugs over at the Xfce bug tracker.

Enjoy!

I meant to write about this a while ago, but I forgot, and it just popped into my head for some reason.

If you’re ever using POSIX signals as a means of primitive IPC, and SIGUSR1 and SIGUSR2 aren’t enough for you, never, ever, EVER make use of SIGRTMIN and/or SIGRTMIN plus some offset. Always use SIGRTMAX and SIGRTMAX minus some offset.

Why?

(Disclaimer: this might only be a problem on Linux, but if you want your app to be portable, blah blah blah…) Depending on what C library you’re using, and what pthreads implementation you’re using, the actual numerical value of SIGRTMIN may not be the same in different applications, depending on – get this – whether or not the app links with libpthread. In my case, the pthread impl makes use of the first 3 SIGRT slots, and so when you use the SIGRTMIN macro, you actually call __libc_current_sigrtmin(), and you get a number that’s 3 higher than what you get when you use SIGRTMIN in an app that doesn’t link against libpthread.

Fortunately, SIGRTMAX (which actually expands to a call to __libc_current_sigrtmax()) seems to be a bit more stable. That is, even if SIGRTMIN gets shifted up 3 slots, SIGRTMAX is still the same.

So, the moral of the story is: I never want to see the SIGRTMIN macro ever appear in your code, unless you really know what you’re doing. Instead, use things like SIGRTMAX, SIGRTMAX-4, etc. It may just save you 4 hours of debugging.

With our SVN repository, we version SVN snapshots using the SVN revision number – we tack “svn-r$REVISION” on the end of the normal version number. This works well, and it’s easy to tell if a given snapshot is newer or older than another one.

Git doesn’t have revision numbers. Commits are identified by SHA1 checksums. Since these are “random,” there’s no way to tell chronological order. How are other people doing git snapshot versioning? The best I’ve come up with is to parse git-log output to get the date and time of the last commit, and then do something like X.Y.Zgit-YYYYMMDD.HHMMSS… which is rather long and ugly. I guess it would be ok to use a 2-digit year here, though. And maybe drop the seconds bit, but I think it’s decently possible to have more than one commit in the same minute. But still… long and ugly.

Any other ideas? My requirements are simple: easy to tell based on just the version string if a snapshot is older or newer than another, must be able to automatically generate this tag, and must be able to identify the exact HEAD that the snapshot was made from.

Lately I’ve noticed a flood of Firefox 3-related posts regarding the new SSL error handling on Planet GNOME. It’s a little funny, as I was writing about this myself a little under two months ago.

Chris Blizzard posts in favor of the new arrangement, and points to an interesting post by Johnathan Nightingale explaining Mozilla’s position. Yes, agreed, Jonathan’s post is a good read, but the salient point is that the new UI is just awful from an average non-technical user’s perspective.

The extra clicks and somewhat abnormal flow (e.g. the need to click a button in the dialog to fetch the certificate) make it harder for the user to understand how to successfully add the exception. You might say that some false positives (i.e., users who fail to access a site that they really actually do want to access) is better than a user succumbing to a MITM attack, but I’m not sure I’d agree.

Equally importantly, the error messages make no distinction between the potential severity of the various SSL errors. For example, I’d say a self-signed cert on a site that you’ve never visited before is fairly low-risk. But a self-signed cert on a site that used to have a trusted cert would be a huge red flag. Domain mismatches and expired certs would fall somewhere in between. It’s hard for the average user to make an informed decision on risk/severity if they were to encounter both of these situations because the error messages and dialogs look exactly the same.

Addressing Johnathan’s main point about self-signed certs and level of security: as a highly technical/advanced user, I personally can say that, in the vast majority of instances where I encounter a self-signed cert, I really do just care about the encryption, and I don’t particularly care about the identity verification of the site that a trusted cert could offer. Now, Firefox probably shouldn’t use me as an example as a target user that needs protection, but that’s a data point nonetheless. I don’t care for things like: Bugzilla installations, my blog, accounts at sites like identi.ca, Twitter, Slashdot (they don’t offer SSL at present, but if they did…), etc.

Pretty much the only time I do care are for financial institutions. And guess what? They’ve already decided that SSL as used for identity verification is useless! Most of them (I can only think of one that I use that hasn’t) have already implemented a “security image” system wherein I pick a random image that gets shown to me every time I log in. If a site claiming to be the site I want shows me an image I don’t recognise, I’ll know that the site is a fraud. Is it perfect? Probably not. But it’s orders of magnitude better then what SSL error dialogs offer.

And I guess that’s really it: as much as I hate the phrase, I really think that the SSL error dialogs are “a solution in search of a problem.” In the cases where I care about site spoofing, the sites themselves have already implemented a better solution. In the cases where I don’t care, well… I don’t care.