Category Archives: Tips

Update the GeoIP database

GeoIP is a proprietary technology provided by MaxMind that allows the geolocalization of IPs. It provides databases as both free and paid solutions with IP records matching the country and the city. The GeoLite Country database can be downloaded for free and is updated about once a month.

The database can be used with the command line tool geoiplookup . By calling it, it will check for the default database, but you can specify another one through a command line option.

First download and install the latest database and license under your home directory, for example ~/.local/share/GeoIP/. Make sure to decompress the database with gunzip. The directory has to contain these files:
Next create an alias for the command geoiplookup, for example through your ~/.bashrc script put the following line:
alias geoiplookup='geoiplookup -d $HOME/.local/share/GeoIP/'

And done! But why all the hassle? Because your system may not provide the updates on a regular basis. Of course you can set up a scheduled task to download the database right into your home directory.

XTerm as root-tail

The idea behind this title is to use XTerm as a log viewer over the desktop, just like root-tail works. The tool root-tail paints text on the root window by default or any other XWindow when used with the -id parameter.

Using XTerm comes with little advantage, it is possible to scroll into the “backlog” and make text selections. On a downside, it won't let you click through into the desktop, therefore it is rather useful for people without desktop icons for example.

We will proceed with a first simple example, by writing a Shell script that will use the combo DevilsPie and XTerm. The terminals will all be kept in the background below other windows and never take the focus thanks to DevilsPie. DevilsPie is a tool watching the creation of new windows and applies special rules over them.

Obviously, you need to install the command line tool devilspie. It's a command to run in the background as a daemon. Configuration files with a .ds extensions contain matches for windows and rules that are put within the ~/.devilspie directory.

First example

The first example shows how to match only one specific XTerm window.

The DevilsPie configuration:
(is (window_class) "DesktopLog")
(wintype "dock")
(geometry "+20+45")
(opacity 80)
The Shell script making sure devilspie is running, and spawning a single xterm process:
test `pidof devilspie` || devilspie &
xterm -geometry 164x73 -uc -class DesktopLog -T daemon.log -e sudo tail -f /var/log/daemon.log &
NB: You can notice the size of the XTerm window is set through the Shell script while the position is set through the DevilsPie rules file, and there is a simple reason for this. By default XTerm has a size of 80 columns and 24 lines and text with too long lines will be wrapped on the next line. If afterwards you resize the window the wrapped text won't move up and the result will be ugly. Therefore it's better to set the initial size of the terminal correctly.

To try the example, save the DevilsPie snippet inside the directory ~/.devilspie, and download and execute the Shell script. Make sure to quit any previous DevilsPie process whenever you modify or install a new .ds file.

Second example

The second example is a little more complete, it starts three terminals of which one is coloured in black.
(matches (window_class) "DesktopLog[0-9]+")
(wintype "dock")
(opacity 80)
(is (window_class) "DesktopLog1")
(geometry "+480+20")
(is (window_class) "DesktopLog2")
(geometry "+20+20")
(is (window_class) "DesktopLog3")
(geometry "+20+330")
test `pidof devilspie` || devilspie &
xterm -geometry 88x40 -uc -class DesktopLog1 -T daemon.log -e sudo -s tail -f /var/log/daemon.log &
xterm -geometry 70x20 -uc -class DesktopLog2 -T auth.log -e sudo -s tail -f /var/log/auth.log &
xterm -fg grey -bg black -geometry 70x16 -uc -class DesktopLog3 -T pacman.log -e sudo -s tail -f /var/log/pacman.log &

NB: You will probably notice that setting the geometry is awkward, specially since position and size are in two different files, getting it right needs several tweakings.

This blog post was cross-posted to the Xfce Wiki.

CLI tool to review PO files

If there is something annoying about reviewing PO files is that it is impossible. When there are two hundred messages in a PO file, how are you going to know which messages changed? Well, that's the way it works currently for Transifex but there are very good news, first a review board is already available which is a good step forward but second it is going to get some good kick to make it awesome. But until this happens, I have written two scripts to make such a review.

A shell script

Pros: tools available on every system
Cons: ugly output, needs template file



# Usage
if test "$1" = "" -o "$2" = "" -o "$3" = ""; then
echo Usage: $0 orig.po review.po template.pot
exit 1

# Merge

# Diff

# Clean up files

$ ./ fr.po thunar.pot
#: ../thunar-vcs-plugin/tvp-git-action.c:265
-#, fuzzy
msgid "Menu|Bisect"
-msgstr "Différences détaillées"
+msgstr "Menu|Couper en deux"

#: ../thunar-vcs-plugin/tvp-git-action.c:265
msgid "Bisect"
-msgstr ""
+msgstr "Couper en deux"

A Python script

Pros: programmable output
Cons: external dependency

The script depends on polib that can be installed with the setuptools scripts. Make sure setuptools is installed and than run the command sudo easy_install polib.

#!/usr/bin/env python
import polib

def podiff(path_po_orig, path_po_review):
po_orig = polib.pofile(path_po_orig)
po_review = polib.pofile(path_po_review)
po_diff = polib.POFile()
po_diff.header = "PO Diff Header"
for entry in po_review:
orig_entry = po_orig.find(entry.msgid)
if not entry.obsolete and (orig_entry.msgstr != entry.msgstr \
or ("fuzzy" in orig_entry.flags) != ("fuzzy" in entry.flags)):
return po_diff

if __name__ == "__main__":
import sys
import os.path

# Usage
if len(sys.argv) != 3 \
or not os.path.isfile(sys.argv[1]) \
or not os.path.isfile(sys.argv[2]):
print "Usage: %s orig.po review.po" % sys.argv[0]

# Retrieve diff
path_po_orig = sys.argv[1]
path_po_review = sys.argv[2]
po_diff = podiff(path_po_orig, path_po_review)

# Print out orig v. review messages
po = polib.pofile(path_po_orig)
for entry in po_diff:
orig_entry = po.find(entry.msgid)
orig_fuzzy = review_fuzzy = "fuzzy"
if "fuzzy" not in orig_entry.flags:
orig_fuzzy = "not fuzzy"
if "fuzzy" not in entry.flags:
review_fuzzy = "not fuzzy"
print "'%s' was %s is %s\n\tOriginal => '%s'\n\tReviewed => '%s'\n" % (entry.msgid, orig_fuzzy, review_fuzzy, orig_entry.msgstr, entry.msgstr)

$ ./ fr.po
'Menu|Bisect' was fuzzy is not fuzzy
Original => 'Différences détaillées'
Reviewed => 'Menu|Couper en deux'

'Bisect' was not fuzzy is not fuzzy
Original => ''
Reviewed => 'Couper en deux'

Don’t produce Gzipped tarballs

A quick note so I can delete it from my desktop. In order to produce only a Bzip2 tarball with the Autotools, specially when running make distcheck, set the automake init call with these parameters:

AM_INIT_AUTOMAKE([no-dist-gzip dist-bzip2])

By the way I wonder if it's worth dumping bzip2 against xz.

VLC with GTK+ look-n-feel

To get Qt applications to look like GTK+ applications run qtconfig and in Select GUI Style choose GTK+. Next click in the menu bar File > Save.

Something is still puzzling me, why does GNOME run VLC automatically with native GTK+ look-n-feel and not Xfce?

Update: Thanks to the power of tig and grep, I figured the Qt library (qt_init function) defines the desktop environment as GNOME for Xfce (this results in GTK+ theming, GNOME like Open dialogues, etc) by retrieving an X11 atom on the root window and compares it to “xfce4” but it seems that this doesn't work nowadays (at least it didn't work within an Xfce 4.7 desktop session). I'm looking forward for sending patches.

Update2: The latest version Qt 4.6.2 doesn't include the code for checking the X11 atom (it's in git), which explains why it doesn't work.

Include custom GTK+ RC style

I've been using a custom GTK+ RC style for the notes plugin since the version 1.4.0, right now it is at version 1.7.2. I have been playing with GTK+ theming again these last two hours, and I've get custom scrollbars, a gradient for the custom-made “title bar”, and better colours for the notebook to get the current tab stand out from the crowd.

While experimenting on a test-case code I found out a better way to parse a gtkrc file in the program. The first time I was fighting with the existing gtk_rc related functions, I gave up on a solution I partially dislike that is to include a line to the custom gtkrc file within ~/.gtkrc-2.0.

Today I understood how gtk_rc_parse(filename) behaves. You have to call this function at the beginning of the program before building any widgets, it will work even if the file doesn't exist yet. Next, while the program is running, you can modify the file, create it, delete it, truncate it, whatever, and call gtk_rc_reparse_all() to get the style refreshed in the GUI. It's hard to believe that such easy things are sometimes a PITA :-)

Be prepared for a 1.7.3 notes plugin with nicer colours.

Show/hide functionality from notification area

When using a status icon within the notification area it is common to use the left-click action to show/hide the main window. Obviously this is often done in different ways. So here is my tip on how to do it right :-)

What I believe to me the most sense-full way is to:
  1. Check if the application is invisible and show it,
  2. Otherwise check if the window is inactive and present it,
  3. Otherwise hide it.
In C language it looks like this:
/* Show the window */
if (!(GTK_WIDGET_VISIBLE(window))) {
/* Present the window */
else if (!gtk_window_is_active(GTK_WINDOW(window))) {
/* Hide the window */
else {
int winx, winy;
gtk_window_get_position(GTK_WINDOW(window), &winx, &winy);
gtk_window_move(GTK_WINDOW(window), winx, winy);
I have been doing this for quite a long time inside the Xfce Notes plugin, except a little different with multiple windows.

Some remarks, the PendingSealings proposes gtk_widget_get_visible instead of its analogous MACRO. And as you may also notice when the window is hidden it gets moved just after, this is important as otherwise the window would be repositioned by its initial value once shown again (e.g. centre of screen or dynamically by the window manager).

Backward compatibility for Ruby 1.8

As I'm currently writing some Ruby code and that I started with version 1.9 I felt onto cases where some methods don't exist for Ruby 1.8. This is very annoying and I started by switching the code to 1.8 method calls. I disliked this when it came to Process.spawn which is a one line call to execute a separate process. Rewriting it takes around 5 lines instead.

So I had the idea to reuse something I already saw once. I write a new file named compat18.rb and include it within the sources that need it. Ruby makes it very easy to add new methods to existing classes/modules anyway, even if they exist already, so I just did it and it works like a charm.

Here is a small snippet:
class Array
        def find_index(idx)

class Dir
        def exists?(path)

Update: It can happen that a fallback method from Ruby 1.8 has been totally dropped and replaced against a new method in 1.9, and in this case the older method has to be checked if it exists, and otherwise make a call to the parent.
class Array
        def count
                if defined? nitems
                        return nitems
                        return super

Build a project with Vala

This post is about using Vala in a project but in the end provide the C code for the releases. I think that this is very essential and that releasing source code to be build from Vala is wrong. Vala will always rewrite the code to GObjects in C, but has already proven that compiling the same code from two different versions of Vala will fail. So when you are doing releases with Vala you will break your releases sooner or later. Another good point is when the Vala code is compiled on top of patched vapi files, doing only C compilation with the releases will drop the requirement to apply them.

I'll take as example the Autotools, if you are using a different tool-chain you can surely adapt it. The idea is simple, the Vala sources are only compiled in maintainer mode. When you compile the application from the development branch you will usually have a script called to build the configure script that will automatically be executed with the parameter --enable-maintainer-mode. When providing the distribution tarball that is created with make distcheck, the configure script will not be run with that parameter (except if specified by hand) and the source files to build from will be filled in with the C filenames.

The example below is very generic and can be copy/pasted but should be adapted.

Autoconf script

1. The initialization of Automake and the maintainer mode in the autoconf script. The Automake version is checked for 1.11 which is the first version that comes with Vala support. The extra dist-bzip2 argument is there to provide an extra bzipped distribution tarball as you guessed it.
AM_INIT_AUTOMAKE([1.11 dist-bzip2])
2. The check for Vala only on maintainer mode. The AM_PROG_VALAC defines the variable VALAC that can be reused inside the files and accepts an optional version check.
if test "x$USE_MAINTAINER_MODE" = "xyes" ; then
if test "x$VALAC" = "x" ; then
AC_MSG_ERROR([Cannot find the "valac" compiler in your PATH])
3. It is possible to sum up the build configuration at the end of the autoconf script.
echo "Build Configuration:"
echo "* Maintainer Mode: $USE_MAINTAINER_MODE"
if test "x$USE_MAINTAINER_MODE" = "xyes" ; then
echo " * Vala: $VALAC"

Automake script

1. The declaration of the Vala sources and their respective compiled C sources.
product_VALASOURCES = \
obj1.vala \
obj2.vala \

product_VALABUILTSOURCES = $(product_VALASOURCES:.vala=.c) product.h
2. Use the special BUILT_SOURCES variable to build given targets before running a dist with e.g. make distcheck. This usually done in maintainer mode, as in this case to be sure the releases won't have anything to do with Vala.
PACKAGES = --pkg=gtk+-2.0
BUILT_SOURCES = vala.stamp
vala.stamp: $(product_VALASOURCES)
$(VALAC) --vapidir=$(srcdir) $(PACKAGES) $^ -C -H product.h
touch $@
3. The final sources for the product are filled in with the generated Vala sources. The Vala sources are not passed to any SOURCES which is why they are passed to the special EXTRA_DIST variable.
product_SOURCES = \
random-source.c \
random-header.h \


That's it

There are many existent Vala projects nowadays from where you can pick up new ideas, and this post is just an example amongst many others. The full example is available in the xfce4-vala bindings.

Update: I corrected some mistakes seen in green in the script portions. If VALAC is unset the configure script must quit otherwise the resulting Makefiles will have empty commands instead of /usr/bin/valac. Also the generated header file must be passed to product_VALABUILTSOURCES otherwise it would have been left out from distributions as it wans't passed to any product_SOURCES nor EXTRA_DIST variables.

Refresh the Xfce background

In Xfce 4.4 there was a little hack that worked to refresh the background. I managed to get the same result for Xfce 4.6 with the following "hack":
if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ] ; then
. ${HOME}/.dbus/session-bus/`ls -rt ${HOME}/.dbus/session-bus/ | tail -1`
IMAGE_PATH=`xfconf-query -c xfce4-desktop -p ${PROPERTY}`
xfconf-query -c xfce4-desktop -p ${PROPERTY} -s ""
xfconf-query -c xfce4-desktop -p ${PROPERTY} -s "${IMAGE_PATH}"
Now when will this be useful? Barely never. Still enjoy it :-)

Update: script snipped updated to run within a cronjob.