Section "InputClass"
        Identifier "Logitech MX1100 button remap"
        MatchProduct "Logitech USB Receiver"
        MatchDevicePath "/dev/input/event*"
        Option "ButtonMapping" "1 2 3 4 5 6 7 2 9 10"
EndSection

As with the previous method, xinput list should give you the product string to use for MatchProduct.

As you can see, most of my font settings are at the default “Sans” font.  The “Sans” and “Sans serif” fonts , at least in recent Ubuntu releases, refer to the corresponding DejaVu font variants (previously it was Bitstream Vera).  However as I found out through experimentation, whilst Qt is obeying my font settings, the generic “Sans” font seems to mean something completely different (at least to Qt4).  If I instead specify the DejaVu fonts directly in my font settings, the correct font rendering is used:

So that’s it: if you’re using GNOME and you seem to get a Qt font rendering that doesn’t match your GTK font rendering, try using a more specific font.  (Note: I haven’t got a clue what “Sans” actually means to GNOME, but it doesn’t appear to be a font in it’s own right.)

Take a look at this code—what do you think it should do?

$foo = 'bar';
var_dump(isset($foo['xyz']));
var_dump($foo['xyz']);

Most people would assume that indexing a string on another string is nonsensical, and they would be right—in PHP you can only index a string with an integer. The logical extension would be that isset($foo['xyz']) would be false and/or any attempt to index using a string would raise an error. And that is where they would be wrong. In fact, isset($foo['xyz']) is true, and $foo['xyz'] is “b”.

PHP is dynamically typed, which generally means there is a lot of implicit casting between types going on. In this case, while indexing a string can only be done with an integer, there is an implicit cast from a string to an integer, so this cast is performed and the result used as the index. However, the usual way of converting from a string to an integer is to use digits (0–9) up until the first non-digit character (after taking the minus sign into account if there is one). This means the integer value of ‘xyz’ is 0, since there are no digits to add up.

When explained, this may seem like sensible behaviour, but let’s think about the effect this has when coding and debugging: if you accidentally index a string with another string somewhere, you won’t know about it straight away. Instead, you’ll just be getting “wrong” values and scratching your head over where they could be coming from. I’m of the opinion that if you can only index a string on an integer, then indexing it on a string should be at the very least a warning. Silently doing something completely different isn’t very helpful.

And so that this doesn’t seem like a nonsensical contrived example, here’s a reduced version of the code that raised the issue:

function get_item($array, $path, $default)
{
    $item = $array;
    foreach (explode('.', $path) as $p)
    {
        if (!isset($item[$p]))
        {
            if (func_num_args() < 3)
                throw new ItemNotFound($path);
            else
                return $default;
        }
        else
        {
            $item = $item[$p];
        }
    }
    return $item;
}

What this function does is traverse a multi-dimensional array with a “key path”, i.e. “key1.key2″ gets $array['key1']['key2']. Since isset() is the most common way people check the existence of an array, this is what I used here. However, things break down in this example:

$array = array('foo' => 'bar');
$x = get_item($array, 'foo.xyz');

The expected behaviour is that the exception should be thrown, since $array['foo'] is not an array with a “xyz” key, but the issue described above instead leads this to return “b”.

In this case, there is a way around it: what I really should have been using is the following check:

if (is_array($item) && array_key_exists($p, $item))

This has more interesting consequences—it means that a very very large number of people are using “isset” where they mean “is_array and array_key_exists”. As for me, I just fixed a bug in my code exposed by a unit test, so I’m happy (even if a little bewildered by PHP).

A fairly clean Windows XP machine is fairly certain to not have anything higher than .NET 1.x installed. Anything really compelling in the .NET framework requires 3.5. This means somehow you need to get version 3.5 onto the machine somehow.  This isn’t a problem in Windows Vista and later, which include the framework.  Microsoft’s answer to simple deployment is it’s “ClickOnce” system, where an application automatically installs .NET from the Internet (if necessary) before installing itself.  Sure, it’s a 60MB download, but it only needs to be done once.

The real issue is when you can’t guarantee an Internet connection or a working .NET 3.5 installation.  At this point you must resort to the offline installation, and this is where .NET and Java are very different.  For Java 1.6 SE, the offline installer is 16MB for Windows 32-bit.  For .NET 3.5, the offline installer is a 200MB universal package, with no way to cut out the parts you don’t need.  Java in fact is so small relatively speaking that many applications actually include the JRE in their package (for example OpenOffice – 148MB with JRE vs. 134MB without), whereas .NET can turn a 10MB application into a 210MB monstrosity.

Now in my particular situation, I’m embarassed to have chosen to use C#/.NET/WPF for a simple tool at work.  For programming the tool itself, it was certainly the fastest option – other kinds of Windows programming, e.g. MFC or Forms, just look painful, and I thought the barrier to entry would be lower than Java.  However this 1MB tool requires the 200MB .NET offline installer to be carted around with it because the network it’s used on is completely separate from the Internet.

.NET will only be really appealing once it’s ubiquitous, but then “critical mass” is one of the big problems for lots of software.  For now, I think I’m going to try Java next time…

Since I’m primarily a Linux user, I don’t have Logitech’s own SetPoint software at my disposal, so I’ve always had to find a way to get this functionality in some other way. When I first got the mouse, this method involved deliberately using a “basic” mouse driver (referred to in xorg.conf as “IMPS/2″), which didn’t support many mouse buttons. The effect was that the button mappings wrapped around, leaving button 8, my preferred “middle click”, mapped to button 2 (8 mod 3), the real middle button.

Unfortunately, newer Xorg versions became smarter and better capable of handling more buttons, and this workaround ceased to function. For the next while, I used something even more hackish: xbindkeys combined with xmacroplay to simulate a middle click with the following part of my .xbindkeysrc:

"echo ButtonRelease 8 ButtonPress 2 ButtonRelease 2 | xmacroplay -d 0 :0.0 &"
    b:8

The downside to this solution is that there are some cases where the button events don’t work correctly, one of them being open-in-tab from a bookmark menu in Firefox. It seemed the best solution would be to get Xorg to remap the buttons in such a way that button 8 really was just an extra button 2. The “xinput” utility lets you set button maps in this way—this wiki entry shows how to remap mouse buttons (even if for a different purpose).

This method worked fine, and I put it in my startup programs for GNOME, but it didn’t persist after suspend/resume. It appears that when resuming, USB devices get “reattached”, and therefore don’t keep the settings applied to them the last time they were attached. The workaround for this is to set a policy using a HAL (Hardware Abstraction Layer) .fdi file. These files live in /etc/hal/fdi/policy (at least they do on Ubuntu) and allow you to set various properties on input devices. This page on the Ubuntu wiki gave me the recipe I needed to remap buttons based on the device name. I ended up with the following .fdi file (which I saved at /etc/hal/fdi/policy/logitech-mx1000.fdi):

<?xml version="1.0" encoding="UTF-8"?>
 
<deviceinfo version="0.2">
 
<!-- Remap Logitech MX1000 buttons so that the most accessible side button
     acts as a middle button -->
 
  <device>
    <match key="info.product" string="Logitech USB RECEIVER">
      <merge key="input.x11_options.ButtonMapping" type="string">1 2 3 4 5 6 7 2</merge>
    </match>
  </device>
 
</deviceinfo>

Now, whenever my Logitech mouse is connected, it gets the buttons remapped—this includes when resuming from suspend. Problem solved… until things are changed again of course!

I feel that Facebook started off pretty well.  The initial target audience seemed to be students, and that’s what most of the users were.  It was friendly and uncluttered, compared to other social networking sites like MySpace.  This spread to a wider audience, first sucking in kids and then adults.  This was less than ideal for some, the idea of their parents on a social networking site being horrifying, but still not a disaster.

But in the midst of all this, the apocalypse happened: a powerful API which allowed other people to extend the functionality of Facebook by creating applications that people could add to their account.  Gradually users became innundated with an unstoppable torrent of application requests, caused by application developers making the “tell all your friends” step seem (or be) necessary to using their application.  The average user’s profile became a mess of applications competing for screen space.  The target audience became those who have the time to play endless Flash games, answer endless quizzes, and generally clutter the “requests” page of their friends.

And so Facebook became MySpace 2.0—gaudy and cluttered, with infinite ability to add more clutter.  Maybe the lesson learned is that the moment you allow anything “shiny” in a social networking site, your demographic will degenerate to schoolkids who want to fill their profiles with as much of it as possible.

Personally, I’ve reduced my Facebook interaction for the past 2 years to having the site email me when anybody says something directly to me either via message or on my “wall”.  There is just too much clutter now for me to wade through the endless application requests, friend requests from people I don’t know, and news feed items generated by the latest viral quiz.  And maybe pictures of friends getting drunk have lost their novelty value…

div.dokuwiki form.btn_show .button {
  padding: 1px 0 1px 16px;
  background: transparent url(images/page.png) 0px 1px no-repeat;
  border: none;
}

One thing that became apparent is that IE7 has absolutely no idea how to render this. The correct rendering (as produced by Firefox 3 and all the other browsers) is this:

IE7′s take on rendering this looked more like this:

After a bit more experimentation, I came up with the following illustration which roughly shows what is happening:

The nice thing is that this is fixed in the upcoming IE8, so I’ve taken the stress-free approach; since it’s a relatively “minor” visual bug, there’s no sense it tearing my hair out trying to make it render correctly everywhere. On this occasion I’ve decided that people can either deal with the fact their browser is behind the times, or upgrade, or wait for the upgrade to happen for them.

This led me to wonder how easy it would be to “scrape” the data from one of these sites. Having heard about BeautifulSoup, a Python HTML “tag soup” parser, I opened up an interactive Python session and started to play with the data from this BBC News page. Luckily for me, the BBC page’s HTML isn’t too ugly, so figuring out how to get the data rows wasn’t that hard.

The end result is the following Python script which scrapes the data from the BBC News page and saves it in both CSV and JSON formats.

“Mozilla/1.22 (compatible; MSIE 2.0; Windows 95)”?  Who uses such a browser?  My bet is on it being a zombie machine that somebody has completely forgotten about, which would explain the several other hits I have from versions of IE before 5.0…  These visitors turn up, hit the same page repeatedly, and then leave.  Unfortunately I deleted my spam before seeing this, otherwise I’d be able to verify this theory.  Maybe I’ll look more closely next time.