Jaunty Tooltip Annoyance

August 23rd, 2009

I upgraded to Jaunty a few days ago, and have been happy with the new version for the most part. One thing was driving me crazy though: the tooltips in the workspace switcher were staying up until I moved the mouse over them. This is way more annoying than you might think. Imagine that you’re trying to write some code, and switching frequently between your IDE on desktop 1 and the API reference in your browser window on desktop 4. After every switch, there’s a useless tooltip hovering over the panel, partially obscuring your windows, and it won’t go away until you mouse over it. It’s like trying to code while a gnat is constantly buzzing around your face.

There’s a bug filed against it, of course, but there’s no workaround. I did find two blog posts that offered a workaround of sorts by globally disabling all panel tooltips. At first I thought that was a bit extreme, but after swatting a few hundred tooltips I was ready to try anything. Unfortunately, this setting did not appear to have any effect, even after restarting the panel. I was still getting the tooltips.

*Sigh*. Well, seeing as how I do claim to be a programmer, and I can often be found extolling the virtues of open source to people who mostly don’t care, maybe I should practice what I preach, dive into the source code, and fix it myself. Right? Right.

It turns out this is really easy to fix. Assuming, of course, that your definition of “fix” is the same as mine, which is “disable all tooltips for the workspace switcher applet”. There is a global setting to do this, and it just requires changing a single line of code.

To build a fixed version of libwnck, first download the patch, and save it to the /tmp directory. Then run the following commands in a terminal:

$ sudo apt-get build-dep libwnck
$ apt-get source libwnck
$ cd libwnck-2.26.0
$ patch -p0 </tmp/libwnck-notooltip.patch
$ debchange -v 2.26.0-ubuntu1+notooltips

The debchange command will keep APT from “upgrading” your custom package. It will open the debian/changelog file in the default editor so you can enter a description. You can skip this step if the notification to upgrade libwnck doesn’t bother you.

$ debuild -rfakeroot binary
$ cd ..
$ sudo dpkg -i libwnck-common_2.26.0-ubuntu1+notooltips_all.deb libwnck22_2.26.0-ubuntu1+notooltips_i386.deb
$ killall gnome-panel

If you don’t want to build the packages yourself, you can download mine here.

How to keep APT from reinstalling custom packages (Ubuntu)

March 31st, 2009

A few weeks ago, I finally got around to upgrading my Ubuntu desktop to Hardy Heron. Like many others, I found that the cursor in gnome-terminal had inexplicably started blinking again, and there was no longer a preference to disable it. Fortunately, finding a fix was easy. Applying the patch and rebuilding the .deb package was even easier. But after installing the patched package, the update-notifier immediately informed me that there was one update available: gnome-terminal. It seems that APT prefers packages in the repository over locally installed packages.

I ignored this for a while, and just dealt with the “updates available” icon always being in the notification area. I tried searching google several times, and eventually came across this forum post, which led to this article containing the answer I was looking for.

I could probably just pin gnome-terminal, but I want to make sure I get any future updates for it. I decided the easiest way to fix this annoyance was by appending a short string (+noblink) to the version.

First, fetch the source and update the version:

$ apt-get source gnome-terminal
$ cd gnome-terminal-2.22.1
$ debchange -v 2.22.1-0ubuntu2+noblink

At this point, the default editor will open the debian/changelog file so you can describe the change. Enter a short comment, like “disable the blinkin cursor”, save the file and exit the editor.

Next, patch the source. Jay Cornwall’s patch is not currently on-line, but it’s a simple fix: just edit src/terminal-screen.c and change this line

terminal_widget_set_cursor_blinks (screen->priv->term, blink);

to this

terminal_widget_set_cursor_blinks (screen->priv->term, FALSE);

Finally, build and install the package:

$ debuild -rfakeroot binary
$ sudo dpkg -i ../gnome-terminal*.deb

Starting a New X Server

February 22nd, 2009

This is one of those posts that is mostly for me, so the next time I need to do this I don’t have to spend 30 minutes googling obscure config file formats. (Incidentally, I had to google and muck with styles for at least 30 minutes to figure out how to keep wordpress from mangling my code snippets.)

I sometimes find it useful to start an extra X server to run a particular application. Full-screen games are a good example. Ordinarily, a full-screen game grabs the display and there is no way to switch back to the desktop without exiting the game completely. When run in its own X server though, it is easy to switch between servers. The following shell script shows how to do this:

#!/bin/bash

display=:1
authfile=$HOME/.Xauthority

if ! xauth list "$display" | grep "$display " >/dev/null 2>&1; then
    xauth add $display . `mcookie`
    removelist="$display"
fi

xinit /usr/bin/xterm -- $display -auth $authfile -nolisten tcp

if [ -n "$removelist" ] ; then
    xauth remove $removelist
fi

This script will start a new X server on the next available virtual terminal (normally vt8) using display :1 and launch an xterm. Toggle between the servers using ctrl-alt-F7 and ctrl-alt-F8. When the xterm exits, so does the X server.

If you try to run this code on a Debian-based system, though, you will get the following error:

X: user not authorized to run the X server, aborting.
xinit:  Server error.

I found this out the hard way when I started using ubuntu. This is because Debian uses a wrapper to start the X server, which enforces tighter security constraints by default. To get this to work, you will need to edit the /etc/X11/Xwrapper.config file, and change this line:

allowed_users=console

to this:

allowed_users=anybody

Check the man page for Xwrapper.config for more options; there aren’t very many. Personally, I don’t consider this a security risk for a single-user home system.

About Me

February 16th, 2009

My name is Jason Day. I am a programmer in Atlanta, GA. My first real programming experience was at a computer programming day camp at the local community college, in around 1980. We learned to program in BASIC on an Apple ][, and I was hooked. I couldn’t afford a computer, but I did have an Atari 2600, and there was a BASIC Programming cartridge available. What a cruel joke that was. It did keep me somewhat entertained though until I was able to acquire an Atari 600XL, which is what I really cut my programming teeth on. I didn’t have a disk drive or even a cassette drive; I had to enter everything by hand, every time. With a little help from Compute! magazine, I would spend hours typing in BASIC programs for silly games and playing them.

I continued my programming education in college, this time on a 386SX 25 Mhz IBM compatible, with a whopping 2 megabytes of RAM and a 52 MB hard drive. I taught myself x86 assembly language, to enhance the DOS batch “programming language”. I took courses in FORTRAN and Pascal, then C, C++, LISP and MIPS assembly language.

My first “real job” out of college was at a media company called iXL (now defunct). I started as a junior C/C++ developer, helping to port a game to Windows 95. While there I taught myself Java and Perl, eventually writing primarily back-end code in servlets and JSPs.

These days I do most of my programming in Java. But I’ve never lost the thirst to learn new languages, or about programming in general. I also make some code available on my web site.


Copyright © 2024 jlogday.com. All Rights Reserved.
No computers were harmed in the 4.366 seconds it took to produce this page.

Designed/Developed by Lloyd Armbrust & hot, fresh, coffee.