I’d like to stress out that this is an alpha quality release; I’ve been using it for a while, now, and nothing serious like the destruction of my hard drive happened but I cannot guarantee that it won’t happen to you. you’ve been warned.

from the new-and-shiny department:

• use NetworkManager to detect a connection change
• scroll wheel support
• nice gradients on the speech bubble
• more readable datetime stamps on each status
• update the status view with just the new statuses instead of reloading everything

from the stuff-still-missing department:

• an icon — can I have an icon? please, pretty please with sugar on top?
• follow/unfollow users
• direct messages
• show a particular user
• show followers and following
• add a control to open a browser on the current status
• show error messages instead of silently failing

and finally, from the would-be-nice department:

• use Gypsy to update the location
• exporting the status archive

if you want to give a hand, just clone the repository:

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

and hack away!

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 [↩]

  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 [↩]

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… [↩]

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.

the Clutter talk on saturday went, in my opinion, quite well; lots of people listened to my ramblings and watched my simple slide show. about the talk: it was my first with a slightly modified Lessig method approach and I have to say that it’s been a very satisfactory experience - nonetheless because it removes the need to put slides online, which I never end up doing anyway¹.

1. I’ve got a git repository with the small application I wrote to give the talk with, so if you want it you can always ask me for the URL to clone [↩]

as some of you might already know, we have started working on a reference “toolkit” based on Clutter called Tidy.

Tidy is a simple library containing some useful actors and interfaces which can be used by applications developers; it aims to be simple and yet provide some high-level classes that Clutter won’t provide.

it is by no mean complete, or aiming to replace other toolkits; you can think of it as a reference implementation for a toolkit based on Clutter.

Tidy works as a standalone toolkit, but it can also be used as a copy-and-paste repository, like libegg for the gtk+ stack; because of this, it doesn’t provide any kind of API or ABI guarantee, and it probably won’t be released in form of tarballs. it can be seen as a constant work in progress.

right now, Tidy is composed of these classes:

• TidyActor - a base actor class, implementing stylable actors, with padding and alignment
• TidyButton - a simple button class
• TidyFrame - a container capable of aligning its only child
• TidyListView - a list view using ClutterModel to introspect its structure and contents
  • TidyCellRenderer - base cell renderer class
  • TidyCellRendererDefault - default cell renderer
  • TidyListColumn - base column class
  • TidyListColumnDefault - default column
• TidyTextureFrame - a texture that efficiently clones a background image so that it can stretch the entire size allocation
• TidyProxyTexture - a texture class that efficiently caches the source file
  • TidyTextureCache - a cache for textures loaded from on-disk data
• TidyTextureReflection - an actor using GL to compute a reflection of the parent texture (imported from the toys)
• TidyStylable - base interface for stylable objects
  • TidyStyle - storage class for a style
• TidyScrollable - base interface for scrollable actors
  • TidyAdjustment - object for clamping a value between two boundaries (with quantum increments support)
  • TidyScrollBar - scroll bar actor controlling an adjustment
  • TidyViewport - scrollable viewport controlled by a pair of adjustments

Update@2008-02-07T10:01Z: after this announcement, Chris added two new actors:

• TidyScrollView - a viewport with scoll bars
• TidyFingerScroll - a viewport with kinetic scrolling

Plus a lot of bug fixes.

there are examples for basically every class and functionality under the tests/ directory.

since everybody want screencasts these days:

this is still in the prototyping stage; meaning: if it breaks (and it will break) you get to keep both the pieces. also, there are rough edges and missing functionality. we’ll keep working on it and adding new classes between now and Clutter 0.6 (and after), and also use Tidy as a testing ground for Clutter functionality and staging ground for actors/data structures/interfaces.

you can check out Tidy from SVN using:

  svn co http://svn.o-hand.com/repos/tidy/trunk tidy

or browse the repository from your web browser via:

  http://svn.o-hand.com/repos/tidy/trunk/ (raw)
  http://svn.o-hand.com/view/tidy/trunk/ (viewcvs)

in other, Clutter-related news:

• Iain has been working on a Clutter and WebKit-based browser actor; you’ll find a very cool screencast of it on Iain’s blog.
• In Clutter trunk we landed initial support for FBOs and we’re fixing bugs/updating bindings/updating documentation toward the 0.6.0 release.
• It’s a bit old, but I’ve been updating the Vala bindings for Clutter and Clutter-GTK, so you can now use all the bling with Vala; you’ll need Vala trunk, but it’s worth it.

Last week I also went through the huge list of changes, additions and removals in the public API; the result is a collection of seven emails (1, 2, 3, 4, 5, 6 and 7) I sent on the clutter-list - complete of mistakes which I can only attribute to the amount of food, wine and beer I had during the Xmas break.

I’m incredibly proud of how much Clutter grew since the 0.4 release we did after GUADEC; the amount of bug fixes alone makes it worth to check it out - and the new features list is impressive. A lot happened, and a lot more will happen in the near future; some things are already here - but will be announced in due time.

As always, kudos to everyone that has helped by filing bugs and patches; started writing bindings; and last, but not least, contributed documentation.

• new event handling, borrowing from the W3C DOM event - that is, two event phases: capture, which traverses the scene from the stage to the actor that received the event, and bubble which traverses the scene from the actor to the stage. You can block the event chain in any point of both phases by simply returning TRUE in the signal handlers (like GTK+); kudos to mallum and Pippin
• improved text scaling, at least for downscaling at ~50%; kudos to Pippin
• build and test on win32 using the SDL backend, complete with VS2005 build files; kudos to tf
• time-based timelines, so you can define a ClutterTimeline by giving its length in milliseconds; and without even breaking the API.

Still, there’s plenty more coming - so keep looking at trunk.

JSON-GLib - The code base has been consolidated a lot while working on ClutterScript, so I feel confident about making a release of the out-of-tree repository. The release is bagged, tagged and signed as json-glib-0.2.1 in the git repository¹. You can grab the tarball here. Work on seamless GObject-JSON (de)serialization will continue in the master branch towards a 0.4.0 release. Update@2007-10-16T23:30+0100: obviously, as soon as I got back home and checked the repository I found two bugs in the generator code; hence, brown paper bag release 0.2.1. Tarball, documentation and tag updated.

1. As usual, at http://folks.o-hand.com/~ebassi/git/json-glib.git [↩]

Luckily, GNOME has Jhbuild, which is easy to set up² and also allows custom modulesets for handling dependencies inside a separate root - to avoid messing up your box.

So, if you want to play with Clutter, here’s two Jhbuild modulesets:

• clutter-0.4.modules - for the stable branch of Clutter, if you are developing applications
• clutter-0.6.modules - for the development branch of Clutter, if you want to contribute to Clutter itself, or you want to write bindings for it

Just download the moduleset file of the branch you want to use, copy it into the modulesets directory of the Jhbuild checkout and then:

  jhbuild -m clutter-0.4 build pyclutter

or, if you have a fresh checkout of Jhbuild, simply do:

  jhbuild -m http://folks.o-hand.com/~ebassi/clutter-0.4.modules build pyclutter

thanks to Frederic Peters for fixing remote modulesets and pointing this out

The command lines above will build the stable Python bindings for the stable branch of Clutter, fetching all the needed dependencies. If you’re stuck on some external dependency, though, feel free to drop into #clutter and ask for help³.

Update@2007-10-12T17:51+0100: I’ve added the following meta-packages:

• meta-clutter-core, depending on Clutter
• meta-clutter-suite, depending on meta-clutter-core, Clutter-GStreamer, Clutter-GTK+ and Clutter-Cairo
• meta-clutter-python, depending on meta-clutter-suite and PyClutter

You can use the meta-packages to pull in everything you need. As soon as I figure out a way to reliably depend on the other languages runtime environments, I’ll probably add their own meta-packages and a meta-clutter-bindings as well.

Have fun!

1. IRC: irc.gnome.org - join today! [↩]
2. the wiki page linked has it running in less than ten easy steps [↩]
3. be sure to specify which distribution you have [↩]