Colorful GNOME-colors

One of my favorite icon sets is the GNOME-colors series. The shapes, contrast, perspectives, and luster (not too shiny) are all just right. One thing that wish it had a bit more of though was color diversity. When you use gnome-brave, for example, things become just a bit too blue for my taste. And I don't mean from just an aesthetic perspective--it impacts usability for me as well.

So, I wrote a little (translation: longish) script that will make a new hybrid icon set from all the icon sets in the whole GNOME-colors pantheon. The script was written for Ubuntu/Debian and is I hope self explanatory. The basic idea is that it makes a copy of one of the sets (I chose gnome-brave because it's closest to what I want) and then selectively copies over the bits from the other sets. Hacking the script for other distributions and/or local installations should be pretty straight forward. The script includes a full list of the icons that are part of the Ubuntu package; ones that do not deviate from the default are commented out.

After running the script, you will have to move the directory it generates to ~/.icons or to /usr/local/share/icons.

Odd and pesky details:

• Requires at least bash 4.  
• Assumes you have the gnome-colors package installed.
• Don't try running this from within Geany. For some reason, Geany chokes on declare -A statements. It works just fine if you run it inside a terminal.

You can download the script from http://download.tuxfamily.org/skinny/misc/make-gnome-colors-hybrid.sh. I would show it here except that I'm tired of fighting Blogger's inability to properly implement pre and code tags or provide some other means of sharing code without messing it up.

Installing the Qt SDK

Update: Bits of this have been obsoleted with the 4.7.3 release. I'll try to post an update soon. [09 May 2011]

Because I live fast and loose and on the bleeding edge, I decided to install the Qt SDK using the Nokia download rather than from my distros' package manager. Actually, the real reason is that I was seeing a weird message in the debugger in Qt Creator on Ubuntu 10.10 and hoped the a newer SDK would fix that. But alas it did not--on neither my Ubuntu nor my Debian Squeeze development system. But I will continue to use the downloaded SDK because it will let me update to the latest versions.*

What follows is a brief guide to help you integrate the downloaded SDK into your system should you opt to do so.

The most important difference between installing the downloaded SDK versus installing from the repositories is that the downloaded install will only install for a single user.** The installation itself is pretty straightforward:

1. Download the installer.
2. Make the installer executable: In a term open to the directory where you downloaded the installer, enter the command
   $ chmod u+x {the-name-of-the-installer}
   In my case {the-name-of-the-installer} was qt-sdk-linux-x86-opensource-2010.05.1.bin
3. In the same term, issue
   $ ./{the-name-of-the-installer}
   and follow the resulting directions. The installer will let you pick the directory where the SDK will go. Don't feel obliged to use the default. Because I didn't want another visible directory in my home directory, I installed into ~/.opt/qtsdk.

The above will install all the SDK bits in the specified directory and create two *.desktop entries for the Qt Creator IDE: one on your desktop (drag it to the trash) and the other in your ~/.local/share/applications directory--so that you get a menu entry for it.

Adding some missing bits
The above process gives you a working SDK that's well suited to using the Qt Creator IDE. However, for more general work there are a few things missing:

1. qmake and other executables will not be available as system commands
2. There is no menu entry for the Qt Designer GUI layout tool.

The first is required if you plan to do Qt development with another IDE (Netbeans, Eclipse, Monkey Studio, etc.). The second is nice to have in any case. Both are fairly easy to fix.

Making the SDK commands available
To do this we are going to edit your .profile file. Before making changes to your .profile, make a backup of it so you can get back to it easily if you break something! If you have also installed the SDK from the repositories, what follows will cause the repository commands to be overridden by the commands in the local SDK. If you don't want this, then don't do this.

Open ~/.profile in a text editor. Toward the bottom, add the following:

# set PATH so it includes local Qt SDK tools
QTSDK_LOCATION=$HOME/.opt/qtsdk
if [ -d "$QTSDK_LOCATION/qt/bin" ] ; then
    PATH="$QTSDK_LOCATION/qt/bin:$PATH"
fi
if [ -d "$QTSDK_LOCATION/bin" ] ; then
    PATH="$QTSDK_LOCATION/bin:$PATH"
fi

making sure to change QTSDK_LOCATION as needed for your installation. When you logout and log back in, the executables in the two bin directories should be available as commands. Test this by issuing
$ qmake -v
in a term. The output should make sense.

Adding an entry for Qt Designer to the menu
Assuming you have done the stuff in Making the SDK commands available, you can just add the following file as Nokia-QtDesigner.desktop to ~/.local/share/applications

[Desktop Entry]
Value=1.0
Type=Application
Encoding=UTF-8
Exec=designer %F
Name=Qt Designer
GenericName=GUI designer for Qt applications
X-KDE-StartupNotify=true
StartupNotify=true
Icon=Nokia-QtCreator
Terminal=false
Type=Application
Categories=Development

If you have not done the Making the SDK commands available stuff, then change the Exec= line to point directly at the designer executable (which should be in {qtsdk}/qt/bin)

Now I'm going to move on to testing alternatives to Qt Creator. Qt Creator has a very nice feature set, but the UI is a bit quirky. I'll let you know if I find anything I like better.

* A possible consequence of this is that installing extra bits and baubles will no longer be easy. For example, it seems the Qt4 Designer plugin for QScintilla 2 (libqscintilla2-designer in Debian-land) doesn't ship with Nokia's SDK, and I don't know if Qt Designer will pick up libs installed in standard system library locations.
** I'm quite certain that you can install the downloaded SDK for all users, for example by installing as root into /opt. However, doing so may generate *.desktop files on root's desktop and in root's .local/share/applications dir, and I am not sure if that will mess anything up. If you try this, please let me know how it worked for you.

Debian Firefox 4 Font Failure

[Update 2011-06-25: You should consider this post obsolete. See this post for more info. Iceweasel 5 installs most beautifully on Wheezy.] 
 
I just tried building Firefox 4 on Debian Wheezy. I build Firefox for my machines because (1) I want the latest FF and (2) I want subpixel rendering--which tends to get turned off sometimes|always in Debian and Ubuntu builds of Firefox and Iceweasel.

My first attempt failed. Why? Because if you enable-system-cairo in the build, FF4 insists that you have at least version 1.10 of libcairo2--and Wheezy and Squeeze are both at 1.8.10. One upshot of this is that there will be no way for Squeeze users to get subpixel rendering in FF4 using the default libcairo2 packages. Wheezy users will have to wait until the current Sid packages trickle down. Once that happens, it theoretically will be possible to backport the Wheezy libcairo2 to Squeeze (with patches even) , but I am frankly getting a little tired of this.

I am now making a second attempt to build FF4 wherein I did not enable-system-cairo, and it seems to building just fine. That should be ready for testing in another hour or so. But of course I expect font rendering to be just tragically bad. (Update: it built and runs fine and renders fonts every bit as badly as I expected.)

Tomorrow I will probably try building FF4 on Ubuntu 10.10, whose libcairo2 is at 1.10. I tried running the Linux prebuilt binaries from Mozilla on my Ubuntu machine, but as I have come to expect from Mozilla's FF builds, cairo did not seem to be enabled. (Update: Building on Ubuntu also failed. Apparently FF4 with enable-system-cairo also needs cairo-tee greater than 1.10, but Ubuntu's libcairo2 doesn't seem to be built with --enable-tee=yes.)

It seems every other post of mine in the last couple years has dealt with the agonies I've had in getting consistently good font rendering in Linux. It really shouldn't be this difficult.

OpenOffice.org + dark theme + Openbox

I've been noodling with the very, very dark aud-Default GTK+ theme--which also happens to play very well with the Onyx Openbox theme. However, as nicely as it plays with Onyx, it plays very, very badly with OpenOffice.org. If you get your Google on, you'll find a number of workarounds for OO.org and dark themes. What I wanted is an easy to implement and (more importantly de-implement) solution. A solution in the Crunchbang Linux forums spells out just the ticket. In your ~/.config/openbox/autostart.sh file, add the line:

export SAL_USE_VCLPLUGIN=gen

This will make OO.org fallback to its native theme ... ugly as sin, but usable.

Note that if you are having the opposite problem--that you can't get OO.org to render with your GTK theme--then try adding:

export OOO_FORCE_DESKTOP=gnome
export SAL_USE_VCLPLUGIN=gtk

instead. This suggestion is from the #! forums and Urukrama's blog.

There are a few other usability issues I'm having with aud-Default , but I'm willing to work at it some more given the sweet way it renders entries in fbpanel's taskbar.

Fixing overzealous hard drive head parking

Debian Squeeze on my Samsung R510 has been working very well, with one exception: pause... pause... click... pause... pause... pause... click... The hard drive seems to be overzealous about parking its heads. There are some (strawman alert?) who feel that heavy head parking actually reduces the life of a drive. Whether or not that's the case, I find the frequent clicking to be downright annoying on this otherwise intensely quiet computer.

As is the case with many things in Linux, a fix is at hand. Many thanks to SammyNetbook for pointing the way. The frequency of head parking can be changed by lowering the aggressiveness of APM power saving through the hdparm command. In the case of my lappy, running

# hdparm -B 254 /dev/sda

(as root) solved the headparking issue. (There maybe lower levels that work as well, but I'm happy enough with the result now that I haven't experimented.)

Running the command at startup
The effect of the above command ends at restart. To automatically run it when my lappy starts up, I used init.d. I first created a file mfk-hdsilence.sh in /etc/init.d:

#! /bin/sh
# /etc/init.d/mfk-hdsilence.sh
#

# Some things that run always
hdparm -B 254 /dev/sda

exit 0

Then to activate this:
# update-rc.d mfk-hdsilence.sh defaults

I got a warning when I did this, but it seemed safe to ignore. Result? A non-clicky, super silent lappy. Life is good.

Update: it seems suspending the lappy resets the drive's APM, so I'll need to figure out a way to rerun hdparm when waking up. I am currently experimenting with placing a file 30_mfk-hdsilence.sh in /etc/pm/sleep.d:

#! /bin/sh
# 30_mfk-hdsilence.sh
#

# silence aggressive head parking
case ${1} in
 resume|thaw)
  hdparm -B 254 /dev/sda
  ;;
esac

exit 0

It seems to be working, but I'll need to live with it for a while to make sure. Suspending under Linux is always stressful for me.

XDG menus in Openbox

Now I feel stupid. For year(s) I've been sorta griping about how the Openbox menu doesn't give you a program listing that coincides with what you get in GNOME, Xfce, and even fbpanel. I've hunted for solutions to this before but came up short. Turns out the solution is insanely simple.

The following is a direct quote from from the excellent ArchWiki. I tried it in Ubuntu Maverick and it works.

Obm-xdg

obm-xdg is a command-line tool that comes with Obmenu. It can generate a categorized sub-menu of installed GTK/GNOME applications.

To use obm-xdg, add the following line to ~/.config/openbox/menu.xml:

{menu execute="obm-xdg" id="xdg-menu" label="xdg"/}

(note: the curly brackets above should actually be angled brackets, but this crazy Blogger interface makes it close to impossible to write the above with angled brackets.)

Then run openbox --reconfigure to refresh the Openbox menu. You should now see a sub-menu labeled xdg in your menu.

Note: If you do not have GNOME installed, then you need to install gnome-menus package for obm-xdg to work.

Update: This is having issues on Squeeze. More later as I (if I) figure it out.

Java Swing anti-aliased font rendering

[Update 2011-04-03:  The Arch Wiki describes lots of options for the export below. I've been having good results with export _JAVA_OPTIONS='-Dawt.useSystemAAFontSettings=setting']

Today I noticed fonts in my Swing-based Java apps were utterly hideous. They were no longer being rendered with anti-aliasing. I don't know if this is because today I logged into a minimal Openbox+fbpabel setup and GNOME was handling this automatically or if it's caused by some other subtle thingy.

No matter, it's pretty easy to fix. Add

export _JAVA_OPTIONS="-Dawt.useSystemAAFontSettings=on"

to your ~/.profile file. You'll probably then have to logout and back in. After this anti-alised rendering will be the default.

Supposedly, you can do this system-wide by adding

_JAVA_OPTIONS="-Dawt.useSystemAAFontSettings=on"

to your /etc/environment file, but I have not tried this.

Update There is one downside to this: the JVM will write Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on to the console. It's not a deal-breaker, but it is a little annoying.