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
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:
GeoIP.datNext create an alias for the command geoiplookup, for example through your ~/.bashrc script put the following line:
LICENSE.txt
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:
- DesktopLog.ds
(if
(is (window_class) "DesktopLog")
(begin
(wintype "dock")
(geometry "+20+45")
(below)
(undecorate)
(skip_pager)
(opacity 80)
)
)
devilspie is running, and spawning a single xterm process:- desktop-log.sh
#!/bin/sh
test `pidof devilspie` || devilspie &
xterm -geometry 164x73 -uc -class DesktopLog -T daemon.log -e sudo tail -f /var/log/daemon.log &
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.- DesktopLog.ds
(if
(matches (window_class) "DesktopLog[0-9]+")
(begin
(wintype "dock")
(below)
(undecorate)
(skip_pager)
(opacity 80)
)
)
(if
(is (window_class) "DesktopLog1")
(geometry "+480+20")
)
(if
(is (window_class) "DesktopLog2")
(geometry "+20+20")
)
(if
(is (window_class) "DesktopLog3")
(geometry "+20+330")
)
- desktop-log.sh
#!/bin/sh
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 msgdiff.sh
Pros: tools available on every systemCons: ugly output, needs template file
#!/bin/sh
PO_ORIG=$1
PO_REVIEW=$2
PO_TEMPL=$3
MSGMERGE=msgmerge
DIFF=diff
PAGER=more
RM=/bin/rm
MKTEMP=mktemp
# Usage
if test "$1" = "" -o "$2" = "" -o "$3" = ""; then
echo Usage: $0 orig.po review.po template.pot
exit 1
fi
# Merge
TMP_ORIG=`$MKTEMP po-orig.XXX`
TMP_REVIEW=`$MKTEMP po-review.XXX`
$MSGMERGE $PO_ORIG $PO_TEMPL > $TMP_ORIG 2> /dev/null
$MSGMERGE $PO_REVIEW $PO_TEMPL > $TMP_REVIEW 2> /dev/null
# Diff
$DIFF -u $TMP_ORIG $TMP_REVIEW | $PAGER
# Clean up files
$RM $TMP_ORIG $TMP_REVIEW
Example:
$ ./msgdiff.sh fr.po fr.review.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 podiff.py
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)):
po_diff.append(entry)
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]
sys.exit(1)
# 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)
Example:
$ ./podiff.py fr.po fr.review.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”
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.
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”
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:
- Check if the application is invisible and show it,
- Otherwise check if the window is inactive and present it,
- Otherwise hide it.
/* Show the window */I have been doing this for quite a long time inside the Xfce Notes plugin, except a little different with multiple windows.
if (!(GTK_WIDGET_VISIBLE(window))) {
gtk_widget_show(window);
}
/* Present the window */
else if (!gtk_window_is_active(GTK_WINDOW(window))) {
gtk_window_present(GTK_WINDOW(window));
}
/* Hide the window */
else {
int winx, winy;
gtk_window_get_position(GTK_WINDOW(window), &winx, &winy);
gtk_widget_hide(window);
gtk_window_move(GTK_WINDOW(window), winx, winy);
}
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)
index(idx)
end
end
class Dir
def exists?(path)
File.directory?(path)
end
end
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
else
return super
end
end
end
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
autogen.sh 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 Makefile.am files and accepts an optional version check.
AM_MAINTAINER_MODE()
if test "x$USE_MAINTAINER_MODE" = "xyes" ; then3. It is possible to sum up the build configuration at the end of the autoconf script.
AM_PROG_VALAC([0.7.4])
if test "x$VALAC" = "x" ; then
AC_MSG_ERROR([Cannot find the "valac" compiler in your PATH])
fi
fi
echo
echo "Build Configuration:"
echo
echo "* Maintainer Mode: $USE_MAINTAINER_MODE"
if test "x$USE_MAINTAINER_MODE" = "xyes" ; then
echo
echo " * Vala: $VALAC"
echo
fi
Automake script
1. The declaration of the Vala sources and their respective compiled C sources.product_VALASOURCES = \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.
obj1.vala \
obj2.vala \
main.vala
product_VALABUILTSOURCES = $(product_VALASOURCES:.vala=.c) product.h
if MAINTAINER_MODE3. 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.
PACKAGES = --pkg=gtk+-2.0
BUILT_SOURCES = vala.stamp
vala.stamp: $(product_VALASOURCES)
$(VALAC) --vapidir=$(srcdir) $(PACKAGES) $^ -C -H product.h
touch $@
endif
product_SOURCES = \
random-source.c \
random-header.h \
$(product_VALABUILTSOURCES)
EXTRA_DIST = $(product_VALASOURCES)
if MAINTAINER_MODE
CLEANFILES = \
$(BUILT_SOURCES) \
$(product_VALABUILTSOURCES)
endif
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.
