Guadec has been in interesting conference, particularly because it took place in Istanbul this year. I tried to keep a few notes throughout the days to wrap up the experience and discussions here.

Sunday

Headed off for Istanbul, partial Imendio meet-up at the airport in Vienna, gathered remaining Imendians at the airport in Istanbul. Like many others, we stayed at the Golden Long Hotel near the seaside.

Monday

Kris and I met up with the Gnome release team where we summarized the Gtk+-3.0 ideas that have been cooked up during and after the Berlin Gtk+ Hackfest.

Tuesday

I was planning to attend the Maemo BOF in the morning, but shortly after arriving at the conference venue, Federico literally dragged me into the DVCS BOF. Still, I only managed to attend the second half of it which was almost exclusively about Bazaar features. People told me the first hour had been quite the contrary and focused mostly on Git hyping. Clearly, there was no consensus after the meeting on what the future versioning system in Gnome will be.
I’m not surprised that is the case. As things currently stand, SVN has very active development and user communities, Git is very actively developed, Bazaar is as well, as are a couple other VCSes. Active developer and user communities are generally a good sign for a healthy project and also an indicator for future relevance. Thus, in any larger community such as the Gnome community, it’s easy to find lots of critics and lots of supporters for each of the bigger versioning systems and that’s unlikely to change much. Consequently, there’ll not be an easy consensus on switching to a single versioning system any time soon, so I think the most productive approach for Gnome to take is to prepare the hosting of multiple VCSes, certainly SVN, Git and Bazaar. Needless to say that cross-VCS integration will also become increasingly important in the future, so focus on maturing and extending git-svn, bzr-svn, bzr-git and the like makes a lot of sense.

Later that day, we had a Gtk+ Developers meeting in the medium sized presentation room. The place was a bit too large to have the planned face to face discussions so we’ve had to sacrifice some of the spontaneity to microphone resource sharing. Kris took minutes during the meeting and will probably post those to gtk-devel-list once he’s found a minute to process them. The meeting was quite productive nevertheless, we discussed the upcoming Gtk+ 2.14, features and schedule for 2.16 and 3.0 and a bit of the post-3.0 road map.
Right after that discussion, Kris and I attended the advisory board meeting where we briefly wrapped up the developers meeting, the Gtk+ Hackfest in Berlin and the improvements the Gtk+ project has seen since the State of the Gtk+ Maintenance email. In particular, we stressed that we now have the GtkTasks and Gtk+ 3.0 Tasks wiki pages which can serve as an entry point for contributors and assistants to the project at various experience levels, in particular for companies that want to sponsor developer resources. Also for people that have an interest in long term Gtk+ project involvement, feel free to read up on how to become a Gtk+ maintainer.

Pizza looks weird in Istanbul BTW:

Wednesday

Almost by accident (I was mostly looking for an air conditioned hall in the afternoon), I happened to be watching “Gnome Documentation: A year in review” by Don Scorgie where he described the new user documentation tool Mallard. For some time now, I’ve been working on a Wiki syntax parser for Doxer to unify the markup I have to use for my blog, inline documentation and CMS content markup at testbit.eu. (I have a blog entry in the queue on this for another day.) In this context, implementing a Doxer markup backend that generates Mallard’s XML input could be an attractive markup alternative for future Gnome documentation – it at least ended up on my ever growing TODO list. ;)

Lots of people approached me throughout this and the following days for a chat about Gtk+-3.0 and what comes after that. With the merging of the GSEAL branch into upstream trunk recently, there’s been a lot of focus on the technical preparative work we’re doing for the actual 3.0 release which is planned as an ABI break to Gtk+-2.16 without adding any new features (it’s basically just a re-release with all deprecated code removed and current “private” API really made private by moving it to non-installed source files).

What has been lacking emphasis in this course is that 3.0 is going to be the necessary enabler, needed to work on implementing future visions of Gtk+ and to refactor the code base back to a healthy state where it becomes maintainable again. Quite expectedly, the need for the sealing and accompanied ABI break has been questioned several times, so I’ll reiterate the reasoning here:

• Everybody falls the first time.
  Code development in open source projects is very evolutionary, especially for projects that don’t clone or reimplement existing specified APIs like Libc. A whole chapter is spent on prototypes in The Mythical Man-Month:
  “Plan to throw one away; you will, anyhow.”
  So newly added components and APIs are almost certain to need fixups or revamps in future iterations (likely more than once). If critical internals are being exposed and eternal ABI stability has been promised, this however becomes impossible. Given the development history of Gtk+ and the variety of interests in this project, it is vital for its future success to prepare for future changes and allow iterative improvements. After all, progressive improvements, appreciation of contributions and adaptions to changing circumstances is where the free software development model shows its strength. The waterfall design model is not it.
• Gtk+-2.x is essentially a dead end.
  Everybody agrees that Gtk+-2.x is pretty much dead in a few revisions because of the huge work involved in its maintenance and no relief in sight with its current ABI maintenance policy. This is at least true for all current and past core team members (i.e. everyone who actively tried maintaining 2.x over a significant period). The question is whether we move to an entirely new toolkit (Clutter, Rapicorn, Qt, HippoCanvas, etc) or whether that “new” toolkit is Gtk+-3.0 which may be largely API compatible with Gtk+-2.x. In either case, applications and libraries will need to migrate to a new toolkit base with a different ABI, the main difference is the involved porting effort.
• GLib and Gtk+ do have a means to deal with API changes:
  1) We provide new alternative interfaces (functions).
  2) We deprecate old interfaces (functions) or provide compatibility code in old interfaces.
  Notably, this does only work for API that is exported via function symbols. Structure fields that are directly accessed from application code can’t be deprecated and removed without breaking ABI, and there is no compatibility code upstream could provide for these kind of accesses either. That’s why we want to move away from exposing any structure internals in 3.0 and beyond.
• 3.0 will ABI-incompatibly remove all deprecated and private APIs.
  Of course, the above described deprecation scheme only scales well if deprecated APIs are really removed from the code base at some point. Technically, this is an ABI break which is why GLib/Gtk+ have not been doing this since 2.0. However, lots of other vendors do this to keep a healthy code base, e.g. Qt does break ABI between major releases, Python 3.0 will be incompatible with 2.5, Apple does remove long deprecated APIs in newer releases of Mac OS X, Symbian broke API and ABI in 9.x, Microsoft broke behavior from .NET 1.1 to 2.0, and the list goes on…
  By exposing only function symbols as future public interfaces, we’ll be able to provide arbitrary compatibility functionality for old interfaces on top of new components, add helpful runtime warnings for iterative migration and constrain future ABI breaks to removal of properly deprecated interfaces.
• User visible gains are post-3.0 features:
  Since GLib and Gtk+ are largely volunteer contribution based projects, it’s close to impossible to plan exact arrival of future features. However the following is a list of things that have (partially) been discussed as post-3.0 work during the Gtk+ Hackfest already:
  • Full support of alpha transparency for all widgets;
  • Support for (partial) stacking of widgets (needs transparency);
  • Offering easier layouting facilities;
  • Support for animated visible transitions between widget states;
  • Providing new UI metaphors based on simulation of physical effects like acceleration, 3D browsing of image collections, 3D skimming through notebook pages, and more;
  • Using IDL based type data generators and code generators to improve the way widgets are implemented;
  • Implementing a new theming system for the toolkit;
  • Moving towards exposing widget features only via interfaces that have their own handle (asymmetric query_interface).

This is how GSEAL, the Gtk+-3.0 release and a couple remaining outstanding tasks are going to enable development of exciting future user visible features. The next step for Gtk+ to get work in visionary areas off the ground is to start consideration of feature feasibility and implementations, required resources and tentative schedules.

At the end of the day, we had the Opening Cocktails Party, during which I managed to catch Hallski tattooing J5:

Thursday

Thursdays most interesting event was of course the keynote by Kris which got hijacked by the Gnome release team for the announcement of Gnome 3.0 which is essentially Gnome 2.30 cleaned up and based on Gtk+-3.x. Kris’ slides are available online:

	http://people.imendio.com/kris/gtk-state-of-the-union-2008.pdf

The slides provide a good overview of what Gtk+-2.14 will bring, prospects for 2.16 and visions/requests from the community for Gtk+’s future. As previously described, Gtk+-3.0 is about enabling refactorings and development of new features, and the plan is to do our best to make the transition away from old deprecated code as easy as possible. Other than properly porting an existing Gtk+-2.x application to work with the G_DISABLE_DEPRECATED, GTK_DISABLE_DEPRECATED, GSEAL_ENABLE switches, no additional changes will be required to build and run an application on Gtk+-3.0.

At the end of the day, there was the boat trip through the Bosporous which provided a beautiful sight along the coast line.

Friday

I managed to attend the latter half of the lightning talks which was as always quite interesting. I should probably ignore my laziness and actually prepare short lightning talks for next year about Rapicorn and possibly Doxer… ;)

I took particular interest in Transifex, an online translation platform that can work together with multiple VCSes and that we’d ideally move all Gnome translations to in the future. There are two things I’d like to see fixed in a future translation workflow from a developer perspective:

• The .po templates should really be generated by the developers of the upstream project by automatic means, e.g.:
  make update-po -C po/
  So the upstream version of intltool and po/Makefile.* are used instead of possibly broken or outdated intltool/gettext versions on the translators system.
• Developers should be able to determine merge points for translations, and also review related non-po file changes, rather than having translators wildly commit into upstream repositories (which may conflict with other VCS workflows like branch merges or commits around release phases).

Later on, Federico presented his ideas for timeline tabs for the desktop. This should make it rather easy to find documents or URLs from previous days or weeks, because out of natural necessity, humans generally have good chronological associations. So the new and nice part about this approach is that it can provide good visual access to the chronologic dimension, something a file system doesn’t usually reveal easily, and that’s not easily made accessible by the most prominent desktop metaphors either.

I feel very tempted to start an implementation of the desktop tabs with Rapicorn, however with a few refinements of Federico’s proposal:

• The view should provide a “chronological zoom” slider to switch the view between years/months/weeks/days/hours.
• To be most useful, we’ll need a crawler that tries to (re-)construct past file modification history without relying on programs pushing journal entries about file edits. This will be needed anyway unless every program on this planet provides file editing journal information.
• I think the journaling hooks need to be implemented via DBus and not rely on Nautilus, so they’re usable by all cross-desktop applications and non-GUI programs.
• Various filters by file extensions, magic and possibly more will also be needed in the tab view (this was partly raised during the discussion phase at the end of the presentation).

Saturday

About half of the Imendians headed home on Saturday, we had some early leaves on Friday already and left some others in Istanbul for additional vacations.

Oh, and since I’ve been asked about my nickname here and there, I decided to add tabs to my hackergotchi for clarification:

Aftermath

There have been quite some discussions on the Gtk+-3.0 plan after Kris’ keynote. One thing that was brought up is that releasing an ABI incompatible but featureless new version of Gtk+ and calling it 3.0 is rather unconventional. An alternative scheme could involve releasing the ABI incompatible cleaned up version as 2.99.0, make 2.99.x the new development branch and release 3.0 with cleaned up ABI and new features (would have been 3.2 in the original plan).

Every other week, someone asks how to use the new unit testing framework in GLib (released with GLib-2.16.0) and Gtk+ (to be released with the next stable). First, here is a write-up from last December that summarizes all important aspects: Test Framework Mini Tutorial.

For people building packages that use the new framework, the following new Makefile rules will be of interest:

• make test
  Run all tests recursively from $(TEST_PROGS), abort on first error.
• make test-report
  Run all tests recursively, continue on errors and generate test-report.xml.
• make perf-report
  Run all tests recursively, enable performance tests (this usually takes significantly longer), continue on errors, generate perf-report.xml.
• make full-report
  Run all tests recursively, enable performance tests, enable slow (thorough) tests, continue on errors, generate full-report.xml.
• make check
  Run make test in addition to automake checks.

After GUADEC, we will be looking into getting build machines setup that’ll regularly build GLib, Gtk+ and friends, run the unit testing suites and provide reports online.

For those pondering to write unit tests, but too lazy to look at the tutorial:

• Implementing a test program is very easy, the only things needed are:

    // initialize test program
    gtk_test_init (&argc, &argv);
    // hook up your test functions
    g_test_add_func ("/Simple Test Case", simple_test_case);
    // run tests from the suite
    return g_test_run();

• In most cases, a test function can be as simple as:

    static void
    simple_test_case (void)
    {
      // a suitable test
      g_assert (g_bit_storage (1) == 1);
      // a test with verbose error message
      g_assert_cmpint (g_bit_storage (1), ==, 1);
    }

  Tests that abort, e.g. via g_assert() or g_error(), are registered as failing tests with the framework. Also, the gtester utility used to implement the above Makefile rules will restart a test binary after a test function failed and continue to run remaining tests if g_test_add_func() has been used multiple times.

• Checks in tests can be written with if() and g_error() or exit(1), or simply by using variants of g_assert(). For unit tests in particular, an extended set of assertions has been added, the benefit of using these are the printouts of the involved values when an assertion doesn’t hold:

    g_assert_cmpstr   (stringa, cmpop, stringb);
    g_assert_cmpint   (int64a,  cmpop, int64b);
    g_assert_cmpuint  (uint64a, cmpop, uint64b);
    g_assert_cmphex   (uint64a, cmpop, uint64b);
    g_assert_cmpfloat (doublea, cmpop, doubleb);

  For instance:
  char *string = "foo"; g_assert_cmpstr (string, ==, "bar");
  yields:
  ERROR: assertion failed (string == "bar"): ("foo" == "bar")

• The framework makes it easy to test program output in unit tests:

    static void
    test_program_output (void)
    {
      if (g_test_trap_fork (0, G_TEST_TRAP_SILENCE_STDOUT |
                               G_TEST_TRAP_SILENCE_STDERR))
        {
          g_print ("some stdout text: somagic17\n");
          g_printerr ("some stderr text: semagic43\n");
          exit (0);
        }
      g_test_trap_assert_passed();
      g_test_trap_assert_stdout ("*somagic17*");
      g_test_trap_assert_stderr ("*semagic43*");
    }

• And it is similarly easy to test and verify intentional program abortion:

    static void
    test_fork_fail (void)
    {
      if (g_test_trap_fork (0, G_TEST_TRAP_SILENCE_STDERR))
        {
          g_assert_not_reached();
        }
      g_test_trap_assert_failed();
      g_test_trap_assert_stderr ("*ERROR*test_fork_fail*not*reached*");
    }

• The above and more tests are showcased in GLib: glib/tests/testing.c.

There’s of course lots of room left to improve GLib and Gtk+ unit tests, and also to improve the current framework. For a speculative, non-comprehensive list, here are some ideas from the unit testing section of my personal TODO:

• Introduce 2D marker recognition for graphical unit testing of Gtk+ layouts (prototyped in Rapicorn).
• Provide functionality to determine image similarities to allow for pixel image based unit tests (port this from Rapicorn).
• Implement state dumps to automate result specification and verification in unit tests. (This will allow us to avoid adding lots of abusable testing hooks to our API.)
• Integrate performance statistics (like #354457) and other related information into test reports.
• Publically install a variant of the Makefile.decl file used in Gtk+ to implement the test framework rules and Xvfb swallowing of test programs. This is needed by other projects to run unit tests the way Gtk+ does.
• Implement the unit test ideas that are outlined at the end of this email: Gtk+ unit tests (brainstorming).

Amongst many other things during the Gtk+ Hackfest 2008, it was brought to my attention that Gtk+ maintainership is sometimes perceived as some kind of leet circle, hard to join for newcomers. I can’t really imagine how “hard” it is for newcomers to join Gtk+ maintenance these days. The learning curve probably is steeper now than it was in the last decade, but then, we do have documentation now and didn’t have any back then… ;-)

In any case, I think that definitely none of the Gtk+/GLib core maintainers would want to bar someone else from contributions or helping out with maintenance tasks. So to aid that process, I’ve written down what I keep telling people who approach me about this in person. A lot of it might seem overly obvious to veterans, but for newcomers or contributors looking into extending their activities on the project I hope to provide helpful starting points.

Much of Gtk+ is still maintained as a huge monolithic whole. That is, a very few people are taking care of a wide variety of components. I think ultimately we would all be much better off, if we had more people being responsible for individual components like particular widgets (e.g. GtkNotebook) or widget families (e.g. GtkBox, GtkHBox, GtkVBox). So the following are steps and tasks useful for anyone wanting to get into Gtk+ component maintenance.

First of all, we have the GtkTasks wiki page, a task list with various ways in which people can contribute to the Gtk+ project and start getting involved. In particular for the following positions, no one has signed up so far to volunteer on a regular basis:

• Patch/Bug Monitoring & Filing – collect bugs from mailing lists and IRC to make sure they are being filed.
• FAQ Maintainer – this involves monitoring the mailing list(s), taking CC:-mails from other people on possible FAQ material and regularly updating the FAQ accordingly.
• Build Monitoring – run and maintain Gtk+ tool-chain builds on various platforms.
• Making Releases – we are looking for someone assisting in the release process and to take over release building during some periods in the future.
• Implementing Test Programs – there’s much work needed in our unit test coverage, so we’re always looking for people willing to implement more unit tests.

For general information about the maintenance situation, the State of the Gtk+ Maintenance write-up is still fairly valid. However many good things have been suggested by the community since, such as the GtkTasks page and the Hackfest. At the end, the write-up addresses how occasional contributors or developers at different experience levels can help out the project. For instance with activities such as: Bug triage and verification, Review and clarify documentation, Revision hunting for regressions, Refactor code areas, Work on optimizations, and the list goes on.

If none of this sounds interesting to potential new maintainers, be warned that regular maintenance means having to put up with pretty much all of these at some point. ;-)
However, probably the most straight forward way to take on maintenance for a particular code portion (usually a particular widget) is to start becoming familiar with it and work on improving it right away:

• Cleanup indentation – lots of contributions to Gtk+ in the past have weakened coding style in various areas. In general we use GNU coding style plus a few extra rules similar to the Gimp coding style.
• Perform code cleanups – look for outstanding migrations/refactorings in the code or if the implementation could be simplified/streamlined in areas.
• Check documentation and examples – contributing by improving the existing documentation, testing existing examples and providing new ones is a very straight forward way to learn about a new component. Also, documentation patches are usually easily and quickly approved.
• Provide unit tests – writing new unit tests for existing component APIs is even better than providing documentation examples. You get immediate feedback and they should in general be easy to approve to go into upstream. Also, it is definitely an area where Gtk+ and GLib still need lots of work.
• Review bug reports and patches – go through the Gtk+ bug load of a particular component, see what issues could be closed or need info. Find patches that could be applied or need work and provide/fix patches along the way. Also, feel free to provide review for existing patches where you feel confident to provide reasonable input. For existing maintainers, looking at other people’s review is one of the best ways to figure if another person is up to the task of taking over component maintenance.
• Actively nag existing maintainers or people with SVN accounts for trivial patches (like Cody and Mathias who signed up for Patch testing & committing) to review, approve and apply your changes.
• Participate in the project forums like gtk-devel-list and #gtk+ (needed to nag people from the core team and other developers), and read and reply in other related mailing lists.

The first few points actually mean working with the code by providing patches, and filing new bug reports with those patches attached. While this may at first increase our bug load, if someone shows sincere interest in taking over component maintenance, sticks to the coding style and provides useful patches, there’s nothing stopping us from granting new SVN accounts so contributors can commit their own patches after approval.

Finally, the project is welcoming every new contributor. But be reminded that no approval is needed from anyone to start your work. In actuality, asking for it will most probably get you a reserved or negative answer, because improving the project is all about working on it, not making or requesting promises. So, everyone is invited to read through the task lists/descriptions and get their hands dirty immediately. A fair bit of self incentive is needed to take on maintenance of a component anyway, so you’ll have to get yourself motivated on your own there won’t be anyone else doing it for you.

There have been several requests about hosting Gtk+ (and GLib) as a Git repository recently and since that topic has come up more and more often, I meant to write about this for quite some time.

Let’s first take a look at the actual motivation for such a move. There are a good number of advantages we would get out of using Git as a source code repository for Gtk+ and GLib:

• We can work offline with the Gtk+ history and source code.
• We can work much faster on Gtk+ even when online with tools such as git-log and git-blame.
• It will be much easier for people to branch off and do development on their own local branches for a while, exchange their code easily with pulling branches between private repositories, etc. I.e. get all the advantages of a truly distributed versioning system.
• With Git it’s much easier to carry along big Gtk+ changes including history by using cherry picking and (interactive) rebasing.
• We can make proper public backups of the source code repositories. This ought to be possible already via svnsync, but isn’t for svn.gnome.org because we run an svn 1.3.x server instead of an svn 1.4.x server that is required by svnsync. (Yes, this issue has been raised with the sysadmins already.)

A quick poll on IRC has shown that all affected core maintainers are pretty much favoring Git over SVN as a source code repository for GLib/Gtk+.

However, here are the points to be considered for not moving the repositories to Git (just yet):

• Complexity; Git is often perceived to be harder to use than SVN, there are several attempts to mitigate this problem though: Easy Git Giggle yyhelp.
  With some of the above, Git is as easy to use as SVN is, so Git complexity doesn’t need to be holding anyone off at this point.
• Git may be stable and mature these days, but git-svn is not there yet. It is generally good enough to create local Git mirrors of SVN repositories and work from those to have most of the Git convenience on top of an SVN project.
  But git-svn has seen structural changes recently, quite some rewriting and bug fixing that indicate it’s still too much in flux for the one-and-only SVN->Git migration for projects at the scale of Gtk+. This is not meant as criticism on git-svn, fairly the opposite actually. It’s good to see such an important component be alive and vivid. All issues I’ve raised with the maintainer so far have been addressed, but it seems advisable to wait for some stabilization before trusting all the Gtk+ history to it.
• Gitweb interfaces already exist for GLib/Gtk+ mirrors, for example on testbit: Testbit Git Browser.
  These can be used for cloning which is much faster than a full git-svn import. Alternatively, shallow git-svn imports can be created like this:

    git-svn clone -T trunk -b branches -t tags -r 19001 svn://svn.gnome.org/svn/gtk+
  

  This will create a repository with a mere ~1000 revisions, including all changes since we branched for 2.12. We’re using such a shallow repository for faster cloning of our GSEAL() development at Imendio: view gtk+.git.

• In summer 2006, we’ve had the first test migration of all of GNOME CVS to SVN, in December 2006 we’ve had the final migration. During that period, the Beast project stayed migrated to SVN to work out the quirks from the CVS->SVN migration before we migrate all other GNOME modules and have to fix up everyones converted modules. There were quite some issues that needed fixing after the initial test migration and in the end we had to rebuild the Beast development history from pieces. Preventing the other GNOME modules from such hassle was the entire point in migrating Beast early on, so I’m not complaining.
  However, given the size and importance of GLib/Gtk+, the development history of those projects shouldn’t be put at a similar risk. That is, GLib/Gtk+ shouldn’t be pioneering our next source repository migration, let some other small project do this and work out the quirks first.
• git-svn already provides a good part of the Git advantages to developers while Gtk+ stays hosted in SVN. Albeit due to mismatching hashes, syncing branches between distinct git-svn checkouts of different people is tedious. Setting up an “official” git-svn mirror on git.gtk.org could probably help here. Also, to ease integration, jhbuild could be extended to use git-svn instead of svn commandos to update SVN modules, if the current module has a .git/ subdirectory instead of a .svn/ subdirectory.

The bottom line is, there’s a good number of advantages that Git already can (or could) provide for our development even without migrating the repositories to Git right away. When exactly will be a good point for migrating GLib/Gtk+ and possibly other GNOME modules might not be an easy call, but right now is definitely too early.

I’m currently in the process of building some general purpose infrastructure for Rapicorn and because a good portion of the C++ utilities used in Beast and Rapicorn are factored out into an extra library called Birnet. I’m running into similar complexity issues here that we encountered with libglib vs. libgobject vs. libgdk already. I.e. lower level modules cannot reference or use mechanisms provided at a higher level (for instance deriving GHashTable from GObject). This becomes even worse with C++ which lacks support for partial classes (a class definition spanning multiple source files, like implementing gtk_widget_foo() outside of libgtk).

One remedy would be to actually merge libbirnet and librapicorn into a single project and let Beast depend on librapicorn. However, that’s essentially like we started out with GLib and Gtk+ in late 1996 when it got split out of the Gimp package. In June 1998 we split off libglib into a separate package for programs needing C utilities but not libgtk. So now, I’m reconsidering this separation after almost a decade. Reflecting on the move is probably not a bad idea before attempting the opposite with Rapicorn:

How many programs are actually linking against libglib but not libgdk, and is there any real benefit from separation?
If your machine has libglib and a few spare minutes, you can use this command line to find out on your own:

	find `echo $PATH | sed 's/:/ /g'` -type f -perm +111 | xargs ldd 2>/dev/null |
	  awk '/\<libglib-2\>/{ lg+=1 } /\<libgobject\>/{ lo+=1 } /\<libgdk_pixbuf\>/{ lp+=1 }
               END { print "glib=" lg " gobject=" lo " gdk=" lp ;
                     print "glib-only:    " 100*(lg-lo)/lg "%";
                     print "gobject-only: " 100*(lo-lp)/lg "%";
                     print "gdk-lot:      " 100*lp/lg "%"; }'

Here are results from a couple machines I had quick access to:

	Site                       Gdk  GObject     GLib  #Apps
	gimp.org:                50.0%    12.5%    37.5%     16
	gtk.org:                 47.1%    17.6%    35.3%     17
	developer.gnome.org:     19.5%    53.7%    26.8%     41
	my server (sarge):       66.7%    14.1%    19.3%    192
	my laptop (etch):        72.7%    14.8%    12.4%    209
	my desktop (feisty):     72.2%    17.1%    10.7%    252
	64bit KDE desktop (sid): 53.0%    16.7%    30.2%    338

That is, the servers have a quite limited set of GUI applications installed, but across a full fledged desktop the vast majority of applications is linked against libgdk anyway. I found Stefan Westerfelds Amd64 KDE desktop particularly interesting: It actually has the most applications linking against GLib, prolly because it has Mono and libQtCore.so installed which both link against GLib these days. Does anyone actually have a system with libglib installed but not libgdk?

Next, let’s take a look at the actual “savings”:

	ls -l libglib-2.0.so.0.1200.4 libgmodule-2.0.so.0.1200.4 \
              libgobject-2.0.so.0.1200.4 libgthread-2.0.so.0.1200.4
	-rw-r--r-- 1 root root 596608 2006-11-16 10:26 libglib-2.0.so.0.1200.4
	-rw-r--r-- 1 root root   9784 2006-11-16 10:26 libgmodule-2.0.so.0.1200.4
	-rw-r--r-- 1 root root 237156 2006-11-16 10:26 libgobject-2.0.so.0.1200.4
	-rw-r--r-- 1 root root  14028 2006-11-16 10:26 libgthread-2.0.so.0.1200.4
	=====================================
	                       857576 = 837KB

	ls -l libatk-1.0.so.0.1214.0 libcairo.so.2.9.2 libpango-1.0.so.0.1400.8 \
	      libgtk-x11-2.0.so.0.800.20 libgdk_pixbuf-2.0.so.0.800.20 \
              libgdk-x11-2.0.so.0.800.20
	-rw-r--r-- 1 root root  102504 2007-03-14 13:44 libatk-1.0.so.0.1214.0
	-rw-r--r-- 1 root root  395836 2006-10-20 07:44 libcairo.so.2.9.2
	-rw-r--r-- 1 root root  235464 2007-01-14 22:27 libpango-1.0.so.0.1400.8
	-rw-r--r-- 1 root root   88604 2007-03-04 22:21 libgdk_pixbuf-2.0.so.0.800.20
	-rw-r--r-- 1 root root  528580 2007-03-04 22:21 libgdk-x11-2.0.so.0.800.20
	-rw-r--r-- 1 root root 3043524 2007-03-04 22:21 libgtk-x11-2.0.so.0.800.20
	=======================================
	                       4394512 = 4292KB

GtkGdkPangoAtkCairoGlib / GLib ratio: (4394512 + 857576) / 857576 = 6.12.
So the “savings” turn out to be splitting off 5/6th of the GUI stack size. At best, a GLib-only program is saving 4.2MB that way. But then again, those are likely to be in memory already anyway. And most definitely, they reside in a library, available as const .text on the harddisk. To put that into perspective: We’re talking about only a handful megabytes here. In physical size actually less than a hires desktop background image, smaller than some icon themes, or roughly 10% of a full linux-2.6.8 kernel + modules binary footprint (41MB). Also symbol resolution performance doesn’t necessarily improve through splits, Ulrich Drepper has a few words on multiple DSOs during deployment.

Given that selecting Gtk+ subcomponents to allow selective shrinkage for size constrained embedded devices via configure.in options is on our TODO list anyway; for this set of libraries: Size is not worth a split!

Of course, other aspects not reflected in library size weigh in much more strongly. Such as the ability to build different user communities around projects (e.g. for Cairo vs. Glib) or the reduced dependency chain (sshfs and Qt wouldn’t depend on GLib if it drew in Pango or Gtk+).
So while for the vast majority of applications the GLib split off doesn’t make a huge difference technically, software evolution arguments make all the difference, definitely justifying a separation. The GLib internal splits are definitely not worth the hassle and conceptual boundaries though, if we ever break binary compatibility again, merging the GLib internal libraries and respective pkg-config packages would be a good idea.

Back to my original problem… I’m now pretty convinced that merging Rapicorn with the Birnet utility library will most likely not pose a problem anytime soon. And Qt 4 kindly demonstrates that splits can also be carried out successfully later on during the game.

1) A dependency on OpenGL for a library as portable and as widely used as Gtk+ these days, could only ever be a weak one. That is, OpenGL features may or may not be used, depending on whether the current platform a Gtk+ application runs on actually has OpenGL available or not (e.g. by animating widgets conditionally to only be carried out when acceleration support is present).

2) The OpenGL 2D drawing API is effectively unusable for Gdk/Gtk+ drawing primitives. The main problem here is that OpenGL doesn’t provide pixel-perfect 2D drawing operations which are necessary for accurate input event processing and a coherent visual presentation (it also doesn’t always provide anti-aliasing in the 2D drawing API either). Here is a very good web page with nice screenshots summarizing the problems with OpenGL pixel-perfectness: OpenGL: “not pixel exact”, Hardware AntiAliasing.

3) By using XRENDER and hardware-accelerated X drivers, Cairo is already being performance optimized to utilize hardware acceleration. Trying to use a portable OpenGL subset instead (pixel shaders / triangle rendering) would be fairly pointless, it’d effectively be using the available portable hardware acceleration facilities through another indirection. So with more and more Gtk+-based platforms/applications moving to Cairo-based drawing, there is no additional infrastructure or support code needed to make use of available hardware acceleration facilities. Essentially, the portably usable hardware acceleration subset is brought to you automatically through Cairo and X.

For the lazy, here’s a quick overview of the artifacts presented on the OpenGL comparison page:

.

The documentation updates cover Gtk+-2.11.4, so they contain new features like: GtkBuildable, GtkBuilder, GtkScaleButton, GtkVolumeButton and GtkTooltip.

You can do this for Gtk+: Patch testing & committing

Gtk+ has a volunteer task list up on the wiki. One of the open positions is the one i just described, and it’d much help the project if people signed up for it. Note that having SVN access can help but is not a requirement for all tasks, access rights can be granted for active contributors.

Next time you wonder why your Gtk+ bug report seems stalled, don’t ask why it’s being processed so slowly, ask yourself why you’re not helping the project already, so all submissions can be processed faster, including yours. ;-)

In other news, there’s been some discussion on width-for-height and height-for-width management around Gtk+ recently. So I summarized the approach taken by Rapicorn, which in a nutshell allows arbitrary constrains with multiple resizing iterations and employs dedicated strategies to stabilize the resizing process: Hysteresis problems in Gtk+ – Rapicorn size negotiation.

Gtk+ has an alarming shortage on core maintainer resources.

That being said, let me make one thing crystal clear here: this can not be blamed on the core maintainers themselves, they are doing their best to cope with the situation as it is. By a large ratio, there simply isn’t enough man power available to handle all the incoming requests, to review all contributed patches, debug all the bugs filed and to do important nurturing and maintenance work needed by an ever growing code base (like refactoring).
This situation has been persisting for a longer time now, and has led to significant aging in the code base and affected the overall quality of the project. As time passes, it’ll just become worse if we’re not going to put more resources at the project as a community. I figured that in order for this to happen, a sense for the problematic nature of the current maintenance situation has to first be developed in the community, which is why i posted to gtk-devel and related lists yesterday:

State of the Gtk+ Maintenance