Pages

July 18, 2011

Fixing ugly Qt fonts in Openbox, Fluxbox, etc.

On Debian Squeeze at least, unless you are using GNOME or Xfce (or ostensibly KDE) or are running the configuration daemons that come with these, fonts rendered by Qt apps look like utter crap.

It seems that Qt honors neither ~/.fonts.conf, nor what's in ~/.fonts.conf.d, nor what's in /etc/fonts/conf.d. This is a problem if you want to run light-and-lean and not use the GNOME or Xfce daemons in Openbox, Fluxbox, and likely many other window managers.

After much hair pulling, I finally managed to work around the problem by using Xresources. Adding the code below to either ~/.Xresources (for user-only changes) or to a new file /etc/X11/Xresources/fonts-default (for system-wide changes) fixed the issue for me. It also fixes problems with ugly font rendering in OpenOffice.org and LibreOffice.

What I added is:
Xft.dpi: 96
Xft.antialias: true
Xft.hinting: true
Xft.rgba: rgb
Xft.autohint: false
Xft.hintstyle: hintslight
Xft.lcdfilter: lcddefault

The dpi entry is there just for good measure. Change settings as needed according to taste.

June 25, 2011

Fixing ugly LibreOffice UI in Squeeze

I removed OpenOffice.org from my recently Lenny-to-Squeeze updated machine and installed LibreOffice from backports instead. A succinct how-to for doing that is available here.

The installation went without a hitch, and LibreOffice started just fine. But the UI was ghastly, horribly, I would-rather-look-at-and-smell-a-garbage-bin ugly.

Easy fix:

# apt-get -t squeeze-backports install libreoffice-gtk

Aaah.

There is a libreoffice-gnome package as well. I don't know what the difference is yet, but I suspect it would be a good idea to go through all the libreoffice backports for Squeeze to see if there's anything else I missed.

Squeeze, Fonts, Firefox update

This is good.

This morning I finished upgrading a Lenny installation to Squeeze. (For those of you who might know what's coming next, this installation had the plain old standard libcairo2 -- no patches of any sort.) So far things seem to be just fine. But it's Debian and so this is no big surprise. This is not why I'm writing this post.

The reason for writing this post is to let you know that indeed the rumors are true. Installing Iceweasel 5 from http://mozilla.debian.net/ solves three problems that have plagued lots of Linux users:
  1. Obsolete Iceweasel/Firefox.
  2. Ugly font rendering with official Firefox binaries.
  3. Ugly font rendering everywhere on the system.
You heard it right, folks. Installing Iceweasel 5 in Squeeze brings in a version of libcairo2 with all the yummy Ubuntu font rendering goodness. Like I said, this is good.

But there are a couple small gotchas:

Confusing instructions
The directions given at http://mozilla.debian.net/ are complete, but the order in which the info is given is confusing. So here is what you need to do, in the order in which you need to do it.
  1. Add the following entry to /etc/apt/sources.list or a new file in /etc/apt/sources.list.d/:
    deb http://mozilla.debian.net/ squeeze-backports iceweasel-release
  2. Add the archive key to your apt keyring:
    # wget -O- -q http://mozilla.debian.net/archive.asc | gpg --import

  3. Import it into the APT keyring:
    # gpg --export -a 06C4AE2A | sudo apt-key add -

  4. Update the repository database:
    # apt-get update

  5. Install Iceweasel 5 with the following command:
    # apt-get install -t squeeze-backports iceweasel

Configuring fonts
After I did the above, fonts were still not quite right. So I added the ~/.fonts.conf  file posted here here*. (Blogger, please make it possible to post code with angled brackets!!)

I don't know which is the magic setting responsible for letting the fonts come out all pretty (I suspect lcdfilter), but I'm happy enough with the results now that I'll just be using the setup for a while. It's only a process of elimination to figure out which setting is the key, and once it's found it should be an easy matter to make these the system default so you don't need the ~/.fonts.conf file.

[update 2011-07-11: Changed sources.list addition to reflect changes at http://mozilla.debian.net/.] 
*[update 2011-07-01: I added rgba settings for completeness.]

June 11, 2011

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.

April 02, 2011

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.

March 23, 2011

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.

February 02, 2011

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.