Month: March 2008

Posted on

Time to Build

Claudio did some interesting profiling (and patching) of the BookmarkFile implementation in GLib — so kudos to him and Felix.

one thing that he noted is:

However, I still have the feeling that letting ~\.recently-used.xbel grow without control is very, very wrong. In my laptop, this file is about 5MB, which accounts for ca. 9000 files(!).

this is very true, but I feel it needs some context. when I first wrote the RecentManager code I only had the EggRecent implementation as a comparison; the old EggRecentModel had an hardcoded limit of 500 items stored per file. limiting on the number, instead of the age of an item inside a recently used file list did not feel right, so I thought about hardcoding a limit of 30 days — but stopped short of doing it because I realized that hardcoding limits at the toolkit level was not a good idea:

  • application developers will not be able to change it in any way
  • users will not be able to change it in any way
  • system administrators will not be able to change it in any way

just to give a few examples: while I was still writing the RecentManager inside libegg, Alex Graveley was writing Gimmie. Gimmie had ((and might still have — I haven’t checked it for a while now)) a local document and application history that could allow you to go back in time of months; had I hardcoded a limit, the Gimmie developers would have needed a new implementation, defeating the purpose of shipping the RecentManager inside GTK+ to cut down the amount of code replication.

hardcoding limits is also something that makes it hard, or even impossible, for users and administrators to control; I might want a 30 days limit, but other might want a 90 days, or a 7 days — or even a 1 day limit. some might not even want to save the recently used files at all (think kiosks).

I don’t believe in strictly hardcoding policies in the toolkit; providing fallbacks is perfectly fine, but preventing people from actually having different settings is akin to convince everyone that you’re right and they’re wrong.

still, this doesn’t solve the problem at hand, that is the current lack of policy.

what I’d like to see is some process taking care of purging the old entries, using some key inside gconf, at the end of the session; gnome-settings-daemon would fit the role for GNOME, and other desktop environments using GTK+ could provide the same functionality ((if you’re not using a GTK+ based desktop environment you’re either using the same spec used by GTK+ so you can provide your own way of purging the cache, or you’re using another way to store the recently used files, so the size of the file saved/read by the RecentManager will not bubble out of control so easily — and you can still flush it yourself)). after all, gnome-settings-daemon should already flush the thumbnails cache — it wouldn’t be much of a complication.

Posted on

Berlin/Final

some final thoughts on the Hackfest: it has been a great opportunity for discussing with all the usual suspects and more, and on a very high bandwidth channel — unlike IRC or the mailing list. definitely, an experience that must be repeated next year, because the discussions we had and the work we started will keep us all busy at least until GUADEC — and from then on, towards a very bright future for GTK+ and the whole GNOME project.

thanks to Mathias and Openismus for being the local organization; thanks to Tim, Kris and the entire Imendio, for moderating the whole panels; thanks to Vincent and the GNOME Foundation, and obviously all the sponsors, for helping out in organizing and funding this gathering of hackers; and thanks to everyone that made these five days an incredible experience for me: you all really rock the GNOME community.

Posted on

Berlin/5

last post of the Berlin Hackfest series, written on the last minutes of day 5

today was “wrap up” day. we got together in the room used for the presentations and summed up all our work during the various sessions of the week. it turned out that the amount of work, even though not reflected by the wiki page, was really enormous; the introspection guys worked a lot and now that they have received a lot of input, they are going to rework things and kick ass even more. apparently, Behdad decided that I would tackle the GL integration inside GDK — which, of course, I’d really like to do; the GL integration, and a GDK wrapper for the GLX_texture_from_pixmap (and the equivalent call for the other platforms) would obviously be the primary way to integrate Cairo 2D high quality drawing and GL 3D and hardware acceleration in a simple way. and this is a step forward the implementation of a scene graph inside GTK+.

in the meantime, I’m — as Ryan would put it — deeply recursing. it all started on tuesday, when I decided to start hacking on a real application with Vala using all the bits and pieces a modern GTK+ application requires: GtkUIManager, about dialogs, command-line switches. the application was supposedly going to read the new GTest framework reports, and allow comparing of multiple runs in a fast way. this, in turn, led to some bugs filed against Vala GTK+ bindings. working around these issues, I also found out that the libxml-2.0 bindings in Vala — which I need to parse the GTest report XML — require a lot of pointers usage and are, in general, quite sub-obtimal, due to the very C oriented API. while investigating on a substitute, I found out XmlReader — the cursor-based XML traversal API that .Net and other high-level languages implement ((Even libxml-2.0 implements it, even though it suffers from the same issues of its DOM API, and it’s still not GObject-based)). Thus, today at a coffe shop ((Behdad is right: a coffee shop without any Internet connectivity makes wonders with your productivity levels)) I started hacking very quickly on a rough implementation of a XmlReader GObject class which, as of at this moment works quite nicely:

  XmlReader *reader = xml_reader_new ();
  GError *error = NULL;

  if (xml_reader_load_from_file (reader, "book.xml", &error))
    g_error ("Unable to parse book.xml: %s", error->message);

  xml_reader_read_start_element (reader, "book-info");

  xml_reader_read_start_element (reader, "author");
  author = g_strdup (xml_reader_get_element_value (reader));
  xml_reader_read_end_element (reader);

  xml_reader_read_start_element (reader, "title");
  title = g_strdup (xml_reader_get_element_value (reader));
  xml_reader_read_end_element (reader);

  xml_reader_read_end_element (reader);

  g_print ("The author of %s is %s\\n", title, author);

  g_free (title);
  g_free (author);
  g_object_unref (reader);

and you’re done. at this moment, I’m cleaning it up and adding the gtk-doc API reference to the build ((When I write new libraries, I usually stub out the API and document it at the same time; now I started to add the GTest units before I even implement the API)). I’m probably going to add the generic read() method, so that:

  while (xml_reader_read (reader))
    {
    ...
    }

will work as expected. it’s, as usual, code replication — but I’m going to need it anyway, so it’s good code replication.

Posted on

Berlin/3

second and third day of the hackfest, edited on day five

on tuesday, Behdad and I started working on OpenGL integration inside GTK+. as stated multiple times on the Bugzilla entry, what we both would like is a Cairo-like integration of GL inside the available drawing systems in GTK+. in short: not a specialized widget like GtkGLArea, which would make it difficult — or plainly impossible without jumping through a long series of hoops. in flames. tied. and blindfolded — to integrate GL inside existsing projects; and not the incredible API dump that GtkGLExt is.

the design we mostly agreed on was a shared object inside GTK+, containing the GL context abstraction object, and two simple calls to delimit the drawing code, wait for vblank and swap the GL buffers. plus, an easy to use wrapper around the texture_from_pixmap extension, to allow drawing with cairo on a Pixmap and then have it pushed into the GL pipeline.

Carl arrived on wednesday, and partecipated at the scene graph BoF we held. the BoF itself was pretty straightforward: we read the slides that Havoc sent on the mailing list and discussed the various points. we all agreed on a lot of points — and we tried to define the problem space more deeply ((We did not always succeed in this, but the issue at hand is quite large and it’s understandable)). being there, I could bring to the table my experience in the past two years ((It’s really two years? holy crap! The time really flew…)) with the design and implementation of Clutter. some of the attendees were already familiar with it — something very satisfying — and I could expand some points in Havoc’s slides about Clutter that have been recently fixed or are going to be fixed in this cycle. the biggest point is that the scene graph should integrate with Cairo, in order to allow applications and people to gently merge both the 2D drawing of surfaces into a full 3D environment; I’ll leave to Carl to explain the Cairo side, because he’s obviously better at this than I am. :-)

the operative result of the scene graph discussion was that Clutter emerged as an already powerful and established solution for this problem space, and given that it already nicely integrates with GTK+, we can work towards the common goal of making it “the GTK+ canvas”, outside the actual library so that it can grow unrestrained and experiment in new directions.

Posted on

Berlin/1

day two of the gtk+ hackfest.

yesterday was devoted to the Imendio vision of a better toolkit, and how to get out of the hole we dug for ourselves with the current API/ABI contract – but others have written about it better than I could possibly do.

today was introspection day; Johan Dahlin showed the current state of the GObject introspection code by using a Vala widget, subclassing a GtkDrawingArea, from a Perl script — which was beyond cool. kudos to everyone that has been working on it.

today it’s also six years since the gtk+ 2.0.0 release, so happy birthday gtk+ 2.x!

Posted on

Berlin/0

just landed in Berlin, for the GTK+ Hackfest. At the moment, I’m hanging out in the dbus/gsettings/gdata/gtkapplication room with desrt, MacSlow, gicmo, chpe and herzi waiting for somebody (and I’m looking at you, behdad) with a key for my room to get in.

Posted on

Let It Take You

Murray, just a short reply to your points:

I sometimes feel I’d like to just put actors on a rail, twist that rail about, connect some actors together with struts or springs, start them moving, let the user push and pull them around within constraints, and trigger extra behaviour when they reach certain positions, or reach each other.

What you want is a physics engine hooked up into Clutter; it’s possible, Pippin has been doing some preliminary work on it, and it would solve the more “physical” interaction model. But it’s not always what you want your UI to look like and it’s not always a good model to employ, especially if you cannot interact physically with the UI – like shaking it, rotating it, use multi-touch surfaces.

Clutter is now a very basic API.

You make it sound like it’s a bad thing. Well, it’s not: it’s exactly what we want it to be like. No constraints on the UI structure or behaviour — those belong to toolkits developed on top of Clutter. Like Tidy, which is a shared library (it even installs a pkg-config file), but it will not be released as a tarball because we’d like to keep it as an experimental ground, read: breaking stuff, to see how and what should Clutter provide to implement an accelerated and animated toolkit. Also, as you note, in embedded environments you’ll want to style and create your entire stack: instead of raping and twisting GTK+ themeing until you don’t know that you’re using GTK+ anymore — and losing a lot of time in the process — you can use a standard low level API and develop your toolkit on top of it. It’s not optimal, but I think it’s a step in the right direction to make the GNOME mobile stack a lot more useful and flexible.

Neither you or Clutter should want to reimplement the huge amount of UI logic that is, for instance, in GTK+

That is why you can embed Clutter inside a GTK+ application, and hopefully you’ll soon be able to embed GTK+ widgets inside Clutter.

In short: Clutter was never meant or designed or developed to be a complete replacement for GTK+ on the desktop. On the desktop is an API for allowing hardware accelerated UIs embedded into current applications (photo slide shows for Eog; music library browsing for Rhythmbox; login user browser for GDM; and these are just the first items that come to mind). In the mobile environment arena, Clutter is meant to be used as a cornerstone – along with GLib, GStreamer and the rest of the GNOME mobile stack – for developing a new kind of UI, where the desktop guidelines and style don’t apply.

Posted on

Failsafe

About JSON-GLib: things have gone quiet on that front, but lately I’ve resumed working on it ((In a couple of separate branches, for the time being, but when those are ready, they will be merged back into master and will be released as 0.6.0)).

I decided to try the new GLib test framework that has landed in the 2.15 cycle; GLib and GTK+ are both already using it, and now a branch of JSON-GLib is GTest-powered. Setting it up is not hard – but it requires some changes in the build environment. The API is quite straightforward — just call:

  g_test_init (&argc, &argv, NULL);

inside your main, then add the test functions with:

  g_test_add_func ("/test-section/foo", test_function_foo);
  g_test_add_func ("/test-section/bar", test_function_bar);

and finally run the test using:

  return g_test_run ();

which will return the exit code used by the gtester program to determined whether the successfully test passed or not.

The test suite is built along with your library or application, but run only with make check and make distcheck. There’s also an automatic report generator which will dump an XML file with the results, which you can then parse to create HTML pages or other forms of report. The rest of the work is putting a set of pre-cooked declarations for the Makefile templates into the root of your project; including it in every Makefile.am file; create some tests directories; and dump there the test units. I bet that Anjuta or other IDEs with autotools support can be tweaked to do this stuff for you.

JSON-GLib is now using GTest to test the data types API (for the time being, Array and part of the Node) and the Parser behaviour; nothing very complicated, at first, but it’s good to have it all automated and a simple make away. Adding new test cases to exercise the whole API will be the priority in the next weeks.

Posted on

The Laws Have Changed

This week I got an invite for trying out Github beta. Github is a nice service providing some space and tools to set up git repositories for open source projects.

Obviously, setting up HTTP (dumb) read-only git repos is doable on any box connected to the intertron by merely copying the repository; the nice bits of working with git, though, like pushing branches and tags, or fast cloning through the git: protocol are somewhat harder to set up, so anything that relieves you from actually doing this kind of work should always be welcome.

Github not only provides you with that: it also gives you an incredibly nice web interface; a wiki; the ability to easily track other projects through RSS feeds; the ability to easily set up a “fork” of another repository, thus easing the pain of setting up personal development repositories for contributors.

I decided to try Github by moving there JSON-GLib‘s development git repository, plus some branches and the release tags. The operation took me approximately ten minutes, including the account creation, and it was all very easy and very well explained.

At the moment, Github is in beta ((If anyone is interested to try it, I have two invites an invite left to give out invites are now all gone)) and there are lots of projects starting out; if anything happens, cloning out with full repository history is also a nice feature of git, so I guess that side is covered as well. Bugs and feature requests are now handled using wiki pages, so if I’d have to make a request to the guys at Logical Awesome then it would be: dudes, move to a serious bug tracking system – wikis don’t scale for that (believe me: been there, done that).

All in all, it’s a great service – the way SourceForge should have been, if technology allowed it at the time and if they didn’t choose to reimplement the damned BTS and mailing list archives with something that can only be described as “made of fail”; and if they plan to make me pay a reasonable fee, it’s fine for me: Github’s UI alone is worth it.