therning.org/ magnus

As I wrote a while back the development version of Metacity now has support for _NET_MOVERESIZE_WINDOW. I’ve just compiled a bleeding edge version checked out of subversion and it’s all working fine. Excellent news for Jendela.

Yesterday I received my GNOME SVN account, and today I made my first two commits for epilicious, 1499 and 1500.

I doubt anyone really noticed but a few weeks ago I retired Jendela due to inactivity in GNOME bug 344521. Without those changes I just couldn’t write the tool I imagined. Since I raised that bug on version 2.14 of Metacity and both 2.16 and 2.18 passed by without the patch applied I didn’t hold much hope of it ever getting anywhere. Lo and behold, the bug is closed, the patch is applied. Excellent news! I’m reviving Jendela

GNOME bug #352082 has been closed and Epilicious is now to be found in GNOME SVN.

A little while ago I wanted to launch an OGG file attached to an email. Since I read email in Mutt and it does such an excellent job of delegating unknown MIME types to external applications I simply pressed v (to see the attachments), selected the OGG attachment and pressed enter. Realplayer launched! Imagine my surprise.

After purging Realplayer from my system I had an idea. Mutt uses mailcap to determine how to deal with MIME types it can’t display, but since I’m using GNOME and it has a different system to deal with MIME types I frequently am surprised when viewing attachments in Mutt. Isn’t there some way of combining the two? Well, I frequently use gnome-open to launch viewers from the command line. But it forks off a new process for the viewer so it can’t be used in mailcapⁱ. I spent some time looking into the inner workings of gnome-open and it might be possible to hack it to add a command line option to make it wait for the viewer to exit. However my quick test using Python suggests that it’d require changes in the underlying librariesⁱⁱ.

From what I learned looking through the implementation of gnome-open I hacked together the following short Python script:

#! /usr/bin/env python

import gnomevfs
import os
import sys

mime_type = gnomevfs.get_mime_type(sys.argv[1])
mime_app = gnomevfs.mime_get_default_application(mime_type)
application = os.popen('whereis %s' % mime_app[2]).readline().split(' ')[1]

os.execl(application, application, sys.argv[1])

Then I added a line to the top of ~/.mailcap:

application/*; ${HOME}/bin/gnopen '%s'; test=test -n "$DISPLAY"

Works like a charm, but of course suggestions/improvement are welcome!

1. It seems Mutt removes the temporary file as soon as the viewer returns, so if gnome-open forks and exits Mutt will delete the file before the actual viewer gets to load it. Bugger.[back]
2. I traced it down to a call to g_spawn_async that should be changed to g_spawn_sync, but that’s deep down in the underbelly of GNOME-VFS.[back]

Jono is complaining about moving Evolution setting between machines. GConf can’t be synched easily between machines. Maybe the GConf diff tool could be a start of a proper synch tool for GConf?

(This is one of many reasons I keep on using mutt and fetchmail+procmail. I can easily keep my configurations in synch.)

After taking some advice I got on #epiphany I’ve finally managed to get both epiphany and epiphany-extensions out of CVS to compile. In this case jhbuild buildone was my friend. I installed gnome-devel and python-gnome2-desktop-dev and set to work.

I used jhbuild to build glib and gtk+ (setting PKG_CONFIG_PATH in between). Then I tackled epiphany from CVS. It gave me no grief at all, though I did forget to enable Python support at first. epiphany-extensions was equally simple.

Finally I can get serious about getting epilicious into GNOME

I started trying to compile GNOME 2.15.4, but as you can read from the comments things didn’t quite work out. After a few emails on the gnome-love mailing list I switched to release 2.15.90.

freetype2

I quickly ran into problems with freetype2. It seems Sid’s version is too new. I added a new moduleset to the regular ones I got off the GNOME site:

<?xml version="1.0"?>
<moduleset>
  <tarball id="freetype2" version="2.1.9">
    <source
      href="http://switch.dl.sourceforge.net/sourceforge/freetype/freetype-2.1.9.tar.bz2"
      md5sum="ec1b903e4be5f073caa72458ea58c29c" size="992394" />
  </tarball>
</moduleset>

I saved it as freetype2-2.15.90.modules. You need to add an include tag in gnome-2.15.90.modules and a dep tag on gontconfig in freedesktop-2.15.90.modules.

gtk+

The next thing that failed was gtk+. It said Pango wasn’t built with support for Cairo. A look at config.log for Pango showed that Cairo wasn’t built with the Xrender backend and a look at Cairo’s config.log and output of ./configure --help showed that it inspected the system during configuration to see what backends it could build. (I have to say I really don’t like that sort of behaviour, I prefer it if all configuration options are explicit. Currently it’s trying to be smart but only ends up screwing the user.) I made sure libxrender-dev was installed and I put a link to /usr/lib/pkgconfig/xrender.pc in ${prefix}/lib/pkgconfig (not strictly necessary for Cairo but it seems the resulting cairo-xlib-xrender.pc depends on xrender.pc so I suspect compiling Pango might need it, no harm in having it there anyway, right?).

dbus-glib

Next dbus-glib failed. It’s a well-known problem and the patch is available. However, it seems it wasn’t applied properly by jhbuild and I still got an error saying that ${prefix}/var/run/system_bus_socket - file doesn't exist. Apply the patch manually, re-run jhbuild, answer no to all questions asked by patch (reversing, apply anyway), then skip the patch stage. That should do it for that package.

firefox

Well, that failed as well and I really can’t figure out why. It seems it doesn’t find my installed X libraries during linking. Very weird indeed. I learnt on IRC (#epiphany) that it probably is easier to use Debian’s libxul-dev package. After installing that, and setting PKG_CONFIG_PATH to include both $prefix/lib/pkgconfig and /usr/lib/pkgconfig (it’s better than linking files like I did earlier).

epiphany

This was the package I really wanted all this time. Here things are failing in new and interesting ways. It seems Debian uses a sligtly non-standard split of xulrunner packages for pkg-config. I needed to stick the following line in m4/gecko.m4:

gecko_cv_extra_pkg_dependencies="${gecko_cv_extra_pkg_dependencies} xulrunner-js"

It goes after the if-statement in the pkg-config area of the file.

Still, that doesn’t make it compile successfully. It seems that my two conflicting freetype2 versions are confusing the build… For now I’m giving up, but I’ll be back with a more targeted build story… I will build epiphany from CVS and live to tell about it!!!

The other day I had some problems early on when trying to compile from GNOME CVS using jhbuild. From a sudden surge in brain activity I got the idea to build a release of the development version of GNOME—the 1.15.x series—the lates one is 2.15.4.

I got some help from Elijah Newren’s post on compiling GNOME with jhbuild. Using the links from the release notice on FootNotes I got as far as

% jhbuild bootstrap

without problems. Then I got stuck:

% jhbuild -m \
> http://ftp.gnome.org/pub/GNOME/teams/releng/2.15.4/gnome-2.15.4.modules  \
> build
jhbuild build: dependent module "libdaemon" not found
usage: jhbuild [ -f config ] command [ options ... ]

My first thought was that installing the Debian package libdaemon0 might solve it. Of course it didn’t. Then I remembered that during bootstrap Python 2.4.3 was downloaded and installed, despite being installed on my system already. Not too much of a surprise then that libdaemon0 didn’t do any good.

After looking at jhbuild modulesets for previous releases as well as the bleeding CVS moduleset I got an idea. I saved the 2.15.4 moduleset locally and modified freedesktop-2.15.4.modules to include the following lines:

<tarball id="libdaemon" version="0.10">
  <source href="http://0pointer.de/lennart/projects/libdaemon/libdaemon-0.10.tar.gz" />
  <branch checkoutdir="libdaemon" module="trunk" repo="libdaemon.0pointer.de"/>
</tarball>

It’s compiling rather happily at the moment so I’m optimistic… I’ll add a note if things go pear-shaped…

I’ve just released version 0.9 of epilicious. A package for Debian has of course also been uploaded to my personal APT repo. Have fun!

Oh yeah! Almost forgot. Translate it, please!