Category: Geekery

icewm is not my favourite window manager

Update: I’m a fucking idiot. Turns out I was calling JFrame.setDefaultLookAndFeelDecorated(true); when I should have been calling JDialog.setDefaultLookAndFeelDecorated(true);. All fixed now.

There is a complex interaction between X Windows window managers and Java’s look and feel manager. And it is currently driving me crazy.

Our project choose the “Ice”, aka “icewm” as our window manager. We choose it because

  1. It is very lightweight
  2. It was relatively easy to strip out all the stuff we don’t want
  3. It had translation files so it would automatically display in all the languages we support

On the downside, it also looks very “Windows 3.1″ish, and it’s stupid as hell. The thing that’s currently driving me nuts is that when you use JOptionPane.show.*Dialog to display simple dialogs, Ice insists on putting close and iconify icons on the dialog. Two problems with that

  • The icons overlap the title meaning you can’t read the last word in the title.
  • If you’re dumb enough to actually iconify the dialog, it’s damn near impossible to find it again, and since it is modal, you’re basically stuck until you can figure out where it went.

So here I am trying to figure out how to make JOptionPane tell Ice to stop doing this. JOptionPane.setDefaultLookAndFeelDecorated(true) doesn’t seem to do anything. I discovered in my own dialogs that use my own subclass of JDialog, I can achieve something a little less horrible by calling setUndecorated(true); and getRootPane().setWindowDecorationStyle(JRootPane.FRAME); which gets rid of Ice’s title bar and replaces it with a Java-style title bar that only has a close icon on it.

I downloaded the JDK source code to see if there was anyway I could do something similar in JOptionPane. There are a couple of methods in JOptionPane that look promising, but of course Sun made them private so I can’t override them. I could replace JOptionPane entirely, but that’s probably a gross violation of the license that I downloaded the JDK source under.

I’m hoping that next release I can convince the powers that be to switch to XFCE or something else that looks a little more modern and perhaps will listen to the window manager hints from Java.

Sigh.

Whew!

I suddenly discovered I couldn’t reach my colo box. It wasn’t answering on any of the ports it’s supposed to be. But I didn’t get any indication that anything was going wrong before hand, and I couldn’t ping the IP one before mine, so I was was hoping it was a problem at Time Warner’s data center and not with my box. I called my colo provider, but didn’t get an answer. Ah good, I thought, ever the optimist, that means they’re working on the problem.

But the minutes turned into hours, and I still couldn’t get through to my box, nor was anybody answering the phone. But after nearly three hours of downtime, mail started flowing again! I could reach my web sites! And the IP one before mine became pingable. And it appears that they didn’t have to reboot my box to do it. My 65 day uptime survives. Yah!

Love: strace. Hate: RedHat

Well, thanks to my second favourite debugging tool (after System.out.println), strace, I figured out what was going wrong in Rants and Revelations » Today’s Java puzzlement.

(Short aside: CentOS is actually RedHat Enterprise Linux with the proprietary stuff filed off. So any changes between versions are RedHat’s fault, not CentOS’s.)

I had a short program I wrote some time ago to print out the names of all the fonts that Java knew about. Today I straced it on my CentOS 4.4 and my CentOS 5.0 machines to see what was the difference. Both machines opened up /usr/java/jdk1.5.0_11/jre/lib/fontconfig.RedHat.bfc just fine. And both started opening up various TrueType font files. But what’s that? On the CentOS 5.0 machine, I’m getting ENOENT (file not found) for /usr/share/fonts/ko/TrueType/gulim.ttf. Oh, that’s not good, since I know the installer installs the “fonts-korean” rpm, which is the CentOS 5.0 equivalent of “ttfonts-ko”, which is what I’ve got installed on CentOS 4.4. Oh, but when the geniuses at RedHat renamed the rpm, they also renamed the directory the directory that the TrueType font files go, from /usr/share/fonts/ko/TrueType to /usr/share/fonts/korean/TrueType. And when they did similar renaming with Japanese and Chinese fonts, at least they had the decency to put symlinks at the old locations.

After that, it was a simple matter to copy the /usr/java/jdk1.5.0_11/jre/lib/fontconfig.RedHat.properties.src to /usr/java/jdk1.5.0_11/jre/lib/fontconfig.RedHat.properties, fix the directory names, and voila, I have Korean fonts.

Now I just have to figure out how to get this into the delivery RPMs.

Today’s Java puzzlement

Does anybody know why my CentOS 4.4 desktop system shows Korean fonts in both native apps (like gvim) and our Java application, but our CentOS 5.0 Theatre Management Systems (TMS) will only display Korean fonts in native apps. Obviously the fact that the TMS displays Korean fonts in gvim proves that the fonts are installed. And the fact that my CentOS 4.4 desktop shows the Korean fonts in our application proves that Java 1.5_011 can do Korean. Although the rpm names have changed, as far as I can tell the same Korean fonts are installed.

Anybody have any clues?

Dear Boss

Three years ago, when I was asked to implement a DocumentCache class in the cinlib, I made a mistake so that first build that had it was actually horribly slower than before it was implemented. Yes, I admit it. But I fixed that problem in the very next build, and it actually did end up being a net gain.

So is it really fucking necessary that every time since then when there the slightest question about cinlib performance, the first words out of your mouth are “can we try disabliing the DocumentCache to see if that fixes it”? I mean, it’s been three years. Give it up, already.