Author: James Henstridge

malcolm: I believe “en_SE” is the language code you are after, although google seems to use xx-bork.

Started working on the python bindings for gimp 1.3. It has been a long time since I had done much with that code (a lot of the code hadn’t been changed in 3 years), and it was a bit embarassing to see how bad some of it was …

I now have it mostly working, and updated to take advantage of new Python 2.2 features (given that pygtk for gtk 2.0 uses Python 2.2, there was no point in artificially limiting what constructs to use). Now I am using new style classes for all the various gimp objects (which means that issubclass(gimp.Layer, gimp.Drawable) is now true). It is almost at a stage where it could be added to the main tarball builds of gimp.

Put out new releases of pygtk and gnome-python for GTK 1.2 and 2.0. The new releases support parallel install in the same installation of Python. The new pygtk-1.99.13 release also includes the patches necessary to build out of the box on windows.

Also updated the generated pygtk documentation. This version includes the documentation for Boxed and Pointer types, adds a class synopsis at the start of each section, and a full class heirachy at the beginning. Hopefully they will be a bit more useful for people now. I also customised the xml to html stylesheets to generate a .devhelp file, which means that I can browse the documentation in DevHelp.

On Sunday, the white of my right eye was almost completely red, which was a bit of a shock. I went to the doctor on Monday, who didn’t know what the problem was exactly, so prescribed some prednisolone eye drops. They seem to be working okay, and the red has retreated to just one side of the pupil, and will hopefully be gone in a day or too, which is a relief.

Got the nautilus view up and running. A number of pictures of an early version are at:

• Information page
• Files page
• Provides and Requires page

In the current version, provides and requires have been split onto separate pages (and I added conflicts and obsoletes), and they are only visible if there is anything to show. There is also a changelog page for information about development of the package.

I added support for looking at info about package files on disk (as opposed to info about installed packages), which didn’t take much code.

I turned off the feature where it tries to resolve “requires” or “provides” resources (so you could see which packages provided the resources the current one requires, and what packages depend on it). I just need to add some code to follow these deps on demand …

linux.conf.au

The call for papers is almost over. If you want to speak, please send in your abstracts soon.

GNOME

I started writing up some code to add RPM support to Nautilus. At the moment, I just have a simple GNOME VFS module that allows you to see what packages are on the system. You can see a sample of what it looks like here. The package sizes represent the installed size of the package (as reported in the RPM database), and the modification times are the installation times of the packages.

I still need to write some code so that you can view information about the package (probably as a nautilus view), and some utilities for installing and removing packages (these will probably be separate applications, which should cut down on the problems I ran into when writing GnoRPM. When it is finished, it should be pretty useful.

One of the annoying problems with libtool is the way the -export-symbols and -export-symbols-regex. The flags are supposed to limit which symbols in the library are available to programs that dynamically link to the library.

Unfortunately, the feature is not implemented correctly for many platforms. Rather than leaving symbols out of the dynamic symbol table, it just removes debugging information for the non-exported symbols (so not only does it not work, it also makes your code harder to debug …).

So I put together a simple patch to fix the problem. At the moment, it only changes the behaviour under Linux as I can’t verify whether it works correctly in the other cases (it probably does though). If anyone wants to try the patch, it is available at:

http://www.daa.com.au/~james/files/libtool.m4.patch

I wonder if libtool will make a new release any time soon?

sej: that sounds a lot more like the NPL than the MPL. The MPL does not give any special privileges to Netscape, the only mention of Netscape in the license is that they may publish new versions of the licence, similar to GPL.

In fact, the license policy states that new original code should be licenced under MPL/GPL/LGPL tripple license. I am not quite sure why an LGPL rendering library (such as the LGPL portions of raph‘s libart) should be a problem — such a license sounds consistant with the license policy for “new non-original source files”.

Wrote a short Samba patch to fix up display of the print queue when using the version of LPRng that came with RH7.3 as a print spooler. One of the new features in that version of LPRng was that it leaves one or two jobs in the print queue marked as done (apparently this was done for accounting purposes).

Unfortunately, Samba was not expecting to see jobs marked as “done” (it assumed that jobs marked “active” were being printed, jobs with a numeric rank were queued, and all other jobs were paused). This was causing a lot of confusion at the office, as Windows would not realise that print jobs had completed.

It was fairly trivial to find out what to patch in the Samba source code to fix this, so in about 20 minutes I had things up and running, and the complaints went away. It was much easier to find the correct part of the code to patch than with some other programs I have had to make modifications to.

PyGTK

In my last diary entry, I talked a bit about how long delays between releases of a package can hurt. It has been almost 2 months since the last 1.99.x snapshot of PyGTK. I will look at putting out a new release tonight after applying Arjan’s closure cyclic garbage collection patch and fixing a tree bug jrb pointed out.

A lot has changed since the last release, so it would be good to get people trying out the new version. It is probably possible to implement proper widgets now, which is a big milestone.

After the release, I will look at implementing some nicer ways to use list store and tree stores:

• len(liststore) should return the number of elements in the list.
• liststore[index] or treestore[treepath] should return an object representing the row. getting and setting indices on the row should get/set the appropriate values in the tree.
• iter(liststore) should return an iterator that returns instances of the above row objects. Haven’t thought about iterating over tree stores.

These should help make the new tree widget feel more python-like, which is helpful.

tromey: I have found automake to be a very useful tool over the years, especially when you take its constraints into account (portable make, shell, etc). Within the GNOME community, my biggest problem has been having to explain myself every time I use a feature not found in 1.4.

Many of the hackers are not even looking at the recent 1.6 releases because their packages break with them. The irony is that the parts of their Makefile.am‘s that break are usually work arounds for bugs or defficiencies in automake 1.4 (many of which have been addressed in 1.6). It is depressing to hear people complaining about bugs in old automake while refusing to upgrade (and this is for bleeding edge gnome development; not maintenance branches of the various packages).

I believe part of the reason for this is the large gap in time between the 1.4 release and 1.5/1.6 (about 2 years, IIRC). People grew too used to all the quirks and bugs in 1.4 that when they got fixed, people started complaining about it. With more frequent releases, these bugs would probably have been recognised as such, rather than features.

Another project that could do with another release is libtool. There are a number of known bugs in the 1.4.2 release (such as not being able to do a buildroot install, which really hurts packaging), and a few more architectures are supported in CVS. Putting out a new maintenance release would be a _really_ good idea.

Overall, the new autoconf and automake releases are a lot nicer to work with, compared to the 2.13/1.4 combo.