Java’s Nimbus look-and-feel and custom keymaps

I recently discovered that the Nimbus look-and-feel in Java ignores background colour that’s been set using setBackground() on a JEditorPane. Apparently this is not a bug; look-and-feels are allowed to ignore the colour that you specify with setBackground() (though this raises the question of why the method even exists). With Nimbus, it turns out, you can control background painting by setting a “client property” on the editor pane (using putClientProperty()) – specifically, you set the “Nimbus.Overrides” property to a UIDefaults object, which is essentially a property-value map. The “EditorPane[Enabled].backgroundPainter” property is supposed to be set to a BackgroundPainter which Nimbus will then use, though if you set it some other object type (such as a String or even a Color) it will ignore the property and instead paint the background using the colour that was set with setBackground() – which of course raises the question of why it couldn’t do this in the first place, but, meh, whatever; at least we have a solution. (Any properties which Nimbus needs that aren’t in your provided UIDefaults will be inherited from Nimbus’ default property set).

There is (of course) Only One Problem.

Setting the “Nimbus.Overrides” client property apparently prevents any custom keymaps that you might have assigned to the JEditorPane from working. This is true even when the UIDefaults table you provide is empty, implying that the mere act of assigning something to the Nimbus.Overrides property is changing behaviour of the look-and-feel, which is surely broken.

I’ve submitted a bug to Oracle (via though the hit rate on getting a response for them hasn’t been 100%, so we’ll see what happens. Once you submit you get the following text:

What’s Next?

We will review your report. Depending upon the completeness of the report and our ability to reproduce the problem, either a new bug will be posted, or we will contact you for further information. You will be notified by email in either case.

… (emphasis mine) – however I’ve submitted reports in the past which got no response. I will update this blog entry if/when I receive an acknowledgement. (A few minutes later – first update! I’ve received an automated email stating that “We are evaluating this report and have stored this with an Review ID: JI-9012303”).

Update 24/05/2104: I still haven’t heard anything, but today I discovered this. So, it looks like this was recognised as a bug, but I, the initial reporter, was never notified at all – this seems like poor form. At least my report wasn’t wasted.

Test case below.

Continue reading


Cinnamon (again) and hacky non-bugfixes

After getting frustrated with Ubuntu’s Unity interface to the point of wanting to bludgeon myself to death with a bag of squirrels, I tried out Cinnamon by manually installing the latest version. It’s actually pretty nice, except for one major annoyance: every time I get a skype message, it un-minimises the relevant chat window and brings it over the top of my current foreground window/process. This is really annoying. There is a bug entry in Cinnamon’s bug database, but it closes with this frankly disturbing comment by someone called Clement Lefebvre (clefebvre):

I don’t like the idea of this being configurable.. mainly because this isn’t a question of preference but a question of fixing a bug. The focus should always be taken when the user launches a new app and never be taken on his behalf when he doesn’t trigger the creation of new content.

For Skype, I fixed the bug with this

Well, right, it’s a bug and should be fixed properly, but, check out the fix:

if (!window || window.has_focus() || window.is_skip_taskbar() || window.get_wm_class() == “Skype”)

What the … it actually checks for Skype and handles it specially. That’s got to be wrong. Clement then goes on to say:

For other apps which face a similar issue, I’d like people to insert the following code at line 27 in /usr/share/cinnamon/js/ui/windowAttentionHandler.js:

global.log_error(“Focus stolen by : ” + window.get_wm_class());

Then restart cinnamon, and when the focus is stolen from you, click on the ^ applet, troubleshoot, looking glass, click on the error tab, and you should see the wm class name of the app which stole your focus. Give me that wm class name, and we’ll add it to Cinnamon.

Oh for fuck’s sake… this is not how you do these things. Fix the bug in Cinnamon, make it respond to notifications properly for all apps; don’t just implement a workaround on an app-by-app basis. Am I missing something here? Surely other window managers aren’t implementing this workaround (because they don’t need to, because they handle the notification correctly in the first place)? This doesn’t exactly inspire confidence in the quality of Cinnamon.

PHP, thou art a wart on the face of the web

I’ve long despised most dynamically typed languages, for reasons which I’ve yet to properly enunciate, but I’ve begun to loathe one above all the others: yes, I’m referring to the abomination that is PHP. I’ve never got around to properly writing about why I abhor it so much but I was recently given a link to an article on another blog, which contains (amongst a much larger and very well argued discussion) this little gem (reproduced with permission):

I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

That’s what’s wrong with PHP.

I’ve not really ever had to write much PHP but I’ve sat looking over the shoulder of someone who was in the process of coding some small PHP scripts, and I was horrified. The problems with the ‘==’ operator, and the overloading of the function return types, were particularly unsettling. I’ve written previously about my difficulty in just compiling PHP so that it worked as I wanted – which just adds to the feeling that PHP was simply slapped together from a load of unrelated pieces, and it was only by chance that a turing-complete language emerged. One of these days I’ll get around to explaining just why dynamic languages are bad, but in the meantime get some entertainment (and perhaps education) by reading Eevee’s post.

2012-05-05 addendum: Add “insecure” to my list of gripes.

Cairo 1.12.0 – buggy as buggery?

Cairo 1.12.0 has been released with a swag-full of new features (such as XCB backend) and improvements. Apparently. For me, it causes random text corruption, noticeable most prominently in Firefox (when built with –enable-system-cairo of course) but also in a few other GTK-based apps. I’ve tried compiling with both GCC 4.7.0, 4.6.3 and LLVM 3.0 without any resolution. Cairo 1.10.2 doesn’t produce corruption, 1.12.0 does. For the moment I recommend holding off on the upgrade.

The situation would be a lot better if Cairo had a halfway decent test suite. It does have a test suite, but when I run it (on 1.12.0 or 1.10.2) I get a huge number of failures which are completely inexplicable to me and apparently to LFS authors also. Quotes from that page:

As the test suite is currently unreliable, it is best to simply skip it at this time.


Note that the tests take a long time to run and many of them fail for unknown reasons.

… which pretty much sums up my experience as well. What a joke.

Update: seems I’m not the only one who’s seen this. Not clear at this stage whether it’s really a bug in cairo, in the radeon driver, or the EXA extension.

Evince installation documentation

I just upgraded Evince on my system. Initial attempts were unsuccessful; I got the following message when trying to start it:

(evince:22841): GLib-GIO-CRITICAL **: Settings schema ‘org.gnome.Evince.Default’ is not installed

I have no idea what this means so in the interim I try upgrading ‘glib’. This mostly goes without hiccups (except that newer versions of glib apparently have a dependency on libffi, for reasons which are tentatively explained in the glib README), however, I get the same error message when I try to start Evince. After some Googling, I discover the necessity of ‘compiling the schemas’:

# glib-compile-schemas /usr/share/glib-2.0/schemas

No mention at all of this in Evince build documentation. It looks like the schema might be compiled automatically if you “make install” Evince without setting DESTDIR, but frankly the necessity of compiling the schema should be documented.

Crappy g++ documentation on template instantiation

The g++ documentation says on template instantiation:

G++ has extended the template instantiation syntax given in the ISO standard to allow forward declaration of explicit instantiations (with extern), instantiation of the compiler support data for a template class (i.e. the vtable) without instantiating any of its members (with inline), and instantiation of only the static data members of a template class, without the support data or member functions (with (static):

extern template int max (int, int);
inline template class Foo<int>;
static template class Foo<int>;

The one I’m interested in is “extern”. The docs as quoted above say that it “allows forward declaration of explicit instantiations”, but that’s useless; explicit template instantiations don’t need forward declarations, you may as well just do the instantiation. Of course, the documentation is actually incorrect by omission: the “extern” keyword in front of an explicit template instantiation (as in the example above) actually causes gcc not to emit the instantiated template (even when it would otherwise do so because of implicit instantiation). This means that we can use this syntax to avoid emitting a template instantiation which we know is already emitted in another module.

Avoiding the emission of a template instantiation in many cases has only limited practical value – it might reduce compilation and linkage time ever so slightly, and likewise reduce the disk space used by object files ever so slightly. It would also allow for removing the emitted instantiation from a shared library or executable if the same instantiation was known to be present in another library that we were linking against.

The point is, there’s a potentially useful feature which isn’t documented, yet the syntax is documented – with an incorrect description of what it does.

MySql 5.1 build documentation – utter crap

I’m currently experiencing the joy of upgrading from MySql 5.0 to 5.1 on our server. After building MySql with the same “configure” options as used previously, then installing it, I run the “mysql_upgrade” command, which gives me some alarming output, basically along the lines of:

Error : Unknown table engine 'InnoDB'
error : Corrupt
Error : Unknown table engine 'InnoDB'
error : Corrupt
Error : Unknown table engine 'InnoDB'
error : Corrupt

Unknown table engine? what the… Corrupt?

So, I go do some googling and reading of manuals (which I suppose I should have done beforehand, sure) and it turns out that in 5.1, the “InnoDB” storage engine (the only one worth actually using, as it actually supports locking and transactions) is now a “plugin” and you need a configuration option to enable it:


Ok, so, problem solved, right? Wrong. I then get the following output in the mysqld log:

111212 14:27:37 [ERROR] Can’t open shared library ‘/u1/overflow/usr/local/mysql-5.1.60/lib/mysql/plugin/’ (errno: 2 mysqld: fatal: relocation error: file /u1/overflow/usr/local/mysql-5.1.60/lib/mysql/plugin/ symbol )
111212 14:27:37 [ERROR] Couldn’t load plugin named ‘innodb’ with soname ‘’.

Hmm, not what I call an extremely useful error message. There seems to be some symbol resolution problem, but I don’t even know what particular symbol it’s having trouble with. Rather than mess around and trying to debug this, I go back to the build options. When I run “configure –help” I see, amongst other things:

  --with-plugin-PLUGIN    Forces the named plugin to be linked into mysqld

Err, what the… so, if say “–with-plugin-innodb” or something similar, it will link the plugin statically into mysqld? Weird. But hey, it’s a worth a shot. I try adding that to my “configure” options, and it immediately spews out a message saying that it doesn’t recognize the “–with-plugin-innodb” option! What the hell? I try a few variations but no joy. Getting quite frustrated by now. Ok, the “configure –help” output doesn’t match what “configure” actually accepts, maybe the manual will be more update? Hmm, not really; it’s a bit of a confusing mess actually, and it claims that “–with-plugin-PLUGIN” should work. It does suggest however that no plugins are built by default, and therefore I decide to try the alternative “–with-plugins=innodb_plugin,innobase”. I’m not really sure if I need “innobase” but it seems like it can’t hurt. Waiting for compilation to finish now…


So, compiling without InnoDB support still produced a file called “”, which I can’t actually use? What the?