Uncategorised

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.

GNOME

The 2.0 release has come and gone. It managed to take down widget (which serves www.gnome.org, news.gnome.org and bugzilla.gnome.org). Not being able to access my bugs was a bit of a pain.

The new release looks very nice, and GTK 2.0 is a joy to program. I still need to finish off PyGTK 2.0 though. The articles from Dennis E. Powell and Nick Petreley about GNOME 2.0 have been very surprising. DEP’s article was very encouraging and Nick’s one almost promoted GNOME 🙂.

LibEgg

I haven’t done much work on the menu merge code, but have set up gtk-doc to build reference documentation. I configured it to use the new XML support (so gtk-doc generates XML, and xsltproc is used to transform to HTML). Seems to work very nicely.

I also had a small play with conversion to PDF with the xmlto script, which uses the PassiveTeX FO processor. There were only a few minor issues making the conversion difficult. The first was that xmlto wasn’t performing XInclude processing. This was fairly easy to fix (I sent a suggestion to the author to turn this xsltproc option on).

The more serious one was that passivetex didn’t seem to support prortional table column widths, which are used in the gtk-doc output. This shouldn’t be too big a deal, as I could correct this with a stylesheet customisation layer. Lastly, the <synopsis> elements were not being rendered correctly, but I think this was an issue with the (old) version of the XSL stylesheets I was using.

Bugzilla

I did a mockup of a “show/hide advanced options” button for the query form in bugzilla (see the second attachment). It is just some simple javascript that uses a cookie to persist its state. In the simple mode, it just shows the summary search field and the product/component/version/milestone lists. While the new query page layout is a lot better, I know a number of people who are simply put off by the number of available query options (even though they only need use the first few in the new layout). By allowing people to hide the majority of the options, hopefully this complaint will go away.

Been playing with XSLT a bit recently. It is quite a
nice transformation language. I have been porting the gtk-doc
DocBook -> HTML conversion program to use xsltproc (with
a customisation layer over Norman Walsh’s XSL stylesheets),
rather than Jade (with a customisation layer over his DSSSL
stylesheets). Took a little while to learn what I needed,
but the end result looked fairly elegant.

While working on the customisation layer, I even found a
simple bug
in the base stylesheets.

EggMenu

The menu merge code is mostly working now. With some
help from Anders, almost all the menu merge functionality is
working. You can merge and demerge UI files, bind a
particular menu item to a different action, and use
placeholders.

Toolbars are still left to go. I need to work out how to
do the placeholders on toolbars, as the placeholder
implementation for menus makes use of (possibly hidden)
separator menu items before and after the elements within
the placeholder. The separators in GtkToolbar are not
widgets, so I will need to work out some other way to handle it.

linux.conf.au

Preparation for the conference is going well. We are
still waiting for more submissions for the Call for Papers.
If you want to do a talk, please send in a submission!