GIMP Manual Build Architecture Status
GIMP Help Browser using webkit.
We’re currently in a huge overhaul of the build system the GIMP Manual is using (see my last post).
Ulf D. Ehlert works on a custom Makefile, which can extract the strings, creates automatically pot files, as well as po files and is able to create localized DocBook/XML. He’s still working hard to improve the script. Thanks to publican – it helped to reuse some of the Makefile code the project provides to create pot and po files automatically (I still need to communicate that with the publican folks – sorry guys).
I hope we can merge his changes as soon as possible with a current xml2po branch to test it. Hopefully other developers around will help to improve the Makefile.
We’ve still performance issues. Creating the HTML pages for the translations takes ages, and it will take more when we switch to support gettext.
GIMP Metadata Browser
Current GIMP metadata implementation showing XMP metadata of a sample image.
There was long silence about the Metadata Browser in GIMP. I’m currently trying to picking up the code which seems to float around since 2002. Raphaël Quinet worked on the metadata system for GIMP. There is an Extensible Metadata Platform (XMP) parser, code for reading EXIF data and a UI for browsing metadata. But overall not finished, unfortunately. The development stopped, because of the lack of time to work on it.
I’m trying now to change that. I currently do have a lot of time to work on it and I’m eager to polish my C/C++ skills. Currently I’m reading the code, trying to understand what it does and also reading the XMP spec published by Adobe. I even had a look at exempi, which seems to be the parser you want to use parsing metadata for binary files.
The plan
The current plan is to provide a read only view for the metadata attached to the image including XMP and EXIF metadata (similar as shown in the screenshot). Plain EXIF data is currently not displayed in the metadata browser. It needs to be converted to XMP:exif metadata and merged with the XMP data already found in the image data. That’s my part I’m currently trying to implement.
Team-Triathlon
Me and myself running uphill to the next checkpoint. Photo made by S. Wehrmann.
gocept managed to provide two teams for a team triathlon in the southern part of Sachsony Anhalt, named Rossbach an der Hasse. Our teams made it on the 97th and 100th place (of 129 starters). The triathlon was fun to do. The first placements were divided by the professionals. A big part of the whole time was determined by the bikes and most professionals with their hyper-carbon-super-airy-expensive-like-ass sport bikes.
I’m very satisfied with my standings (swam 13.15min for 750m, placed 37th). Sebastian Wehrman, one of my team collegues did a 26mins run. Well done!
I’m actually looking for another event like this. Though I’d like to cut out the bike part. I don’t own a sport bike and don’t want to throw a huge amount at the materials. Maybe an Aquatlon will be the next thing to do.
Tags: Triathlon, Merseburg, Braunsbetria
GIMP Help Browser Hacking
It was a long time in the train yesterday and I started to hack on the help browser dialog. I never thought that it can be so much fun. I even got to some point and added type ahead search. Not a big deal for an experienced C programmer, but a feeling of success for myself. I want to finish that feature (needs some work), though a global search feature would be more helpful for the user 
Well, maybe that’s the next thing?
GIMP Manual Future Decisions
GIMP Help Browser using webkit.
Help Browser Improvements
I’m very happy about Svens changes for the next stable version of GIMP (2.6). The help browser uses now webkit to render the manual and can even now load the manual from the net if the user have an internet connection. I think that’ll make the access to our manual more easier for the most of GIMP users.
Manual switches to gettext
The user manual is written using DocBook/XML. The translation is seperated by ‘lang’ attributes. There is no reference language. Therefore the manual is written in various languages, seperated by ‘lang’ attributes.
We’re currently working hard to figure out a possible migration strategy of the current manual to gettext. Our build system need to be customized to manage the translations hold in *.po files. There are currently two possible candidates for this:
Publican provides a lot of the functionality we need to update/manage the translations. So has a very specific purpose. It uses the automake/autotool build system, we’re using as well. It is written by people at Red-Hat and can compile hundreds of manuals in the row. Ulf D. Ehlert and I elaborated a possible migration to publican and we figured a few pros and cons:
Pro:
- provides all the functionality needed to manage and build documentation using gettext
Contra:
- complete switch to Publican and be dependant from it
- feels like we won’t need most of the functionality implemented to compile all (other manuals)
WAF though is a build system written in Python. It’s ment to replace the currently widely automake/autotools toolchain, which is currently widely in use by a lot of open source projects.
Pro:
- It’s easier to understand and can better handle the complex process of building and installing our manual. I find it sometimes very cumbersome to express what the autotools/automake should do using bash expressions. I find it much easier to do this in Python or any other high level language than bash (don’t misunderstand me: bash is fine for batch processing).
Contra:
- WAF uses tools to provide configuring/building software. There seems to be no such tool available which provides the functionality to build our manual. We probably need to write our own tool. Not a problem though, but we need to do it and it will cost time.
- “Not compatible” to our GIMP/GNOME (modules) which use automake/autotools.
I will try to write a build script for our purpose using WAF and I also want to communicate more with the publican people. I think this will sort out our current “problems” choosing a system.
Well, could be, that I overlooked or misunderstood something elaborating those tools. I’m sorry if something is not correct, while I was checking.
Update: Ulf sent me already a patch based on autotools/automake, which uses a bit of the publican infrustructure. Think that points out the direction where we’re heading now
Evil has a name: bicycle
While I was sitting in my train back home, I heard the train driver pestering about the bikes, which you’re allowed to bring free in the train:
“Too many bikes in the train. They [the Bahn managers; note from the editor] should introduce a fee for the bikes and the amount of bikes in the train will drop. The bikes are a big problem.”
I do have a better proposal to make: Raise the ticket prizes extraordinary, so that no one can affort taking the train. I’m pretty sure, that this not only solves the bike problem, it will also solve the issues with the customers 
They even demand service for they money – unbelievable.
