The download manager is in the wild

So it's finally done, it took very long, but it's done. The download manager I once had in mind is taking off into the wildness :-) Of course it took long because I never did something with it, writing a front-end to wget/curl isn't interesting -- who cares about downloading HTTP/FTP files when the web browser handles it for you anyway -- and reusing GVFS doesn't make sense cause really you don't want to download from your trash:// or whatever proto:// and again only HTTP/FTP is not interesting. Not at all. I have come across Uget and other very good projects but most of them are either writing the code to handle the protocol like HTTP and/or are looking forward to handle more interesting protocols like BitTorrent. I think it's a very tough job that demands too much for a one-maintainer project. Recently I saw the new release of aria2 that comes with an XML-RPC interface and this took all my interest during 4 days. I believe this utility is very promising and I had really like to write the good and user-friendly XML-RPC GUI client that it seems to be missing!

What is so exciting about aria2? In case you know the project you don't have to read, but it is worth mentionning the features of this small utility. It supports HTTP(s)/FTP but also BitTorrent and Metalinks. It is widely customizable for each specific protocol. It can download one file by splitting it into several pieces and using multiple connections and even mix HTTP URIs with BitTorrent and by the same time upload to BitTorrent peers what has been downloaded through HTTP. So this has to be the perfect candidate to write a nice download manager, hasn't it?

The client is a very first version that I intended to code name draft although the release assistant on xfce.org doesn't allow this. Instead it will take the more neutral road of 0.1.0 to 0.1.1 etc until 0.2.0 followed by stable fix releases.

Why draft? Simple. It's being written with a higher level language than C but not even Vala :-) High-level languages are a great deal when starting a new application, as you can type more and get more, instead of typing like a dog for a rocking hot, well lousy, window. Since I do like Ruby, it's being written in Ruby currently, and it depends on the ruby-gnome2 project for the bindings. To get a picture, a main file to open a window takes 3 lines. Of course the final version is meant to be written in Vala/C, but I still need to convince myself that Vala+libsoup isn't an option that is going to waste too much time. Also at first glance libsoup looks easy to use, it allows to build XML-RPC requests, to request the HTTP bodies and to send messages, but it is not an XML-RPC client and you never know how well the Vala bindings will play. This means extra attention for small things. Starting an application from scratch with such constraints are usually a big time-killer therefore using like in this case an existing XML-RPC client is very important. The GUI is done with Glade in GtkBuilder format and reusing it into a new language will be pretty easy.


So what's next? I'll just wait for some feedback see what the audience thinks about it, if at all, and polish here and there. Keep tuned for the next update.

Messing up with Vala (again)

First some good news. I didn't look close enough into the possibilities offered by Automake 1.11 when I first wrote the post about building Vala projects. Automake 1.11 is all about making releases without the end-users having to compile Vala! Just like it is written in the Automake documentation. From now on I will always apply this wherever it is possible.

I updated the Xfce4 Vala bindings with libraries from the 4.7 stack. In there I have updated the panel plugin example, and as you can see the Automake file is extremely short. When there is a SOURCES defined with a Vala file, Automake will create targets for each compiled program or library with Vala compilation, and generate one vala.stamp file per target. This has its pros and cons. In the case of the Notes plugin, this disallowed me to have a mix of only C written software and Vala inside the same directory. In reality I used to have a single main file for the panel plugin to compile to C either for the 4.7 version or prior. Automake makes the Vala specific targets visible outside the scope of the "if PANEL47 ... else ... end" block. I ended up with self-compiled Vala for each target in maintainer mode only, as previously, which is a small overhead for the specific targets.

Other nice thing about Vala is that bindings are just files. I compiled the Notes plugin for the Xfce 4.6 panel on my netbook just to verify everything is alright but unfortunately there were some problems. I bumped the required version of Vala to 0.7.8 which has GTK+ bindings for 2.18 already while I only have GTK+ 2.16 available. The simple thing to do was to download the GTK+ bindings from the version of Vala I used previously and copy them into a location of the project (or system wide).  As long as the Vala compiler knows where to pick them up (with "--vapidir=") it will choose them and not the ones provided by default. This makes it awesomely easy to provide customized bindings for example.

Vala can always be very time consuming, but I still like it! Just like git merge by the way.

Console keyboard layout and beep

Two quite annoying bits to remember so lets blog 'hem. Under a tty the keyboard may have a bad layout, I know perfectly changing it under X with setxkbmap but I usually Google for the console. The answer is loadkeys. Running loadkeys -d will print the current map file that gives an idea where to find the maps. Switching the map works like loadkeys /lib/kbd/keymaps/.../fr-latin1.map.gz, in other words just pass the map file. Now to come to the other annoying command to remember is the ability to cut off the beep. It works with setterm -blength 0.

Update: passing the locale directly to loadkeys works (thanks Boris), neither the help output nor the man page mentions this.

Fast Python debugging with Vim

So I just needed to test some lines of Gtk+ code and preferably with Python. I love the interpreter (just as well as irb) but debugging even small Gtk+ pieces is not very attractive in the end. Therefore I jumped into Vim, typed my small script, and then executed the command ":%!python -". Only problem is that after the command exits it replaces the content of the Vim buffer with the console output that contains Python debugging messages as well, a quick press on "u" reverts this but maybe there is a cleaner way.

MP3 support on Moblin (part 2)

Part 1 showed the easy way. Now the hard way to get MP3 support is to provide it yourself by building plugins for GStreamer. Having an RPM build environment is a prerequesite. The earlier blog entry shows how to set it up and also has an example to build and install libmad which will be useful in this example and I won't repeat it here.

Download the gstreamer-plugins-ugly source package. Put it inside the SRPMS directory and run the rpm -i command on it to unarchive its content.

Open a text editor and edit the spec file available under SPECS. The package names vary between Moblin, Fedora and RPM Fusion and this needs to be fixed in the header. And in this example only the plugin libmad will be build so that's why many lines will be commented. In fact the only build dependencies will be libmad, libid3tag and liboil. I have put the diff on Snipt. To apply it use the patch command like patch -p0 < gstreamer-plugins-ugly.spec.diff. Don't miss the patch(1) man page to know about the -p option.

Now build binary packages with the command rpmbuild -bb SPECS/gstreamer-plugins-ugly.spec. Wait a minute and you should have a ready to install gst-plugins-ugly package within the RPMS directory.

You can more or less repeat this task for DivX and other video codecs support. For that you'll have to build the GStreamer FFmpeg plugin (gstreamer-ffmpeg source package). Of course FFmpeg depends on many many libraries and you'll have to build them at first.

Update: Regarding FFmpeg, it can be build from the RPM source package without external requirements, in fact it doesn't have any hard dependencies. Or you can even compile the gstreamer-ffmpeg plugin only with the internal FFmpeg sources since it is optionaly linked to an external FFmpeg library. In both cases the provided SPEC files have to be modified.

RPM build environment on Moblin

I once set up an RPM build environment on my netbook to build missing packages, often small tools. There are many docs to do that, for myself I browsed the Fedora project wiki. If you are looking for RPMish stuff you are in the right place there.

Preparation

The package rpmdevtools provides scripts for the packager, one of them is rpmdev-setuptree. This tool will set up automatically the build directory for keeping source packages, spec files, etc. You can run this command now. Within your home, it will create an rpmbuild directory and a hidden .rpmmacros file. You can move the rpmbuild directory where ever you want but you will have to fix the variable %_topdir in the hidden rpmmacros file.

That's already about it.

Build example

Lets take a small example to show the use of the RPM build environment. Download the source package libmad from RPM Fusion. Copy it to the subdirectory SRPMS and then unarchive it with the command rpm -i SRPMS/libmad-[version].src.rpm. And finally you can build the binary packages with the command rpmbuild -bb SPECS/libmad.spec. The rpmbuild command is provided by the rpm-build package.

By now you can install the packages within the subdirectory RPMS, libmad-[version].rpm and the -devel package, if you wish to build the source package madplay to play MP3s from command line :-)

External sources

• Packaging guidelines
• How to create an RPM package
• Fedora Koji
• RPM Fusion