Tinderbox 3 building Gnome

Here in Igalia we’re very interested in some aspects of software quality, and in special in continuous integration. We’re very used to have continuous integration services for our projects, as one of the fundamentals to be handle a group of programmers accessing the same repository.

For doing this, we’ve used three different continuous integration servers, depending on the project:

  • Tinderbox2, for Gnome technologies based projects. For example, you can see our Fisterra tinderbox, running compilations every two hours of our middleware.
  • Cruisecontrol, for Java/PHP web based projects.
  • Tinderbox3, the one I’m working on these days.

As a result of the petition in Gnome Love list for a tinderbox we started an effort to adapt Tinderbox to Jhbuild, and run modulesets inside. It led to two parallel works, one with Tinderbox2 and one with Tinderbox3. Meanwhile, BxLUG has done some work in the same direction, which you can view in the Gnome JhAutobuild webpage.

The Tinderbox2 work was done easily. You can check the current experimental status of the portal in our Tinderbox2 based Gnome Tinderbox. We are integrating unit tests and coverage in it, and we’ve also added RSS feeds for the modules (see here).

And now I’m working in a Tinderbox 3 setup. As the T2 one, it’s experimental. You can check it in our Gnome Tinderbox3 webpage. I’m tweaking and hacking this days, so it’s changing fast. Some features are:

  • A wonderful show all builds view, containing the last compilations of all modules in a time line.
  • Rss feeds for every module, and one for all the trees. With them you can subscribe to the last compilation failures.
  • SSL enabled client and server. The comunications in Tinderbox3 are done through HTTP/HTTPS, making easy to do a secure configuration of clients.
  • The compilation clients detect the modules containing a make check rule in Makefile, and runs the tests. As in Tinderbox pure tradition, you can see the modules failing in unit tests stage as orange.

I would like to share this effort with community. Related to this, a BOF will be held in GUADEC 2006 next week in Vilanova. There’s more information about the continuous integration BOF in GUADEC webpage. It will be on next Thursday 29 at 12:00. See you there!

Let’s kill the templates in gtk-doc

Once upon a time, there was gtk-doc. It was weird and strange, and overall, different from other standards like javadoc or doxygen. But we gnomish people, were tied to it, as it was the only one working correctly with GtkObject/GObject. It’s still this way, as I don’t know any good solution with Doxygen or other tool to fill the space of gtk-doc.

Why it was weird? For me, the worst point was the need to maintain a set of files called templates. They were docbook templates that covered some documentation that you couldn’t add to your source code. These files were processed by some scripts that didn’t work very well with version control systems.

With gtk-doc 1.5 we can avoid the templates, at least for most of the use cases they were required. Now you can add to the source code a commentary like this one:

/**
* SECTION:myclassname
* @short_description: This is my short description for #MyClassName
* @see_also: #Other, #AnyOtherOne
*
* It's a long description about this and that, and other things. You can write
* about many things and enter sgml tags like:
* <itemizedlist><listitem>an itemized list</listitem><itemizedlist>
*/

With this structure you remove at last the templates requirement. One additional note. As there was a bug in gtk-doc 1.5, the general makefile scripts provided don’t work with no templates. You have to add a rule to the documentation Makefile.am like this:

tmpl/*.sgml: scan-build.stamp

Another interesting point is using gtk-doc.make. It’s a script provided by the gtk-doc distribution providing general structure for gtk-doc processing. You can use it adding this line to the Makefile.am:

include $(top_srcdir)/gtk-doc.make

latex-make enters debian

For all of you folks that always complain about how difficult it is to create latex documents with those complex Makefiles compiling figures, linking eps’s, doing bad works to generate pdf or ps automatically, latex-make is here.

It’s a makefile include file to help you compile and track dependencies of a latex document. For example, if you want to compile a latex-only document (of one or more files), you only have to create a Makefile with one line. Imagine the master tex file is called mydocument.tex. Then you would write a Makefile with two lines like this:

LU_MASTERS=mydocument.tex

include LaTeX.mk

If you want to state which kind of outputs you want it to compile by default, you only have to state the flavors (PS, DVIPDF and/or PDF):

FLAVORS=DVIPDF

And about the figures. If you have the figures of your document in figures directory, you only have to add:

LU_mydocument_GPATH=figures

There are more interesting points. It adds a module to handle .fig files and bibliographies.

GtkNotebook and Dogtail

This week I’ve been hacking a while around Dogtail. It’s a Python library intended for implementation of functional tests of applications providing accessibility support through AT-SPI. It lets you check and manipulate the user interface from Python scripts, and it’s easy to integrate it into test cases.

While I was working, I found that I could not easily browse tabs in a GtkNotebook using dogtail. This issue has been reported in Gnome bugzilla (bug report). The problem is:

  • Dogtail uses Python SPI bindings (in project pyspi) to access the accessibility layer. This bindings are a direct wrapper over CSPI.
  • GtkNotebook accessibility implementation has the page tab list role, and the tabs have the page tab role. The notebook exposes the currently selected tab through the Selection interface. It lets you specify a selection of children of an accessible container.
  • Unfortunately neither Python SPI bindings nor Dogtail provide support for this. Then it’s not easy to change the currently active tab of a notebook.

I’m not the only one that has detected the problem this way. Peter Johanson has sent two bugs and patches to solve the issue and add tab browsing support in Dogtail (report in Pyspi and report in Dogtail). In parallel I was developing similar patches. As Peter Johansons’ are more complete, I’ve simply added some functionalities this morning to the dogtail patch to provide an easier way to use the selection interface in Dogtail. I’ve uploaded the new patch to the Dogtail bug report.

Now you can simply write:

focus.application('gedit')
focus.widget(roleName='page tab', name='My tab')
focus.widget.node.select()

And it raises the desired tab easily. Hope those patches go upstream. I think they're a good solution for the tab browsing issue.

DBUS and the power and network managers

Some time ago, in the Guadec-es in Coruña, there was an interesting meeting to talk about interesting enhancement in Gnome desktop. It was mainly centered in i18n issues, but I talked about the way other platforms work in network APIs.

Briefly, I missed a way to know about network status and manage connections, as other platforms do (for example, we get this kind of API in Microsoft Windows related SDK with Connection Manager API. The same applies to power management.

But now there’s an interesting work to face this issue. If Network manager and Power manager DBUS message providers get more or less standarised in Linux distros, we’ll get an standard API to do this kind of use cases:

  • Know if we’re connected to the internet
  • Bring up the default network connection to the internet if it’s shut down. (Useful for devices like palms or mobile phones or even PC’s with analog modem internet). Maybe with a standard dialog in Gnome.
  • Some knowledge about the network status.
  • Know if the PC or device is plugged, and then decide if our application wants to save power or not.

It seems these managers, and their use of DBUS, are the way to go. Good luck!