January 22, 2013
Moved to a new address…

Please note, and if need be update whatever you need to update, that this blog has now moved to jjacky.com — Thank you.

December 8, 2012
kalu could speak your language

The next version of kalu - upgrade notifier for Arch Linux - is almost ready, and one of the changes it will introduce, is support for internationalization.

In other words, kalu is ready to speak your language!

Source code has been (reorganized and) modified to use gettext, it’s ready, all it needs now to speak other languages, are translations.

So, if you like kalu but would like it better if it spoke your language, please consider translating it.

Create a translation

If you want to translate kalu and are alredy familiar with the whole gettext process, you probably know better than I do what to do.

If not, here’s a little guide that should allow anyone to make a translation :

First, clone the git repo (brach next) and prepare things :

git clone https://github.com/jjk-jacky/kalu.git -b next
cd kalu
cd po
make kalu.pot

Then create a new PO file for your locale using msginit : msginit

If you want to create a translation for another locale than your current one, you’ll simply have to use option -l, e.g. for French (fr) : msginit -l fr

Edit the generated .po file (using your editor of choice), translating each msgid in the corresponding msgstr. (Also make sure to check the comments on top, including your name, email, etc. It’s also recommended to use UTF-8 as charset.)

Edit LINGUAS and add the language code (name of the .po file, without .po) on a new line.

To test your translation, first make the .gmo file for your translation, e.g: make fr.gmo

Then you’ll have to build & install kalu, as usual. You can create yourself a PKGBUILD to do so, see this one as example, and simply update the _gitroot variable to point to your local clone. (Make sure to have committed your changes to LINGUAS and your new .po file.)

Just start kalu, and it should speak your language. Note that if writing a translation for a locale other than your current one, you’ll have to specify it on launch, e.g: LANG=fr_FR.utf8 kalu (Also note that you might have to re-generate your locales to include it.)

When you’re satisfied with the translation, simply send it over to have it included in the next release. You can :

  • Fork kalu of github and send a pull request; Or
  • Host the .po file somewhere and open an issue with a link; Or
  • Send me the file via email

November 4, 2012
Easily list package dependencies

Sometimes I wonder about a package and its dependencies, and more specifically the (installed) size of it all. For a simple list of a package’s dependencies, pactree is a great tool that does the job fine.

But when I’m wondering about the size, something else is needed. In fact, quite a few times I’ve found myself doing a pacman -S/-Rs package in order to know either how much size a package (and its “exclusive” (as in not needd by any other packages) dependencies) are eating up, or how much would be needed to install them.

This isn’t, however, an ideal solution, obviously. It does require root privileges, even though I don’ go through with the transaction, and adds useless entry in pacman.log

So I started thinking about it a bit, fast-forward a little and here comes pacdep

pacdep: Package Dependencies listing

pacdep is a little tool that will show the installed size of the package, its exclusive dependencies, and its shared dependencies; Optional dependencies can be shown as well.

By default pacdep searches the local database first, and if not found searches all sync databases, making it easy to use with packages installed or not all the same. Of course, there’s an option to use sync databases only, should you need that.

Package names are prefixed by the repository name they were found in when they’re not from the local database.

As hinted, pacdep creates groups of dependencies: exclusive ones, shared ones, and (optionally) optional ones. By default, only the total size of each group will be shown, but of course you can have packages of any of those groups be listed.

Package size

After the package’s installed size, in parenthesis will be the installed size of the package and its exclusive (and optional, if --show-optional was used) dependencies.

If the package is from local database (i.e. is installed), only dependencies from local database are taken into account. If it is from a sync database (i.e. is not installed), only dependencies from sync databases are taken into account.

In other words, this size represents either the size the package and its dependencies are using on the system (size that could potentially be freed if removing the package and its dependencies), or the size needed to install them.

Reverse Mode

When option --reverse is used, instead of listing the dependencies of the specified packages, pacdep will list packages that require them (i.e. the dependency tree is browsed in reverse).

By default only immediate “requirers” are listed, i.e. packages that have one of the specified packages as dependency.

Specifying the option a second time will go through the entire dependency tree, until a package that isn’t required is found. All packages met will be listed.

Specifying the option a third time will go through the dependency tree all the same, but only the end packages (that aren’t required) will be listed.

Optional Requirements

Just like in “regular” mode, you can have optional dependencies taken into account as well.

Instead of listing optional dependencies, you can list packages that have one of the specified packages as optional dependency.


To give you a quick idea of what you can get, here are a few examples.

Listing exclusive & optional dependencies of git :

% pacdep -eo git
git                      17.24 MiB ( 20.71 MiB)
Exclusive dependencies:   2.76 MiB
 perl-convert-binhex  56.00 KiB
 perl-error           76.00 KiB
 perl-io-socket-ssl  140.00 KiB
 perl-io-stringy     148.00 KiB
 perl-mailtools      204.00 KiB
 perl-net-ssleay       1.93 MiB
 perl-timedate       228.00 KiB
Optional dependencies:  732.00 KiB
 perl-authen-sasl  188.00 KiB
 perl-mime-tools   500.00 KiB
 perl-net-smtp-ssl  44.00 KiB
Shared dependencies:     20.09 MiB
Total dependencies:      23.57 MiB ( 40.81 MiB)

Listing optional dependencies of git, in quiet mode, using raw sizes :

% pacdep -oqw git
git 18079744
perl-authen-sasl 192512
perl-mime-tools 512000
perl-net-smtp-ssl 45056

Listing packages (sorted by size) that (optionally) require git, from sync databases :

% pacdep -Roz --from-sync git
extra/git                17.24 MiB
Required by:              7.47 MiB
 community/giggle         2.41 MiB
 community/gitg           1.70 MiB
 extra/archboot           1.20 MiB
 community/qgit         948.00 KiB
 community/sparkleshare 880.00 KiB
 community/tig          232.00 KiB
 community/hub          160.00 KiB
Optionally required by:  71.18 MiB
 community/qtcreator           50.10 MiB
 extra/kdevelop                13.02 MiB
 community/zim                  7.01 MiB
 extra/kdesdk-dolphin-plugins 540.00 KiB
 community/luarocks           536.00 KiB
Total dependencies:      78.65 MiB ( 95.89 MiB)

Listing optional dependencies of gparted (not installed), including all optional dependencies ;

% pacdep -oppp gparted
extra/gparted             5.58 MiB ( 34.05 MiB)
Exclusive dependencies:  29.37 MiB
 local:    8.12 MiB
 sync:    21.25 MiB
Optional dependencies:    9.00 MiB
 local:    1.77 MiB
  polkit               1.77 MiB
 sync:     7.23 MiB
  extra/dosfstools   240.00 KiB
  extra/gpart         52.00 KiB
  core/jfsutils        1.03 MiB
  extra/mtools       412.00 KiB
  core/nilfs-utils   512.00 KiB
  extra/ntfsprogs    576.00 KiB
  core/reiserfsprogs   1.01 MiB
  core/xfsprogs        3.44 MiB
Shared dependencies:    244.99 MiB
Total dependencies:     283.35 MiB (288.93 MiB)


If you want to give it a try, go ahead. pacdep is released under GNU GPL v3+ The source code is available on this GitHub repository.

You can also find a PKGBUILD in the AUR.

And of course bug reports, suggestions or any other form of constructive criticism is very much welcome.

October 27, 2012
PkgClip 1.1.0 & kalu 1.3.0 released

New versions of PkgClip - Cached Packages Trimmer Utility - and kalu - upgrade notifier for Arch Linux - have just been released.

PkgClip 1.1.0

Changes since last version are :

  • Use package description as tooltip for the Package column

  • Add a panel to show info about the focused item

    Info on panel can be defined through config option PkgInfo. Markup syntax is supported for formatting, as well as the following variables: $NAME, $DESC, $VERSION, $FILE, $SIZE, $RECOMM and $REASON

  • Update polkit policy: use auth_admin for all, add message & icon

  • pkgclip’s source code moved from a mercurial repo (https://bitbucket.org/jjacky/pkgclip) to a git one (https://github.com/jjk-jacky/pkgclip)

  • Add option --enable-git-version to configure. When enabled, the version used in pkgclip (and man page) will come from git describe ran at compile/make time.

kalu 1.3.0

Changes since last version are :

  • Add $DESC to all templates (but news) for package description

  • Update polkit policy: use auth_admin for all, add message & icon

  • kalu’s updater: Add tooltip to columns name & all sizes

  • Fix segfault on invalid JSON from the AUR

  • Fix invalid state when marking read while checking is still running

    Notifications appear as soon as possible, and allow user to mark things read/start upgrades. When this was done while the checking was still running, it wouldn’t be taken into account for kalu’s icon/tooltip.

  • Fix re-show notifications which would ignore conflicting files error.

    When the list of packages to upgrade couldn’t be compiled due to file conflict, a “special” notif is shown, with an error message but also the “Upgrade system” button. This notification wasn’t registered in the last_notifs list, and re-show would ignore it (e.g. say “no notifications to show”)

  • Fix download sizes possibly incorrect (when file already in cache)

    Cachedirs weren’t set with ALPM during the checks, but they are actually used when determining the download sizes, in case files are already downloaded/available in the cache.

  • Fix marking watched (AUR) packages could get garbage in memory

    Marking watched (AUR) packages as seen could sometimes lead to garbage used as new version number in memory (data on disk was valid).

  • Set icon & tooltip properly when conflict makes upgrades number unknown

  • If downloads (news, AUR…) are slow/timeout it might be linked to IPv6, in which case adding UseIP=4 in ~/.config/kalu/kalu.conf (under [options]) might help.

And for the record, I didn’t mention it here but on October 21st version 1.2.1 was released with a hotfix for an error checking news (due to the switch to https-only of Arch Linux website).

Downloads and whatnot

Thanks to all those who reported bugs or suggested features.

PkgClip is released under GNU GPL v3+ The source code is available on this GitHub repository, where bugs/suggestions can be added to the issue tracker.

The release tarball can be downloaded here; You can also find a PKGBUILD in the AUR.

kalu is released under GNU GPL v3+ The source code is available on this GitHub repository, where bugs/suggestions can be added to the issue tracker.

The release tarball can be downloaded here; You can also find a PKGBUILD in the AUR.

And of course, as always, new bug reports, suggestions or any other form of constructive criticism is very much welcome.

September 15, 2012
kalu 1.2.0 released

A new version of kalu - upgrade notifier for Arch Linux - has been released. Changes since last version are :

  • Instead of hard-coded use of xdg-open, one can now define the command line to be used when a link is clicked (in news). Variable $URL will be replaced by the URL to be opened.

    Additionally an error message will now be shown in case of failure.

  • On the command line to be executed on AUR upgrades, a variable $PACKAGES can now be used. It will be replaced by the list (space separated) of all AUR packages for which an upgrade is available.

  • It is now possible to have kalu re-show all notifications from the last ran checks. New option is available in the menu, and as action on single/double click.

    All notifications from the last ran checks will be shown as they were originally (including action buttons), including any error notifications.

    Notifications are removed/altered as needed. For instance, when marking watched (AUR) packages/news, the corresponding last notification will be removed (if nothing remains unread/unmarked), or altered to inform that running checks again is required (also, the button is gone).

    It should be noted that the tooltip doesn’t display status from the last ran check, but last known info. Meaning if the last checks failed (e.g. Internet connection was down), the tooltip will still show data from the (successful) check before, while re-show will only show the error notification(s).

  • Fixed a bug in marking watched (AUR) packages, where garbage could end up as new version number.

  • News parser now handles “all” kinds of new lines (<br >, <br / >, etc)

  • kalu’s updater: error messages of 1024+ characters are no longer being truncated

  • kalu’s source code moved from a mercurial repo (https://bitbucket.org/jjacky/kalu) to a git one (https://github.com/jjk-jacky/kalu)

  • Added option --enable-git-version to configure. When enabled, the version used in kalu (and man page) will come from git describe ran at compile/make time.

Downloads and whatnot

Thanks to all those who reported bugs or suggested features.

kalu is released under GNU GPL v3+ The source code is available on this GitHub repository, where bugs/suggestions can be added to the issue tracker.

The release tarball can be downloaded here; You can also find a PKGBUILD in the AUR.

And of course, as always, new bug reports, suggestions or any other form of constructive criticism is very much welcome.

September 10, 2012
How to convert a mercurial repo to git?

When I started working on a few things, and needed to use some version control, I used mercurial. This wasn’t really something I thought about all that much: I had used subversion & mercurial before (back on Windows) without problems, whereas with git the few times I had to use it (e.g. to try things quickly, or clone a repo) things weren’t as smooth (to me, that is).

Admittedly I never bothered looking into git then, and so mercurial was an obvious “choice” when I needed to use a VCS. Just like bitbucket was obvious for the same reason (it’s probably the best hosting solution with mercurial support).

But the Linux ecosystem loves git, they’re both quite close historically, and lately I decided to actually looked into git. I’m still not done with all the reading, but already I like it a lot.

It can do a lot, so far I understand & like how things work, and I therefore decided to move. Which means, I’ll have to convert my mercurial repos into git ones; starting with kalu.

The right tool for the job

There are many possible solutions to do the conversion. I tried a few :

  • First I used the hg-git plugin. It gives hg the ability to pull to and push from a Git server. Simple enough, however I wasn’t entirely satisfied with the results. (I don’t remember exactly why, but it had to do with tags being lightweight, maybe also missing branches…)

  • I then tried hg2git, but the results weren’t satisfying. Tags were still lightweight, which I was hoping to find a way around, and my branches had all (but master) been renamed “branch-xx”

  • Finally, I looked at fast-export, which gave me the most satisfying results.

The convertion itself is easy enough to do:

git clone git://repo.or.cz/fast-export.git .
rm -rf .git .gitignore
git init
./hg-fast-export.sh -r /path/to/hg/repo
git clean -f # remove fast-export files

Note: On Arch Linux, python 3 is the default, so you need to edit hg-fast-export.sh to add a 2: PYTHON=${PYTHON:-python2}

However, things still weren’t perfect. Tags were still lightweight, and my history was a bit of a mess. Though I believe this is my fault, due to the way things were done in hg.

I’m not sure if I just created this mess, or if it is due to the fact that branches work quite differently in git that they do in mercurial, but the end result is the same.

I ended up with two parallel branches in the history : master, where daily commits were done, and stable, where things were merged and tags done. This seemed alright at the time, but not anymore.

Because I wanted to have a “cleaner” (more linear) history in git, and one where all tags could be seen from the branch master. The branch stable should in fact just be in the same history line, only lower up until things are deemed stable and it gets fast-forwarded (and a tag is added).

So, even though I don’t know any python, I started looking at the source code, to see if I could help “improve” things a bit.

Let’s hack fast-export a bit

Lucky enough, things looked pretty simple & straight forward, and I was able to make a few adjustements.

As I said, I don’t know python so expect things to be ugly. And those are probably quite specific to my needs, and might not be applicable as-is to any other repo.

Create annotated tags

Tags were not annotated, even though in mercurial every time a tag is created, we have a commit (that updates the .hgtags file). fast-export was smart enough to ignore this file, since it’s completely useless in git, but still kept those (empty) commits.

I decided to change things, to ignore those commits (again, they were empty/useless in git, even more so without the .hgtags file around) and instead use their info (date, author…) to create the annotated tags.

Should be noted that I didn’t make sure this would always work, and it’s probably not ideal for a very large repo. But for the small one that I was working on, it worked fine.

Every time a commit is added, we check to see if it’s tagged. If so, the next commit will be “ignored”, and instead the annotated tag will be created. As mentionned, the commit author becomes the tagger, we re-use the date as well, and I forced the commit message to “Add tag for version <tag>" since all my tags are version number, and the original commit message was about the same, only referencing a mercurial changeset which, here, meant nothing.

It was also needed to adjust the marks used, to not reference the commit we didn’t import but the one before (i.e. the one tagged) instead.

Avoid the unnecessary history branch

One problem remained: at one point I had created a new branch (stable), where tags for stable versions would be done. As described earlier, this resulted in a “messy” history, with two parallel branches of commits in the history : one with the actual work/commits being done, and one where things were merged, and tagged.

This looked bad, but because I had consistently done it the same way, it was easy enough to fix it. It always went like so :

  • commit 1 : [master] some work
  • commit 2 : [stable, tagged] merge latest
  • commit 3 : [stable] add tag (to commit 2)
  • commit 4 : [master] more work

So all I had to do was, when dealing with a commit being the result of a merge, check if it was tagged. If so, in addition to “ignoring” commit 3 (and using its info for the annotated tag), simply have the tag applied to commit 1 instead of commit 2.

This worked well, and while all the “commit 2-s” were still being added to git, they would all go away since their branch wasn’t used in any way. I only had to manually delete the branch stable to make it all proper, and then re-create it pointing to the right commit (last tagged one).

And with that, I ended up with a “clean”, linear history in git. Success!

kalu is now using GIT

Now kalu is now using a git repo (with a nice linear history), hosted on github. And for those interested/curious, my fork of fast-export is also available on github, in branch annotated-tags.

September 1, 2012
A couple of plugins for WeeChat

When I moved to Linux, I looked for an IRC client. Originally, I wanted/looked for a GUI one, probably because coming from Windows I’m used to GUI applications.

Soon enough it looked like I wouldn’t be able to find a client that would fit my needs, so I tried CLI clients, and eventually found WeeChat. It’s a great client, does lots of things by itself, but also has scripting support to extend things even further.

Still, as I started to use it more and more, there were a few things I needed that I couldn’t find scripts for. Probably, the easiest way to add them would have been to write such a script, either in perl, python, or any of the other languages supported by WeeChat.

Instead, I went with C plugins. The only reason, to be fair, is that I don’t know anything about any of the (many) script languages supported by WeeChat, while I had been doing some C for a little while. So it was easier/faster for me to do so, is all.

weenick: Provides support for common NickServ operations

First of all, since I use registered nicks of a few networks, I wanted to be identified automatically. This could be done by a simple command triggered upon connection, but I also wanted that on reconnection the command to kill the ghost, the change of nick & do the identification all be done without me having to do anything. Laziness is strong with me. :)

weenick should handle all of that, and you can also define command(s) to be executed once identified.

It is configured through options under var.plugins.weenick.server_default.SETTING for “global” values, which will be used (as fallback) on all servers. You can also define options under var.plugins.server.SERVER.SETTING for settings to be used on server SERVER only.

The options are :

  • nick : your (registered) nickname. When defined, weenick will try to use that nick upon connection (in case WeeChat used another one). If the nick is already in use, killing the ghost will be triggered.

  • password : your password, to identify/kill ghost with services

  • command : command(s) to get processed upon identification

  • nickserv_nick : nickname to send messages to. Default: NickServ

  • nickserv_registered : string to identify notice that nick is registered Default: nickname is registered

  • nickserv_ghost_killed : string to identify notice that ghost was killed Default: ghost with your nick has been killed

  • nickserv_identified : string to identify notice that nick was identified Default: password accepted

  • nickserv_failed : string to identify notice that password is wrong Default: access denied

The nickserv_* options are there because not all servers uses the same strings for each case (starting with servers in another language than English, I guess).

(Of course, a match must happen in a NOTICE from NickServ (or whatever is specified as nickserv_nick) for it to be effective.)

Going over this, I realized the actual commands to kill ghost or identify are hard-coded, which probably isn’t the best. Hopefully all services use the same, specifically: /msg <nickserv> GHOST <nick> <password> and /msg <nickserv> IDENTIFY <password>

(Registering your nick with services is all up to you, btw.)

weereact: Triggers commands in reaction to messages

Another thing I was after, was a way to have commands be triggered automatically in reaction to something that was said in a channel. Sort of a bot-like behavior, if you will.

weereact will allow to do just that: you can define “triggers” that will filter messages, and trigger the specified command(s) for each match.

Messages can be filtered by server, channel, user and content (through perl-compatible regular expression).

All configuration must be done in file weereact.conf in WeeChat’s working directory (e.g. ~/.weechat). There’s no interface, you need to manually edit the file in your favorite editor, and can use the /reload command to have weereact reload its config from the file.

Syntax in that file is pretty basic: Empty lines and lines starting with # are ignored; otherwise the format is simply: key=value

To start a new trigger definition, use the following on a new line: []

Options (keys) can be used to filter on which messages should the actions be triggered, as well as define said actions.

  • on : name of the server the message must be sent on

  • to : name of the channel (with #) or nick for PMs. For PMs send to yourself/you’re receiving, use: to=-

  • by : name of the sender of the message. For messages you’re sending, use: by=-

  • is : perl-compatible regex to filter the message.

  • do : command to be executed when a message matches. You can specify this option as many as times as you need. In addition to the back-references from the regex in is, you can also use the following variables:

  • $on : name of the server
  • $to : name of the #channel/nick the message is sent to
  • $by : name of the sender (only available if you’re not sending the message)

New command: /tobuffer

One last thing this plugin does, is introduce a new command - /tobuffer - which can be used to send text (or commands) to a specific buffer.

It’s very possible you don’t need it for most things, since you can e.g. specify a server & channel with /msg for instance, but I needed to send text/command to plugin buffers (i.e. not IRC channel/privates).

Also, I’m not sure there’s a way, from such a command, to do a /me does nothing Although you wouldn’t need to use /tobuffer for that, if that needed to happen in the channel/private where the original message occured, as by default all text/commands sent by weereact are done to the buffer of the original message, IOW in the same channel/private as the original message.

Downloads and whatnot

weeplugins is released under GNU GPL v3+ The source code is available on this BitBucket repository, where bugs/suggestions can be added to the issue tracker.

Arch Linux users can also use the PKGBUILD in the AUR, which grabs the latest code from the GIT repo.

And of course, as always, new bug reports, suggestions or any other form of constructive criticism is very much welcome.

August 11, 2012
kalu now usable from CLI (1.1.0 released)

A new version of kalu - upgrade notifier for Arch Linux - has been released.

Two main changes with this version. Firstly, the addition of two command-line options - --manual-checks (-m) and --auto-checks (-a) - to run manual/auto checks from command line. No GUI will be used at all, everything gets printed on stderr/stdout (using the same templates as for notifications).

This can be done without the need for a DISPLAY/running X server (i.e. no GTK init performed), thus works from a tty or through SSH. This can also be useful to use kalu from scripts.

Alongside those options is a configure option (--disable-gui) to make kalu a small CLI-only binary (i.e. no dependency to GTK nor libnotify), which could be useful on GUIless box (e.g. servers), where kalu can then still be used to check for upgrades, watched packages, etc

(Running this CLI kalu without arguments will do the same as using --manual-checks)

And then, there were improvments & fixes on the news parser, mainly with support for links. As expected, links will now be in blue & underlined, the URL available as tooltip, and clicking it will open it in your default browser.

Opening the URL is actually done via xdg-open Although I just realized, right after uploading the new version to the AUR in fact, that this wasn’t really the best way to go.

A better solution than hardcoding the use of xdg-open would be to introduce a new option, and that’s what I did. The code is already done, though it’s not in this version. But next version will also use xdg-open by default, but let you change it to whatever replacement you use, or even your web browser directly. Up to you.

(So if you don’t have xdg-utils on your system and don’t want to install it just for kalu, but want to be able to click on links, you can download the code from the repo (branch default) and you’ll then have the option available (under Misc).)

Downloads and whatnot

Thanks to all those who reported bugs or suggested features.

kalu is released under GNU GPL v3+ The source code is available on this BitBucket repository, where bugs/suggestions can be added to the issue tracker.

The release tarball can be downloaded here; You can also find a PKGBUILD in the AUR.

And of course, as always, new bug reports, suggestions or any other form of constructive criticism is very much welcome.

June 21, 2012
dapper 0.1.2 released

As I explained before, I don’t use a session manager, and when I needed something to take care of handling the autostart of Desktop applications for me, and couldn’t find anything what I wanted, I made dapper.

Until now it only followed the FreeDesktop specifications, that is started things according to .desktop files found in user & system autostart folders. In that order, in fact.

Version 0.1.2 now works differently, introducing options allowing you to decide which folders should be processed :

--system-dirs to process system (XDG_CONFIG_DIRS) autostart folders

--user-dir to process user (XDG_CONFIG_HOME) autostart folder

--extra-dir PATH to process the specified PATH (not an autostart subfolder)

Bonus: process will happen in the same order the options were specified.

This turns out to be pretty useful to me, because I really don’t like to have thing autostarted when I open a new session, I like things to stay fast & clean.

(So I’m all for pulse or the PolicyKit agent to be started, but not much else, for instance. That’s done with a clean ~/.config/autostart and dapper -su on session openning)

However, I do start a few of the same applications every single time : web browser, file manager, e-mail reader, kalu, etc

So now, I just made myself a new folder (~/.local/autostart) where I put symlinks to .desktop files of those very applications. And when I want to start it all, instead of doing it manually for each of them, I just start dapper -e ~/.local/autostart and voilĂ !

Note: dapper doesn’t actually resolve the tilde (~) to your home folder. That is if you were, as I did, to create a .desktop file to start this in a single click on a menu item, make sure to specify the full actual path, e.g: dapper -e /home/jjacky/.local/autostart

Also worth mentionning a few bugs have been fixed, notably dapper would crash if the config file couldn’t be opened, or a folder to be processed did not exist (fixed in 0.1.1); and parsing fields was actually quite buggy/not working (fixed in 0.1.2).


dapper is released under GNU GPL v3+ The source code is available on this BitBucket repository, where the issue tracker welcomes bugs/suggestions.

The release tarball can be downloaded here; and Arch Linux users can use the PKGBUILD in the AUR.

June 1, 2012
dapper, a desktop applications autostarter

A little while ago, XFCE released a new version, 4.10, and with it a few changes were introduced. Amongst which is the moving of the starting script (startxfce4), which used to belong to xfce4-util, a package that no longer exists.

So the script got moved to xfce4-session, which is a little problem for me because I don’t have that one installed, and I don’t want to install it. It’s possible I don’t know exactly all that a session manager has to offer, but as far as I know what it would provide me is the ability to shutdown/restart the computer from XFCE, which I don’t care for since I can/would rather do it from my login shell, or restart whatever applications were running last time I logged out, something I absolutely don’t want at all.

So, I don’t use a session manager. But because startxfce4 moved to that package, I needed to do something. The easiest thing would have obviously been to just copy that file and keep using it, outside of any packages.

But I wasn’t too inclined to do so, because this script does quite a few things, or tries to do them at least, and I figured if I make it my own and need to maintain it, I might as well keep things as simple as possible.

One thing this script did, although not very well, was take care of the autostarting of desktop applications. I say not very well, because it would only look in one folder for .desktop files, thus ignoring quite a few things.

This resulted in things not being autostarted for me (e.g. the PolicyKit authentication agent) unless I manually added it.

A Desktop Applications Autostarter

So I started looking for a simple application autostarter, one that would do just that: as per the FreeDesktop specifications, look up for .desktop files in the different folders, and start whatever needs to be started.

Unfortunately I couldn’t find what I was looking for, and that’s how dapper was born. dapper does just that, nothing else, and tries to follow the FreeDesktop specifictions.

I say “tries to,” only because there are a couple things not implemented (because I don’t have a need for them, and am lazy) :

  • Keys StartupNotify and StartupWMClass are not supported.

  • When parsing command line in Exec, field code %c is not supported, and simply removed.

Other than that it will start all that should be started pretty fast, and you can define which desktop to start applications for (e.g. GNOME, XFCE, etc) in configuration file (~/.config/dapper.conf) or from command line.


Maybe this might be useful to some of you, though note that autostarting desktop applications is probably already taken care of if you do use a desktop environment/session manager.

dapper is released under GNU GPL v3+ The source code is available on this BitBucket repository.

You can also find a PKGBUILD in the AUR.

And of course bug reports, suggestions or any other form of constructive criticism is very much welcome.

Liked posts on Tumblr: More liked posts »