courtesy of Ulisse Perusin, Tweet now has a rocking icon.

since 0.2 has been released, I’ve also added:

• a status icon to show error messages and the number of new statuses inside a tooltip; when clicking on it, it will bring up the Tweet window and, more importantly, it will disappear until the next update.
• key navigation, which required a new release of Clutter-GTK
• better word wrapping and dimensioning of the cells in the ListView
• open up the browser when clicking on the user’s icon in the status information overlay

there are still features I’d like to work on before 0.4.0, but all in all current HEAD of master looks fairly stable and useful. if everything goes according to plan, I’ll spin 0.4.0 before GUADEC, and 0.6.0 after I port Tweet to the new shiny Clutter 0.8 API.

well, not anymore: Tweet on GNOME Live

complete with a screenshot of the new UI, as suggested by Matthew Allum:

first of all, now Tweet has an authentication dialog which allows you to enter your username and password the first time you run it:

and even verify them beforehand:

then you get the list of statuses from the people you’re following:

you can scroll around using your mouse, and tap a row to get more informations about the status and the user:

click on the screenshot…

as you can see, the UI is geared towards the touchscreen usage, but I plan to add key navigation soon.

still, there’s a lot to add: support for viewing your own statuses, direct messages, the list of people you’re following and the people following you — even the error messages are just printed to the console, even though I’m working on that.

the bits I’m most proud of:

• the GTK+ integration: I’m retrieving the style information straight from the GtkWindow embedding the Clutter stage, and even if I had to fight with the utter mess that is the themeing code, I was able to gather enough to make Clutter play nice with a GTK+ environment¹;
• the small animation API I implemented on top of the Clutter animation framework, requiring a single function (plus two completely generic classes) to tween an actor between two states; for instance:

  tweet_actor_animate (info, TWEET_LINEAR, 250,
                       “y”, tweet_interval_new (G_TYPE_INT, y + padding, 100 + padding),
                       “height”, tweet_interval_new (G_TYPE_INT, 10, (height - (100 * 2))),
                       “opacity”, tweet_interval_new (G_TYPE_UCHAR, 0, 196),
                       NULL);
  

  this is the code that animates the status information actor that appears overlayed on top of the status view²; I’d like to thank pippin for the idea about the API behaviour;

• Twitter-GLib, the generic API for accessing Twitter throught its RESTful API, which thanks to LibSoup has been a breeze to write even in a clunky and not-at-all-web-two-point-oh-buzzword-compliant language like C;
• the fact that Tweet is written in a very reusable manner (apart from the base scrollable list which comes from Tidy), with every piece neatly abstracted into its own class.
• finally, the fact that after almost a year of basically working on libraries only I can still sit down and get an application from scratch to a usable state in a couple of weeks in my spare time — even if I have to write a library to get it done.

by the way: is any artist out there interested in making an icon for Tweet? I really would like to avoid using Twitter’s own icon.

1. in the screencast the scrollbar handle color, for instance, comes from the theme as well as the font [↩]
2. this kind of utility API is easy to achieve given the power and flexibility of the underlying framework — but it obviously limits what you can and cannot do, and if you ty to coerce it into being more generic you start losing bits and pieces and a simple API starts getting in your way instead of helping you; that’s why Clutter’s animation framework might seem complicated at first: it’s trying very hard to allow you to build whatever animation you have in mind instead of limiting you [↩]

debian: with the release of Hardy I decided to switch back to Debian after three years of Ubuntu. even though there are still some rough edges in Lenny, the support for laptops has definitely improved a lot and so I got back to my old love. starting from Gutsy, I found myself increasingly at odds with Ubuntu decisions and even though I upgraded my wife’s laptop to Hardy, I’m really glad I got back to Debian.

clutter/1: apparently, I’ll give a lightning talk about our reference toolkit for Clutter at this year’s GUADEC, in Istanbul. Øyvind proposed it for me because, regardless of being on the paper committee, I actually forgot the deadline for the CFP — whoops, maybe I shouldn’t have said that. with the Tidy lightning talk and the Clutter guts talk given by Matthew, we decided for a high-level/low-level approach, instead of going for the usual this is teh Clutter, look at teh bling kind of talk. if you want to understand Clutter, Matthew’s talk is definitely where you want to be; as we all know:

Clutter = Clean and nice API + Performance + Portability + Integration = ♥

from my Clutter talk at FOSDEM

so, if you want to know how Clutter creates love, get to Istanbul this July.

tweet: I started eating my own dogfood. Tweet is by no means complete or even guaranteed not to turn you into a goat and eat your breakfast — but now it works well enough for reading your own timeline and sending new statuses; and it doesn’t require trunk of anything any more, thanks to a Tidy transplant. I’m using Tweet as a way to see what kind of API is needed to properly integrate a Clutter canvas into a GTK+ application: colors, fonts, etc. if you want to try it out, contribute or just mock my insanity:

  git clone git://github.com/ebassi/tweet.git

clutter/2: we’re really close to a 0.7 release, which will mark the beginning of the slushy phase of the API; as far as documentation goes, we’re in pretty good shape already, at 93% for the Clutter namespace, and another 80% for the Cogl namespace. bindings will need to be updated — but the amount of new API is not that big, so it’s not going to be a long wait. I’m making a note here: huge success.

the actual amount of code is quite small, and it’s already available in Tidy.

challenges: Luca dared me into making a Clutter-based coverflow-like plugin for Rhythmbox, but it was Iain that picked the challenge up and wrote some basic code for it. I, on the other hand, don’t like coverflow for browsing my music collection, so I finally decided to write something for the Eye of GNOME — a Ken Burns effect slide show. it’s not at all finished, and if nobody picks it up, I’ll try and do my best to have it ready for GNOME 2.24, if EOG maintainers want it, of course. it’s not the best display of Clutter features — except the animation framework — but if you have hardware acceleration it will make slideshows look a lot nicer.

json-glib: this weekend I released the first developers snapshot of JSON-GLib 0.6; the API is stable, the test suite is rocking and this release finally fixes the last bit needed for full RFC 4627 compliance (Unicode escaping). I’m probably going to release 0.6.0 in a couple of weeks.

• use GIO to determine the MIME type of a URI, on every platform supported
• use the file monitoring API to avoid polling the storage file
• add a GtkSettings property for clamping the recently used resources list to a 30 days limit

more stuff I’d like to add is:

• small parser changes to GBookmarkFile, to reflect changes in the spec
• bulk addition, for applications storing multiple items when quitting
• new API needed to follow the usability review in bug 349541
• moving the RecentItem icon code to GIO, and add API to extract the thumbnail

twitter: I’ve been using Twitter a lot in the past two weeks; it’s nice, it makes it easier to copy and paste a quote or a thought, and the 160 characters limit is an interesting challenge. As it’s been ages since I last wrote an application¹, I decided to start writing a Twitter reader/writer — using GTK+, Clutter and Tidy; without much thinking, I opened gvim and started writing code in C² — so, the obvious thing that happened was that I ended up writing a library yet again in order to use Twitter’s web API. luckily for me, libsoup has now a really nice API to work with; all you need is GET and POST to their RESTful API, retrieve the result, parse it through JSON-GLib, hide everything inside a new GObject and you have a wrapper around a web service. the application, you say? oh, I was sure I forgot something. well, it’s coming along — it just needs some work still.

1. lately all I’ve been doing was writing libraries [↩]
2. hey, that’s what I do for a living, it’s hard to switch off; plus, I could reuse some of the platform libraries [↩]

iain’s right: this is funnier than the history meme.

  git clone git://github.com/ebassi/unique.git

I plan to add back a new x11 backend for the 1.2 release, targeting small embedded environments were D-Bus might not be an option, and support for a --replace command line switch. after that, I’ll try to get the same functionalities into GLib/GTK+, as part of the future “desktop platform” module.

Clutter: I did a 0.6.2 release of both the core and the Python bindings, but things are afoot in trunk. we recently landed the multi-stage branch, which means that you’ll be able to create multiple windows and multiple GtkClutterEmbed widgets per application with Clutter 0.8. we’re also about to land the massive COGL rewrite that Ivan Leben of ShivaVG fame did — which will make the GL and GLES abstraction more powerful, will reduce the code duplication and in general will rock your world. Neil Roberts has been doing loads of work on the native Win32 backend: he not only made it possible to run Clutter on WGL, but also use the GtkClutterEmbed on Windows natively:

now, only the Quartz backend is missing the party — hint hint, nudge nudge.

OpenedHand: we’re hiring!

The hard bits are the animation framework, the event handling and down to the integration with the existing platform. A generic canvas is hard, and you probably don’t want it to be developed inside gtk+ (not even for 3.0) — just like Cairo is not developed inside gtk+ but supersedes part of gtk+’s API.

As for 3D acceleration — I’m obviously biased here, so everyone should take what I write with a graintruckload of salt — but I maintain my view that if GNOME (and Linux) started heavily pushing towards more support for OpenGL, then we could get more market share¹, more visibility and thus more leverage to make the currently closed source drivers more open. Intel understood this; AMD is now getting it; I’m pretty sure nVidia will — or they will be simply pushed into irrelevance by the open drivers developed by the community². Let’s face it: other platforms and toolkits are pushing heavily on hardware accelerated 3D effects.

Let’s start aggressively work to get the platform into the XXI century.

update@2008-10-11T12:21+0100 — just as a sidenote: if you have a good CPU, Mesa and software rendering, Clutter will work. It won’t be fast for some operations (like scaling and, possibly, rotating), but in that case you should probably start contributing to Mesa to make it fast (there’s a lot of room for improvement).

1. think Compiz, and how many more users it brought home just with a spinning cube [↩]
2. unless you are a gamer, and need the very best card as soon as it’s out just to play Crisis [↩]

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¹ 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². after all, gnome-settings-daemon should already flush the thumbnails cache — it wouldn’t be much of a complication.

1. and might still have — I haven’t checked it for a while now [↩]
2. 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 [↩]

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¹. Thus, today at a coffe shop² 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³. 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.

1. 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 [↩]
2. Behdad is right: a coffee shop without any Internet connectivity makes wonders with your productivity levels [↩]
3. 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 [↩]

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¹. being there, I could bring to the table my experience in the past two years² 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.

1. We did not always succeed in this, but the issue at hand is quite large and it’s understandable [↩]
2. It’s really two years? holy crap! The time really flew… [↩]

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

1. If anyone is interested to try it, I have two invites an invite left to give out invites are now all gone [↩]

GNOME-Love Boat, love exciting and new,
Come aboard, we're expecting you.

The GNOME-Love Boat soon will be making another release,
The GNOME-Love Boat promises something for everyone.

Set a course for adventure,
Your box's on a new romance.

And GNOME-Love
Won't hurt anymore,
It's an open source,
On a userfriendly shore.

it's GNOME-Love
Welcome aboard it's GNOME-love

Using the --silence hackery from Jacob Berkman I found a way to finally STFU at least libtool. In your configure.ac add:

changequote(,)dnl
LIBTOOL=“\$(QUIET_LT)${LIBTOOL}”
changequote([,])dnl

Add a Makefile.decls file to the root of your project, containing:

QUIET_LT = @echo ‘    ’ LIBTOOL $@;

And include it in every Makefile.am:

include $(top_srcdir)/Makefile.decls

This will silence all libtool invocations; you can make this all conditional, obviously: just sorround the QUIET_* declarations with if VARIABLE...endif and define VARIABLE using AM_CONDITIONAL in your configure template.

Now, I’ll just have to find a way to make gcc shut up¹, and so the saga will end with a third chapter.

1. no, you cannot redefine CC, as it will be invoked by libtool as well [↩]