Planet Imendio

No! this isn’t another “added tabs to $APP” [1], Instead I decided to spend my hacking time on getting MPX work with GTK+. Surprisingly, gdk is 99% prepared to handle multiple pointers, so besides adding support there for the new XInput method to handle device grabs, most of the remaining work should just be focused on making GtkWidgets deal sanely with multiple pointers (madness awaits there…). Here’s a “screencast” of my proof app, apologies for the quality, trying to record and use both the nipple thingy and the touchpad isn’t quite easy

Also, I’ve spent one extra week in Istanbul and surroundings with Mitch and Pia, It has proven to be a really beautiful place full of life, returning to Turkey is a must.

[1] You caught me guys :), I was seriously concerned about your sanity for a while

Update: In case it isn’t clear, the patch isn’t really far from the “evil hack” state, I’ll just submit it to bugzilla as soon as there’s some reasonable base work in which other smaller patches can be developed incrementally.

Going on vacation tomorrow for a week of orienteering in Sälen, Sweden. The terrain will vary from a more classic swedish orienteering for the first two stages and the go over to an alpine terrain with more open areas and higher altitude differences for the third and fourth stage. The last stage seems to be back to more classic terrain again with a mix of small hills and marshes.

In total the event (in my class) will be about 30km as the birds fly which should translate into something like 45-50km of terrain running over the course of five days. Hopefully I’ve exercised enough, I’ve tried to do 4-5 sessions per week over the last couple of weeks and luckily Guadec had little impact on the overall fitness as this week felt really good.

Share This

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).

Somewhat back to normal routines after a week in beautiful Istanbul. As people reading Planet GNOME have seen from others, it was a great Guadec this year.

I found the schedule to be a bit uninspiring but that left more time for discussions and hacking. Among the sessions I went to I really enjoyed going to Alp’s session about Webkit and Blizzards on Mozilla. Some really interesting things coming from these projects.

Kris did a great job wrapping up the current state in GTK+ during his now traditional ‘GTK+ State of the Union’ talk and happy to see that the discussion around future GTK+ is getting started throughout the community. I spent a lot of time this year talking and listening to peoples feedback on the proposed plans. Realized that some things have been a bit left out from the discussions after the hackfest and that we need to do a better job at communicating what we plan to work on besides the cleanups and enabling of future development.

Finally a warm welcome to Stormy as executive director of the GNOME Foundation Board.

Share This

Okay, I am actually getting hacking done (okay okay it is more like reviewing) and I just committed the fix for #316087 "Resizing columns is chaotic" to gtk+ trunk (finally!). Should be in the next 2.13 releases. This patch does modify the internals of tree view column size allocation, so if people could give the latest gtk+ from trunk a test drive that would be really appreciated :)

By the way, you can find the slides from yesterday's GTK+ state of the Union here.
The plans from the release team for GNOME3 sound cool, exciting times ahead :)

We decided to have the GNOME Art BOF on Thursday afternoon 15.30 (turkish time). We’ll try to add notes in #art-meeting on IRC (gimpnet) during the meeting. We haven’t decided on a room yet, but we’ll meet in the lobby, and go and find somewhere to sit down.
Hope to see you there!

Update: I screwed up a bit. It’s 16.30, same place.

My talk "GTK+ State of the Union" at GUADEC has been moved from Friday morning to Thursday 14:30 (the cancelled keynote slot). This was noted in the schedule on the GUADEC website before, but unfortunately this schedule was reverted to the original version as also found on the badges this morning. But the move of the talk is still on :)

Minutes from the GTK+ developer's meeting we had yesterday will follow soon, hopefully early next week. Ah yeah, and during GUADEC I am hacking on Bug 316087, or better known as "column resizing with expand=TRUE columns is entirely fucked up". Seems we are very close to getting this fixed now.

I will probably also hang out at the parties during the upcoming days, so see you all there ;)

It's too hot in Istanbul to have the energy to write something useful right now, but since I promised Bastien a screenshot, here it is:

This is Totem running on GTK+ OS X, but without any nice integration with the global menubar and there is no clean patch that can be committed. (The changes are mostly commenting out some X11 and GNOME dependencies.)

It's using a video sink that renders into a GdkWindow (actually it's backing NSView) through OpenGL, based on the Cocoa video sink that comes with GStreamer.

Posting this just before going to bed for an early rise to fly to Guadec in Istanbul. Unless someone gets sick last minute the entire Imendio crew will be arriving tomorrow and staying at the Golden Horn Sultanahmet.

See you all there!

Share This

I've used Gossip and Giggle in the past as examples of creating Mac bundles of GTK+ apps. Now I have another example that is a bit more complex, in that it uses GStreamer. The test case this time is the good old...

Jamboree music player!

I dug it up from the GNOME SVN archive and it worked pretty much out of the box after cleaning up the makefiles a bit and adding support for the Mac integration library to hook up the menubar.

The latest version of the Mac bundler and the bundle file here results in a nice little bundle.

It looks like this:

GStreamer works nicely, and using the QuickTime wrapper element gives access to all formats supported by the platform.

I've released a new version of the Mac bundler, 0.5. The changes are:

• Correct the GTK_DATA_PREFIX variable
• Add beginnings of framework support
• Clarifications in README and example bundle file
• Remove support for non-included Pango font module
• Fix locale in the launcher script

Download here.

During the last few days I was working on the website for a change. In fact my dear Nancy was doing the lion share of this work. She even made a new Catfish logo on the way. Afterall we are going to share this new site, for programs I work on and artwork Nancy will publish here. The URL moved from software.twotoasts.de to the toplevel www.twotoasts.de. The old file links should silently redirect, including downloads, screenshots and git repository. The sub pages have changed but will all lead to the homepage now, which shouldn't be a problem. Of course I recommend everyone to update your links and bookmarks to www.twotoasts.de now.

A frequent comment I get is that the GTK+ OS X screenshots look like... GTK+. As opposed to native Mac applications, of course. I started a native theme engine quite a while ago but got sidetracked with other things, so it's been sitting around in a git repo for some time now. It could be a fun hack if someone wants to get involved in GTK+ OS X hacking, and there is plenty of low hanging fruit to take care of. It's quite rewarding to play around with, as the result of the work is so immediately visible.

You can check it out here:

  svn co svn.gnome.org/svn/gtk-quartz-engine/trunk gtk-quartz-engine

Here's an example of what it looks like on 10.5:

Update

The repo was moved to GNOME subversion, I've updated the info above to reflect that.

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).

This is something I’ve had to checkup a few times so I figured it would be useful both for myself and for others to keep around in a blog post.

To remove a remote branch you created in Git just push to it like:

$ git push origin :name-of-branch

Share This

The XML GUI definition files used in Rapicorn and also in Beast (described briefly in an earlier blog post) supported a simple $(function,arguments...) evaluation syntax, similar to GNU Make. I’ve never been very happy with this syntax, but it was fairly easy to implement at the start and followed naturally from early $VARIABLE expansion features. At some point last year I considered various alternative syntax variants and discussed the ideas with Stefan Westerfeld. Over the course of the last two months, I finally got around to implement them.

I’ve never grown familiar with reverse polish notation, and although Guile is the canonical scripting language for Beast, I’ve always found myself very inefficient with expressing my thoughts in lisp expressions. So the new syntax definitely had to support infix expressions - despite the more complex parsing logic required to parse them. Bison already ships with an example calculator that parses infix expressions, so that’s a quick start as far as the syntax rules go. Integration is quite a different story though, more on that later.

Since in Rapicorn the expressions are used to compute widget property values, they are likely to be executed very often, i.e. each time a widget is created from an XML file description. Consequently, I wanted to use a pre-parsed AST to carry out the evaluation and avoid mixing evaluation logic with parser logic, which would have forced reparsing expressions upon each evaluation. At first I quickly threw together some C++ classes for the arithmetic operators and used those as nodes for the AST, similar to:

  class ASTNodeNot : virtual public ASTNode {
    ASTNode &m_operand;
  public:
    explicit ASTNodeNot (ASTNode &operand) :
      m_operand (a)
    {}
    virtual Value
    eval (Env *env) const
    {
      Value a = m_operand.eval();
      return Value (!a.asbool());
    }
  };

The supported syntax is quickly summarized:

  Operators: ( + - * / ** < > <= >= == != or and not )
  Functions: name ( args... )
  Inputs:    FloatingPoint 'SingleQuotedString' "DoubleQuotedString"

In this notation, FloatingPoint includes hexadecimal numbers and of course integers and the quoted strings support C style escape sequences like octal numbers, ‘\n‘, ‘\t‘ and so on. The functions can be implemented by the parser API user, but a good set of standard arithmetic functions is already supported like ceil(), floor(), min(), max(), log(), etc. So it’s a very basic parser, but covers the vast majority of expressions needed to position widgets or configure packing properties.

One thing that turned out to be tricky is the binary operator semantics for strings. At the very least, I wanted support for "string" + "string" and "string" == "string". Since both operators are supported for numbers as well, the exact behavior of "string" + FloatingPoint and "string" == FloatingPoint had to be defined. I managed to find a few programming language precedents here in Perl, Python, and ECMAScript (Javascript). They of course all handle the cases differently. In the end I settled with ECMAScript semantics:

  Value1 == Value2  # does string comparisons if both values are strings
  Value1 + Value2   # does string conversion if either value is a string

Unit testing for the parser turned out to be particularly easy to implement. All that’s needed is a small utility that reads expressions and prints/verifies the evaluation results. Throwing in some additional shell code allowed a normal text file to drive unit testing. It simply contains expressions and expected results on alternating lines. Btw, libreadline can be really handy in cases like this. Using it takes a mere 5-10 lines of additional code to support a nice interactive command line interface including history for the evaluator test shell.

After some initial testing, the C++ AST node classes seemed like an awful lot of pointers, fragmentation and VTable calls for a supposedly straight forward expression evaluation. Also, adding the missing destruction semantics would have significantly increased the existing class logic. So I tried to come up with a leaner and foremost flat memory presentation. In the end, I settled with a single array that grows in 4 byte (integer) steps, embeds strings literally (padded to 4 byte alignment) and uses array offsets instead of pointers for references. A single multiplication operator is encoded with 3 integers that way: MUL_opcode factor1_index factor2_index. That’s essentially 12 bytes per binary operator, still significantly more than the parser input, but also significantly smaller than allocating an equivalent C++ class. Evaluation of the expression stored in the array doesn’t need any VTable calls, and a single straight forward evaluation function can be used, that implements the different operators as switch statement cases. Also release semantics are persuasively trivial for a single consecutive array.

What’s left was to figure a way to embed expression evaluation in XML values or text blocks. Previously, $(expression) was substituted everywhere, but with the new syntax, variables (or rather constants defined within the Rapicorn core or via the ‘<arg:ArgName default="5"/>‘ syntax supported by Rapicorn XML files) didn’t use a $-prefix anymore. So sticking with $() seemed to make little sense. As it’s implemented now, backticks are used to cause expression evaluation, with the empty expression evaluating to a single backtick:

  XML Value/Text         Parser Result
    Foo  5 + 5      ->     Foo  5 + 5
    Foo `5 + 5`     ->     Foo 10
    ``Foo``         ->     `Foo`

We will see how useful the current expression style turns out to be. I don’t consider every implementation bit outlined here solidly engraved into stone yet. So as always, I’m open to constructive feedback.

As forewarned, I have a few more words on integrating Flex and Bison with each other and into one’s own library. First, Flex and Bison turned out not to be exactly simple to configure, especially if none of the generated symbols should be exported from a library or clash with a possible second parser linked into the same library or program. Also some fiddling is required to pass on proper line count information from the lexer to the parser, getting character counts as well is non-trivial but lucky wasn’t strictly needed for Rapicorn expressions. The simplest setup I managed to come up with works as follows:

  sinfex.hh     # public API
  sinfeximpl.hh # internal structure definitions
  sinfex.cc     # evaluator implementation
  sinfex.l      # scanner rules for Flex
  sinfex.y      # parser rules for Bison
  sinfex.lgen   # generated by Flex
  sinfex.ygen   # generated by Bison

The only compiled file in this list is sinfex.cc which includes sinfex.lgen and sinfex.ygen as part of an anonymous C++ namespace. A linker script ldscript.map used when finally linking the library prevents anonymous symbols from being exported. The anonymous namespacing of everything declared in sinfex.lgen and sinfex.ygen is what prevents clashes with a possible second parser linked into the library. This isn’t as elegant as i was hoping for, but at least effective in a practical sense. There unfortunately is no way to configure Flex or Bison to generate only static functions and variables. And yes, I have also looked into variants like flex++, bison++, bisonc++, byacc, etc, but they usually show much of the same problems and also tend to make matters worse by generating more files or more complex code.

I've been meaning to blog again for a long while, and I finally managed to sit down and do it. The last few months have been very, very busy. I got inspired in some way and started studying three times as hard, which is a good thing since I finally manage to get a lot of things done there. This week I finished two more master courses, for both of which we did some interesting stuff. For the first one I have been looking at very low-level cache optimizations (esp. strip lining/loop blocking) with somebody else; learnt a great deal of new stuff and gained experience. The other course was about grid computing; for the presentation and project part I have been focussing on data storage in grids. I've been looking at iRODS, which is an open source system for building data grids. It is a very interesting and promising project, but not yet ready for production deployments. I should probably put my report on this online at some point. Furthermore, my thesis is finally almost done. In the coming weeks I will be working on finishing another course which I had to leave behind for a while at the end of last year. At least the end is coming in sight, I hope to have my BSc and MSc degrees before mid next-year.

Being very busy with studying is nice and all, but it means I had zero time left for spare time (GTK+) hacking. I hope this will change in the coming weeks and get my "getting things done" attitude from University work also applied to GTK+ hacking ;) I am going to look into:

• Getting the column resizing with > 1 expand=TRUE columns patch updated, fixed and committed in trunk. (finally)



• Design and implement a proper API for doing DnD (with multiple rows) in GtkTreeView. This should include making it possible to DnD between tree views and apps. (finally)



• Look into improving the rubber banding behavior as Christian Neumair talked about in his blog. As is stated in the related tree view bugzilla bug about this, probably need to move over the cell_process_action() refactorings from my experimental branch to trunk and then this might be much easier to fix. Moving that refactoring over means writing a good automated layouting test.



• Look into properly fixing the editing mess. We need a better means to distinguish between committed/cancelled editings.



• Actually write about the plans for a simple tree view wrapper that I've discussed with Johan and Emmanuele during the hack fest.



• Continue hacking on my experimental tree view branch. More on this later.

I thought I had more for this list, but this will keep me busy for a good while anyway ;)

Was playing around a bit with a synchronous network library that I wanted to use from a GTK+ frontend. Obviously this wouldn’t work too well as the UI would be blocked while waiting for the library to return from it’s network calls. So I wanted to run the network operations in the background using a thread but still get the callbacks in the main thread to be able to update the UI from there.

I ended up writing a small class I called AsyncRunner which is a small proxy to call methods in a various thread and get the callback in the main thread. It’s using the GLib Mainloop so it would only be useful in the cases where you actually have one.

require 'thread-sync'
class MySyncClass
  def foo_method(arg)
  end

  def bar_method(arg1, arg2)
  end
end

sync = MySyncClass.new

# In order to get the methods of MySyncClass asynchronous it is wrapped in an AsyncRunner.
async = AsyncRunner.new(sync)

async.foo_method('test') do
  ui_update()
end

main_loop = GLib::MainLoop.new
main_loop.run

Share This

Just like LinuxTag last year, I went to Berlin the past week to help running the Gnome booth for LinuxTag 2008.

Due to a sports accident, our booth bunny Sven Herzberg unfortunately couldn’t make it, so on Tuesday I took over booth management and merchandise from him and hurried to Berlin in an ICE instead of a car as was originally planned. In Berlin, I met up with Mathias Hasselmann who brought the European Gnome event box and together we set up the booth until late in the night.

On Wednesday morning, Michael Köchling and Christian Dywan arrived, so we had enough people to properly man the booth. Michael seems to be an early riser, since he managed to show up at 09:00 for all days, so i passed the booth keys on to him.

Around lunch time, I was dragged away for an interview about business involvement in free software and Gnome in particular by Malgorzata Ciesielska, a business school student from Copenhagen. She also interviewed other people like Lennart Poettering who also sporadically hung around our booth.

Later that day, Lennart and i went over the new libcanberra API in a lengthy discussion. Libcanberra is a new library for playback or activation of sound events in response to desktop actions that Lennart currently works on. We talked about the needs of timing information for some usage cases, possibly also dispatching forced feedback controls via the library and implementation of a Gtk+ module to hook canberra functionality up with GUI events. What turned out to be a bit tricky is to derive actual semantic information from the low level X event notification that Gtk+ signals proxy, such as dialog-confirmed, dialog-cancelled, menu-item-selected, menu-item-cancelled, combobox-popup, combobox-selected, combobox-cancelled, etc. This extraction requires significantly more logic and special casing of event notification than Lennart apparently had originally hoped for.

On Thursday I attended the Linux Kernel - Quo vadis? talk by Thomas Gleixner which was quite interesting. I managed to catch him afterwards to talk about the prospects of having a memory pressure signal in the Linux kernel. For GLib and Gtk+, this’d be quite useful to voluntarily release pixmap or GSlice caches, particularly desired on embedded platforms.

Friday I sat down with Vincent Untz for a very productive discussion about Gnome/Gtk+ release prospects, autotools, intltool features and more. Later I had a chance to chat with Alexander Neundorf about KDE’s recent CMake migration process. Overall, they seem to be pretty happy with the results. Major benefits from migrating from autotools to CMake seem to be:

• Build process speedups due to getting rid of libtool.
• Simplicity; the build setup is back to a manageable level again. For KDE, the previous combinatoric mess of autotools was hardly fully understood by any single person.
• Unification/merging of build files for Unixes and Windows. (Duplication of build logic between auto* files, nmake and MS project files is currently a major annoyance for Gtk+’s Win32 maintainers.)

On Saturday the last day of the conference, I attended Anne Østergaard’s presentation about Gnome Foundation structures and achievements, the slides of which are available here: The GNOME Foundation (PDF).

After that, I went to Jono Bacon’s talk in which he explained how the free software community is a creative and productive community, which sets it apart from other common community types in our society (usually fan communities). He went on pointing out how this collaborative and open community as a whole (and thus every significant contribution to it) impacts and gradually changes the really big IT companies from within in an unprecedented manner. Come to think of it, this is an incredible achievement that we should rejoice in, especially because it is a morally correct change in that it strives towards openness.

All in all, it was a nice conference again. Personally, I particularly enjoy meeting up with other hackers for productive face to face sync ups. So I’d like to thank Christian and especially Michael for their great efforts in patiently answering bypasser’s Gnome questions at the booth, while I wandered off to talks or had technical discussions in its back.

I’m really excited to see how well the Ruby (on Rails) community have received Git. A big reason is probably the awesome service GitHub but there are several other goodies coming out from the Rubyists.

Yesterday I blogged about the GitCasts and today I learned about Gitjour. It’s a tool to announce and make available repositories over Bonjour so that you can list and clone repositories available on the local network.

To serve a repository simply call:

$ gitjour serve
Registered gringo.  Starting service.

You can then list and clone it with:

$ gitjour list
Gathering for up to 5 seconds...
=== gringo on Tabasco.local. ===
  gitjour clone gringo

Share This

Stumbled over the site GitCasts which publishes regular screencasts about using Git. Should be worth a look for anyone who which to learn more about Git.

http://www.gitcasts.com/

Share This

Was playing around a bit with the Twitter4R library the other day and realized that in order to make it to work on Mac OS X (Leopard) you need to also require ‘time’. Or you will get an error similar to lib/twitter/model.rb:268:in `init’: undefined method `parse’ for Time:Class (NoMethodError).

A small snippet to display my public tweets:

require 'rubygems'
gem('twitter4r', '0.3.0')
require 'twitter'

# Required on Mac OS X Leopard
require 'time'

twitter = Twitter::Client.new

hallski_timeline = twitter.timeline_for(:user, :id => 'hallski')

hallski_timeline.each do |status|
  puts status.text
end

Share This

“We don’t want the user to think about the theme too much, we want the browser to perceptually fade away so that the user can focus on what it is they are actually doing. In a sense it is a little ironic, the harder we work to make Firefox fade away the less likely it is that the user will notice the amount of effort that has gone into crafting the interface. However, the very best user interfaces go completely unnoticed, that is what makes them good.”
Read the rest

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.

Rapicorn 8.4.0 has just been released to the world: Rapicorn v8.4.0 Announcement

Lots of things have happened since the last snapshot over a year ago, some of which kept me from making releases or snapshots earlier. ;-)
Others actually took place in the code base as interesting developments, summarized below.

There’s quite some more stuff in my development queue, but at some point one just has to draw a line and throw out what’s vaguely ready so far, so this is it for today:

  Overview of changes in Rapicorn 8.4.0:

  * Changed versioning scheme to YEAR.WEEK.REVISION.
  * License update to GNU LGPL 2.1.
  * Added a publically installed tool: rapidrun
  * Support println() and close() commands in GUI files.
  * Introduce simple Application and Window object APIs.
  * Merged libbirnet into Rapicorn as librapicorncore.
  * Implemented expose region merging/comprssion.
  * Reiimplemented rectangle gradient shader.
  * Switched to autogenerated ChangeLogs.
  * Improved feedback on parser errors.
  * Fixed Gtk+ version checks.
  * Added PNG saving support.
  * Removed PERL build dependency.
  * Rewrote asyncronous main loops.
  * Many improvements to text editing areas.
  * Speed up blitting logic for local displays.
  * Added SIMD optimized rendering functions for MMX CPUs.
  * Fixed some reference counting issues and child removal.
  * Improved vertical text ellipsization to line granularity.
  * Removed error prone default values from property mechanism.
  * Install tutorial under ${prefix}/doc/rapicornXXXX/tutorial/.
  * Misc compiler and threading fixes, depend on g++-3.4.6.
  * Lots of bug fixes, cleanups and improved test coverage.

As Thomas and Andrea already mentioned, we’re running a GNOME wallpaper contest.
We had lots of great submissions already, but we really want yours as well. Go on, submit it today!

Last week I sat down and wrote bindings for Loudmouth. This means that anyone who want to write an XMPP enabled application with GTK+/Ruby now have an asynchronous library that integrates perfectly with the GLib mainloop.

It also gives me access to testing and writing small scripts using Loudmouth with the beauty of Ruby.

Here is a small example showing the bindings in the current state:

require 'loudmouth'

conn = LM::Connection.new
conn.jid = 'myjid@mydomain.com'

conn.open do |open_result|
  if open_result
    conn.authenticate('username', 'password', 'resource') do |auth_result|
      if result
         puts "Authenticated, do your stuff"
       end
    end
  end
end

GLib::MainLoop.new.run

So far I have only bound the asynchronous calls and I am not sure whether I will bind synchronous ones in the future.

If you want to try them out or even better, help out by improving them or write example code. Create an account at Github and watch/clone the repository. It’s named loudmouth-ruby.

Share This

I ran into a slight problem when I tried to create a type registered subclass in Ruby/GTK+. This is done by adding type_register in your class definition. This worked fine until I tried to pass arguments to the super class constructor through the super() call.

In my previous example, I passed the arguments like usual to the super call. It turns out that when you have registered your class with the GObject type system (which I didn’t do in that example) it overloads the super() call and you need to pass the arguments as a hash instead.

Here is an example subclassing Gtk::Button that sets the button up defaulting to underline mnemonics.

require 'gtk2'

class MyButton  Gtk::Button
  type_register

  def initialize(label)
    super({:label => label, :use_underline => true})
  end

  def signal_do_clicked(*args)
    puts “Clicked”
  end
end

w = Gtk::Window.new

b = MyButton.new(”My _Button”)
w.add(b)

w.signal_connect(:delete_event) do
  Gtk.main_quit
end

w.show_all
Gtk.main

Kudos to Kou for showing how to do it.

Share This

Guess most people have seen this by now but being on vacation last week I just managed to catch up and read the Ars Technica article “Reinventing GTK: envisioning the future of the toolkit” which is a nice and well informed summary of discussions that have been going on around GTK+.

If you haven’t already, you should read it.

Share This

As Andreas already blogged about, we got a new website up now.

It’s been under work for quite some time now and finally got the finishing touches to make it go live.

If you haven’t already, go check it out!

Share This

As requested by Mr. Andersson.

In his last post, Murray writes that GtkTreeView calls gtk_tree_model_iter_next() for every row. This is indeed true, for the simple reason that the internal state keeping of GtkTreeView needs an exact internal representation of what is being displayed. This representation is in the form of an RB-Tree, wherein there is a node for each visible row. The definition of visible that we use here includes all nodes that are outside the current scroll area that is being shown. Visible distinguishes collapsed and expanded nodes from each other. Each node in this RB-Tree contains the properties of that row, such as its height, is it a parent or not, is it selected, etc, etc. In order to build this tree, we need to iterate over all nodes in the model, hence that iter_next() is being called for all these nodes. Even for a million rows this is not a problem, building the RB-Tree is quite a fast operation. This has all been discussed at length recently at gtk-devel-list: see here.

The main performance problems have always been the measuring of all rows, which is something you can avoid by using fixed-height-mode. A lot of people have heard about me working on some experimental tree view improvements, this is also true. In my experimental branch fixed-height-mode has been removed, since the need for validating all rows has been removed. It can handle 4 million rows just fine.

So, do we really have to put the entire model in the internal representation? This is actually an unanswered question. It of course greatly simplifies the implementation of GtkTreeView, but nobody says that it would not be possible to modify GtkTreeView in such a way that this is not required anymore. I haven't looked at this in depth myself yet, maybe at some point in the future when I have time and finished studies and and and ... (I spent a lot of time on University stuff these days, it has been years since I have been so much motivated to work on finishing studies).

While Philip and Jürg's ideas on iterator types and GtkTreeModel improvements are certainly interesting, it is not a (complete) solution for this particular problem. It will especially easify the implementation of data sources/tree models and their testability. The solution for large data sources is really in the view part and not (so much) the model part.


Time for more Minix hacking now ...

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.

Recently I set up a new blog for GTK+ to document releases and for people to blog about cool new things in GTK+. So far, there is just Andreas and myself on the blog. So if anyone else wants to be added just let me know your blog email account and I will set it up. If you have been missing the GTK+ project news, don’t forget, it can be see at http://planet.gnome.org/news/, it is not shown on the regular http://planet.gnome.org/.

Andreas has been doing a great job chasing up some final issues on gtk.org, mainly with regards to the language bindings. Andreas has now removed all bindings that have no support for 2.6 and above and all bindings which are supported by GNOME are illustrated nicely too. So, if your language binding isn’t listed there and you know it is supported, please let us know on the gtk-devel list so we can rectify the pages!

We silently launched the new imendio.com website a little more than a week ago. It feels really nice to finally have it out in the public, being quite a while in the works.
Working from the initial design by Stefan at Pixelperfect we now have a site that better reflects what we do and defines a style we can build upon for a long time to come.

Oh, and Code is Art!

One thing that came up during the Art Meeting last week was that while the art team get lots of request for artwork, it’s really hard to keep track of them. Some are requested in Bugzilla, some on mailing-lists and some are individual requests to artists on IRC, via e-mail or on a conference. Things get forgotten and developers end up wondering if we didn’t want to do it, are too busy or simply forgot about it (often it’s a combination of option 2 and 3).

At the same time, new artists that are interested in helping out with GNOME artwork have a hard time figuring out where to start.

To fix this, we have set up a page in the GNOME wiki called Art Requests, heavily inspired by both Fedora Design Service and Tango Fridays.

Developers: Please add any artwork requests if you have something you need help with.

Artists: Pick a issue you want to work on and add your name to it.

Our art meeting yesterday went quite well and we got a lot of stuff put down that should keep us busy for the next six months. Thanks everyone attending!
GNOME artists are a chatty bunch apparently, so we didn’t get around to discussing everything we wanted before people fell asleep or had to leave for dinner. Therefore we’re going to schedule another meeting sometime soon in the future.
Meeting notes and a raw log can be found on the page GNOME wiki.

I previously wrote about Mac integration for GTK+ applications, and another important part of that is to create app bundles. An app bundle is a self-contained packaged up version of your application that can be distributed easily and put wherever the user wants by using simple drag and drop. This is a very common way of distributing applications on Mac.

To make it easier to create such packages of GTK+ applications, we have created a tool that does most of the work. All you have to do is to setup a small configuration file that points the tool to your binary and any data files that you want to ship. All dependent libraries are sucked in automatically. The application must be able to find its data files dynamically of course, since there is no hard coded path where it will end up.

You can take a look at the bundle file for Gossip for a quite simple example.

I have some plans to add support for dragging in frameworks and not just libraries, and to add better support for translations and other specific resources.

Thought I better blog about this as well, just to make sure people don’t mix up the dates (hi Jakub!)

We’re going to have a GNOME Art Meeting on IRC Friday 28 March 18.00 UTC
in #gnome-art on gimpnet where we hopefully can discuss what we want to
do during the 2.24 release cycle as well as further down the road.

Hope to see as many of you there as possible!

I finally found the time on Monday and Tuesday to set up Drupal for the new Monkey Bubble website. After migrating most of the content, we added forwards from the old page to the new one (thanks, Jeff, for adding our news feed to Planet GNOME News).

Unfortunately, there's still one part lacking on the new website: it's using the default drupal theme. So if someone could pick up the old monkey-bubble theme and provide a version for Drupal 5.x, that would really rock.

In the mean time, really nice things are going on in Monkey Land. In January I merged the maemo-port of Monkey Bubble into upstream (thanks Jouni, for providing the port). These days are spent refactoring the audio engine to finally start working properly (that means: audio + sound effects - hick-coughs - memory leaks).

Tim Pritlove hat heute Nacht die Chaosradio-Folge hochgeladen, in der Tim Janik und ich zu GTK+, GNOME und FreeDesktop.org interviewt worden sind. Ein bisschen schade, dass uns die Zeit ausgegangen ist, aber vielleicht gibt's ja nochmal eine Fortsetzung…

It’s not only in the upstream GTK+ project that there has been a lot of happenings lately. The Ruby GTK+ bindings team got a new maintainer after the old maintainer Masao Mutoh decided to step down and turn the reins over to .

Kouhei seems set on doing a new, much anticipated release of the bindings as soon as possible. The last release was done over a year ago (2006-12-29) and a lot of improvements have been done after.

I’d like to extend my thanks to both Masao and Kouhei for their efforts and willingness to take care of maintaining the bindings for this excellent language.

I also raised the question about moving the project over to GNOMEs infrastructure to get closer to upstream development and make it easier for people to participate. The suggestion seems to have been well received and many have said that they would love that. I’m pretty sure it would put some more light on the project and help the continued development positively.

Share This

In some of the feedback we've received so far we feel that some of the points on the slides have been misunderstood. All people that haven't been in Berlin of course miss a part of the story, since the bullet points don't tell it in full. We've just done some more touches to our paper describing our vision on the GTK+ and you can read it here. As you can imagine, the paper is much more elaborate than the slides.

If there are more questions/suggestions after reading the paper, be sure to let us know!

To celebrate the 2.22 release of GNOME, we’ll be meeting up on Friday 19.00 at Flygarns Haga in Gothenburg. I’ll buy the first round. Everybody is welcome!

This is a reply to some comments on Kris blog post about our vision of GTK+ 3.0.

First off, as I said in my reply there, I think it’s important that we do not make GTK+ 3.0 into a holy grail of all the features we would like to see in GTK+. There will always be features lined up that would make sense to push in, some which will change fundamental things in the core.

The way I see it (which Havoc seem to as well) is that a change of the Widget core to a scene graph is a project that will take place outside of the GTK+ tree and at some point get endorsed and included. This is a process that is likely to take several years and I do not see any reason to put GTK+ on hold, waiting for it.

There are still things that can be done on the GTK+ 2.x tree without breaking ABI. However, it is getting harder and harder (in some cases already impossible) to do it in a compatible way. A tremendous effort is put on figuring out all the places that can possibly break external ABI due to an internal change.

Mind though that this is not only the case when it comes to new features but also day-to-day maintenance is suffering from this with several bugs that can’t even be fixed today.

GTK+ currently exposes a huge amount of internal implementation details which blocks cleaning up of internal code, something that is much needed. This is not only for code beautification, in fact, the reason is that it’s a necessity in order to maintain the toolkit.

Why do we propose to break ABI now and not after features X, Y and Z? Because we want to do the break at a point where users will not have to make any logical changes to their code (as long as they are not using deprecated widgets or functions).

For applications being fairly up to date it will be a matter of recompiling with the right set of flags and then let the compiler do its work and fix the places where it breaks. Our plan for this is the introduction of the GSEAL macro that will let you compile your application with:

  CFLAGS="-DGSEAL_ENABLE -DDISABLE_DEPRECATED" ./configure

This will make the compiler catch all uses of direct access to the object fields so that you can go through them one by one and replace them with a call to an accessor function instead. This can even be automated in many cases and Johan tried it with some nifty regexps yesterday which seemed to work fine.

The changes will in a majority of the cases be:

  Bar *bar = foo_get_bar (foo);

instead of:

  Bar *bar = foo->bar;

After we have done this we will have an API consisting only of functions which means that any compatibility glue code we need to write can be done without the risk of variables being accessed directly and circumvent the compatibility layer. This is in the fundamentals of OOP practices and I believe that it’s a price well worth paying.

More over, since 3.0 is not going to be a feature release there is no need for applications to jump on it right away, they can use that period to do any transitions needed and be in position to reap the benefits with the ABI compatible 3.2 feature release.

Will we have to break again in the future? Of course! That’s what 4.0 is for and we propose that we already at the release of 3.0 decides when 4.0 is planned to be released so people know when deprecated code will be removed.

Michael wrote in Kris blog that we shouldn’t discard incrementalism, and this is the exact same feeling we have. We need to do things incrementally, but that doesn’t mean things can or have to always stay 100% compatible, only that the changes are small to ease the effort of following them.

In summary our proposed solution is an enabler for incrementalism.

Share This

People here figured that today is GTK+'s 2.0.0 6th anniversary, woo! We go to celebrate this later tonight. Today most of the talks have been about introspection. I spent some time talking with ebassi and jdahlin where they showed me the "simple tree view wrappers" that exist for perl and python. Both seem to be similar and very nice. Hope to look into creating something like this in C soon (maybe this week still?) to make the simple uses for GtkTreeView much less time consuming to program.

My hacking project seems to be progressing nicely. pixbuf-demo is running fine already with all graphics properly loaded via CoreGraphics. It loads photoshop files nicely as well. Next steps are getting it to do progressive loading and support animations and then a first version should be ready to hopefully commit in trunk. After that I will look into getting saving support done :)

Almost everybody had some boss that was too exigent about how you spend your work time, but this time it got too far! This is the backtrace I’ve got from epiphany several times:

Program received signal SIGSEGV, Segmentation fault.
...
(gdb) bt
#0  ephy_node_db_is_immutable (db=0x854f2c0)
at /build/buildd/epiphany-browser-2.22.0/lib/ephy-node-db.c:174
#1  0x080a7ad9 in resolver_found_cb (resolver=0x8507240, interface=3,
protocol=GA_PROTOCOL_INET, name=0x951d5d8 "Richard Hult“,
type=0×9229338 “_http._tcp”, domain=0×9705e98 “local”,
host_name=0×9166308 “Celery.local”, address=0xbfa12944,
port=<value optimized out>, txt=0×883a960, flags=4, data=0×8547620)
at /build/buildd/epiphany-browser-2.22.0/src/bookmarks/ephy-bookmarks.c:979
#2  0xb7f86fbf in ga_signals_marshal_VOID__INT_ENUM_STRING_STRING_STRING_STRING_POINTER_INT_POINTER_INT () from /usr/lib/libavahi-gobject.so.0
…

Please, at least let me browse API docs and repositories, I promise I’ll behave!

So we are in Berlin now with a good amount of people for the hackfest. The apartments are nice, the wireless is working out fine so far and there are plenty of snacks and beer. Though we seem to have run out of beer already, but I heard rumors it's going to be fixed soon ;) One problem is though that the weather outside is too nice to actually sit inside all day and hack. However, it looks like this is going to change Tuesday/Wednesday.

This morning we started with presentations after we finished transforming one of the living rooms into a "theatre". Everybody just fit in the room and it's a pretty funny sight :) I had the honor of starting off the presentations track this morning. I think a lot of people have actually been thinking about the future of GTK+; what new features to add and how to move forward. We hope to have a lot of discussions about all these ideas everybody has. At Imendio we've also been thinking about where we want to go with GTK+. We presented our "vision" on GTK+ during this mornings presentation; my slides can be found here. We hope to have more discussions about this this week. Later on we will post a document with a more elaborate description of these ideas.


As for hacking, I was recently inspired by dom's and arc's GDI pixbuf loader. For this week I've decided to do something similar for Mac OS X. The CoreGraphics framework has an ImageIO library with loading and saving support for a lot of image formats. I hope to get a pixbuf loader using this running during the hackweek. It will greatly simplify the build process for GTK+ on the Mac as well as shipping applications.

Lennart found the asm code in FreeBSD that makes GNU ld give a warning when using certain functions:


diff --git a/display.c b/display.c
index 24bba79..a0376f2 100644
--- a/displ