I’ve been asked to review the GNOME 3 Application Development Guide for Beginners; I went through the book in about half a day and wrote this somewhat short review afterwards, and published on G+; sadly, I used a limited distribution, and G+ does not allow changing that without resharing your own post. given that I wanted to push it on the blog, I took the chance to review some of the stuff I wrote, and expand it.

my initial impression of the GNOME 3 Application Development Guide for Beginners book is fairly positive: the topics covered are interesting, and the book never loses itself in them, so that beginners will not feel utterly stranded after the first three chapters, as it too often happens with “for beginners” books. I appreciated the “pop quiz” sections, as well as the small sections that recommended improvements to the example code.

obviously, writing a book enshrines a certain set of requirements and APIs, and that is problematic when there is high churn – like what happens in GNOME 3, especially in terms of development tools (libraries and applications) and overall experience. for instance, the section on Clutter (which is the one I can immediately give feedback on, given my position) still uses the deprecated “default stage”, and yet it uses the new ClutterActor easing state for animations; the default stage was deprecated at long last in Clutter 1.10, but its use was not recommended since the days of 1.0; the actor easing state API was introduced in the same release that deprecated the default stage. also, the example code published in the Clutter section does not use any of the layout managers provided by Clutter, preferring the fixed positioning of the actors, which is perfectly fine on its own; the book, though, then proceeds to mention the amount of code necessary to get something on the screen, compared to the equivalent code in GTK, that uses boxes and grids. in general, that’s an utterly fair thing to say: Clutter sits at a lower-level than GTK, and it doesn’t have complex constructs like GTK does; I’m pretty sure, though, there are better examples than a row of boxes that could have used a BoxLayout, or a FlowLayout, or a GridLayout, or a TableLayout; or better examples than using an explicit PangoFontDescription instance with a ClutterText to set a specific font name and size, instead of using the ClutterText:font-name property which wraps the whole thing for the developer’s convenience. in short: Clutter is more “raw” than GTK, but there are convenience APIs for developers.

it’s been a long time ((this year is actually my 10th bug-versary)) since I started off as a beginner in developing with (and) GNOME, so all I can say about book for beginners is whether they are using what I write in the way I think it’s supposed to be used; as far as I’m concerned, apart from a couple of issues, this book is indeed providing a solid base for people that want to begin developing for GNOME and with GNOME.

the price is pretty accessible, compared to the cost of similar books: I’ve paid much, much more for an introductory book on Core Animation, or on Perl books; the ebook version, if you dislike the dead tree version, comes in various formats, including PDF and Kindle.

I’m not going to give votes or anything: it’d be a pointless number on an equally pointless scale; but if you’re a beginner, I think this book may be fairly interesting to you, if you want to start coding with GNOME technologies.

Everything hits at once

conferences
sadly, this year I missed FOSDEM — and I saw from the blog posts on PGO that the DX hackfest was also amazing — but I had a good excuse, as I had to give a talk about Unicorns and Rainbows at linux.conf.au, in Canberra. I had the chance to explain what are the plans for the toolkit(s) used in GNOME in the coming future, as well as (obviously) enjoying one of the best free and open source software conferences, so all in all, I think that it was a good trade off. plus, I didn’t have to deal with the FOSDEM flu, apparently, so: good stuff all around. the video of the talk is already available on the LCA website ((and, seriously: how come the GUADEC videos are always, always late or not available even when we do record them? it makes us look really bad; GUADEC teams: fix this crap. it should be a hard requirement)) so if you weren’t there, you can still watch it. I’d put the slides somewhere, but I’ll have to make sure that the notes are up to date first ((I had my notes on the tablet, to avoid the focus back and forth when I had to advance them)).
life
after LCA, I took a week off in Sydney with Marta; the city was really enjoyable, and we had a great time exploring it. when I say “a week off” I don’t mean a week off of work, given that I’m currently not working: January 22nd was my last day at Mozilla. I detailed a why I left, and what my current plans are, on G+, so I won’t repeat them here — the executive summary is that I burned out pretty badly before leaving Intel, and I made the mistake of not taking a clean break before starting to work for Mozilla. right now, I’m trying to get back in a productive groove, so I’m looking around for cool stuff to do, as well as fulfilling my roles in the GNOME community as best as I can.
happenings
while in Sydney, I got a notification from my VPS hosting, the kind of notification that you really don’t want to receive when you’re on holiday and on a hotel wifi connection: apparently, my WordPress installation got hacked, and it started serving malware. cue various profanities that I clearly cannot repeat on a family-friendly website. I learned some valuable lessons from the first security breach I’ve ever experienced in years, but the main one is definitely the old adage from the Hitchhikers Guide to the Galaxy: don’t panic ((the other, and equally important one is: never trust a pile of PHP brain damage)).
beers

apropós of events, there’s a new GNOME London Beers meet up scheduled for celebrating the 3.8 release — or, at least, that’s the main excuse for meeting up, drinking beer, and having pizza with the GNOMErs in (and around) London. if you are in the area on March 1st, sign up on the wiki!

The Queen’s Rebuke

news of my death abandonment of the GNOME community have been greatly exagerated.

seriously: I’m still here at GUADEC (typing this from the common area); I’m still on the Board of the GNOME Foundation; and I’m still working on GNOME tech, like Clutter, GLib, and GTK+.

I am also working at Mozilla (and we’re hiring! :-)), but I also worked at OpenedHand and at Intel, and that never stopped me from actually doing stuff on the side; lots of people in this community do this — you don’t need to be full time employed with a company to contribute to GNOME, or to try and give the projects goals and direction.

on Sunday, I tweeted this:

[tweet https://twitter.com/ebassi/status/229551373044305920]

if it doesn’t show up, here’s what I wrote: we were always a bunch of friends working on stuff we loved in the face of unsurmountable odds. here’s to 15 more years.

it’s very true that we lack resources. we always did. it’s also true that we are competing in a space that does not leave us much room. we didn’t get 20% of the desktop market either, though. we’re doing what we do not because of the market share, or because of the mind share, or because we want to be paid. we write GNOME, we document GNOME, we design GNOME, we translate GNOME because we love GNOME. you would need to pay us not to work on GNOME.

everyone here at GUADEC is aware that hard times are upon us; we (presumably, though we don’t have any real metric to define that) have lost users. we definitely have lost sponsors. it’s not the first time, and I suspect it won’t be the last. what we haven’t lost are our passion for what we do; our mission, to provide a free environment for users to work with; and our willingness to drain all the swamps we have in the Free Software world.

if you want to work with us, join the GNOME Foundation — both as a member or on the advisory board if you are interested in sponsoring the project. help out in one of the many teams, not just with code, but with design, documentation, translation, marketing, web development, and mentoring.

we have so much work to do ahead of us to not only stay relevant, but to fullfill our mission, and blaze the trail to the future of Free and Open Source Software — we’ve got to get to it.

The Legionaire’s Lament

I have an idea of where the app developers are.

they are in an ecosystem that put up with a language that calling niche 10 years ago was flattering.

or they are in an ecosystem that is so fragmented that you can forget complaining about three or four major distros, when you have to deal with five different major versions on dozens of devices and form factors, all with minimal or no upgrade paths.

more importantly, though, I think that the app developers are where stuff looks cool and where the community leaders don’t eat their children in constant whining on public venues.

Rox in the Box

public service announcement — I just revoked my trusty GPG key, which I also used to sign Clutter releases:

pub   1024D/A4320FF4 2000-09-18
      Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4
uid                  Emmanuele Bassi 

the size of the key was ultimately too small to be trusted indefinitely. it’s been superceded by the following key:

pub   4096R/EA11BBB7 2012-06-22
      Key fingerprint = 53EF 3DC3 B63E 2899 271B  D263 22E8 091E EA11 BBB7
uid                  Emmanuele Bassi (GNOME) 
uid                  Emmanuele Bassi 

which will (hopefully) last at least as long as the old one, and possibly more.

The Rake’s Song

today is my last day here, at Intel.

it’s been an honour and a privilege working with one of the best teams in one of the best companies in the world. as I leave behind people that humbled me and made me a better engineer, I cannot but feel a bit sad; still, all good things must come to an end — and I’m sure that the good things done will, in time, temper the bad things that happened during these nearly four years.

what will happen on Monday, I’ll leave for a latter blog post — but suffice it to say that I’m going to stick around the free and open source software community at large (and GNOME in particular) for a while longer.

I know what your question will be: what happens to Clutter’s maintainership? well, if the demise of Moblin and MeeGo, and the rise of Tizen, haven’t killed Clutter I suppose nothing short of an asteroid impact will. so if you were already planning to open the champagne bottle and celebrate me stepping down from my self-appointed position of Clutter (almost) benevolent dictator, I’m afraid you’ll have to postpone the party for a long while.

I also want to thank all the people that voted for me, as well as the other candidates in the GNOME Foundation elections for the Board of Directors.

finally, see you all at GUADEC 2012:

GUADEC 2012 Badge

where I’ll give a talk about Clutter 2.0 and GTK+ 4.0.

June Hymn

today is the deadline for submitting candidacies for the election of the GNOME Board of Directors.

I decided to run again this year: it took me a bit to get into the role, but I think I can work with the fellow Board members, as well with the rest of the people in GNOME, to ensure the proper functioning of the Foundation now.

remember: being on the Board of Directors doesn’t mean having a fancy title, or a shot at managing the GNOME project towards a technical goal; it mostly entails providing the means by which the +GNOME project can actually function. without the Board and the Foundation, we could not organize hackfests, or send people to GUADEC, or even have GUADEC.

being a Director is not a huge amount of work: a 1hr meeting every two weeks, and at most one hour every day for emails and IRC discussions; but it’s necessary work, and it makes all the difference between a functioning community that can provide infrastructure to a complex project and a project that can only use public and free services without any guarantee of continuity. imagine not relying on all the services on gnome.org; or imagine not having any funds to organize the successful hackfests we’ve had in the past few years.

if you are a GNOME foundation member, consider running – if not for a specific goal, just to help out making GNOME successful in bringing together people to provide a first class software platform.

Culling of the Fold

I’ve received a bunch of questions about the state of the perl-Clutter bindings in the past couple of years; I entertained a vain hope of returning to actively maintaining them, but the effort of actually maintaining the underlying C library left little to no time for bindings (just ask the pyclutter users).

luckily, the stellar work done by Torsten Schönfeld on Glib::Object::Introspection allowed me to jump start an introspection-based binding module for Clutter in about half an hour – including the time spent porting one of the examples in the C API reference to Perl.

perl-Clutter is in git.gnome.org, and it works pretty much like perl-Gtk3 — same Dist::Zilla based setup, same dependencies.

contributions are very much welcome — though I’ll try to reserve some spare time for going back to the same levels of compatibility as the old, static bindings. one area for new contributors is pure-Perl overrides to paper over the C API; another is writing Cogl bindings, possibly static ones like perl-Cairo, as the Cogl API is not very introspection-friendly.

We Heaved Relief as Scores of Innocents Died

after all the changes in this series of blogs, and all the big changes I tried to introduce in them, this is mostly a coda — one in which I just want to mention a couple of new features that don’t fall in the previous apocalypses but that I think are interesting nonetheless.

ClutterTimeline and ClutterAlpha

the timeline class gained a new property, repeat-count which replaces the venerable loop one; whilst loop would just make the timeline loop indefinitely (until forcibly stopped), repeat-count allows you to set a ceiling to the number of repeats.

another change in the Timeline class is the introduction of the progress-mode property, which allows you to control how the progress property is computed. this effectively deprecates ClutterAlpha, even if the class itself hasn’t been marked for deprecation (as we still need it for other API).

these two changes hopefully will make using ClutterTimeline a better experience, and remove some custom code.

Support localizable strings in ClutterScript

if you currently define UI elements in ClutterScript you’ll notice that all the strings are not translatable; this is clearly sub-optimal, and prevents people from actually writing proper applications using this format, just like they do with GtkBuilder.

I recently added the ability to describe translatable strings inside the JSON format, using a syntax like:


  {
    ...
    "a-label-property" : {
      "translatable" : true,
      "string" : "A Translatable String",
      "context" : "Some Context",
      "domain" : "Gettext-Domain"
    },
    ...
  }

the domain and context members are optional, and allow you to specify a gettext domain and context for a specific string; you can assign a domain to the ClutterScript instance, using clutter_script_set_translation_domain(), or use the Gettext domain specified by the application itself upon initialization with bindtextdomain().

obviously, this is just a step: the real support for localization can only come after intltool is updated to handle the JSON format used by ClutterScript, to extract the translatable strings and place them into the POT file; this is planned, but it’s not ready yet.

see you in 6 months!

well, I hope you enjoyed this series of blog posts; oh, more accurately: I hope you haven’t been bored to death by it.

what will happen in six months is, very likely, a 1.12 release of Clutter, with a couple of other Apocalypses landing (a way to animate layout management by using the easing states and transition API instead of the half-aborted animation API inside ClutterLayoutManager; and the ClutterActorModel API, to get rid of the ClutterClones).

ideally, I’d really like to have the first 2.0 alpha release at about the same time — in order to give people the feel of the changes, as well as time to port their applications and start complaining about the missing functionality while I can still add, change, or remove API. what’s certain is that between 6 and 12 months I want to have Clutter 2.0 out of the door and into your systems; whether or not that will happen sooner or later it entirely depends on the time I’ll be able to spend on it, as well as the contributions I may receive. so, if I have to close with a familiar exhortation: patches welcome!

until then, have fun with Clutter!

And I Believe California Succumbed to the Fault Line

Clutter’s description, and I quote from the website, is:

an open source software library for creating fast, compelling, portable, and dynamic graphical user interfaces.

and yet, the API to build a user interface is static: you create the actor tree, you tell it how to paint its contents, and only then you animate it to create a compelling and dynamic result.

the ethos of an API should be to Do The Right Thing™ by default — and make it harder if not impossible to Do The Wrong Thing™ — so why is it that you have a simple function to make an actor jump at a given position, and you have a really complex function, full of side-effects and options, to make an actor tween between the current position and the desired new one?

Scumbag Steve meme - top caption says: "Promises dynamic user interfaces", bottom caption says: "makes everything static by default"

wouldn’t it be better, and even easier, if the simple function did the tweening, and if the complex function just went away because, well: who needs it, anyway?

so we need to identify properties that should be animated when changed, and we have to make every setter for that property perform a transition from the current value to the desired value, using a predefined duration (that can be changed), and a predefined easing mode (that can be changed). easy, right?

well, sort of. we already have all the pieces in place: we have the timeline, to define the duration and progress of a transition; we have the interval, to define the initial and final states, as well as the interpolation between the two; and we have the introspection capabilities of GObject to determine whether a property can be animated, and how. all we need to do is connect the dots inside ClutterActor. hence, the introduction of ClutterTransition and of the easing state. the former is a simplified version of ClutterAnimation, that ties a ClutterInterval directly into a ClutterTimeline to avoid signal emissions and weird memory management rules; the latter is a way of describing the duration, delay, and easing mode of all subsequent transitions. Clutter will manage everything behind the scenes for you, so you just need to tell it how long, and how paced, are your transitions.

so, in short, this call:


  clutter_actor_animate (actor, CLUTTER_EASE_OUT_CUBIC, 250,
                         "x", 100.0,
                         "y", 100.0,
                         "width", 200.0,
                         "height", 200.0,
                         NULL);

becomes:


  clutter_actor_save_easing_state (actor);
  clutter_actor_set_easing_mode (actor, CLUTTER_EASE_OUT_CUBIC);
  clutter_actor_set_easing_duration (actor, 250);
  clutter_actor_set_position (actor, 100, 100);
  clutter_actor_set_size (actor, 200, 200);
  clutter_actor_restore_easing_state (actor);

which does not seem much, but:

  • you get back all the type safety you need;
  • the code becomes easy to follow;
  • you can use the convenience API instead of a per-property set.

for instance, try throwing things like scaling or rotating:


  ClutterVertex vertex = CLUTTER_VERTEX_INIT (x, y, z);

  clutter_actor_animate (actor, CLUTTER_EASE_OUT_CUBIC, 250,
                         "rotation-angle-y", 360.0,
                         "fixed:rotation-center-y", &vertex,
                         "scale-x", 2.0,
                         "scale-y", 2.0,
                         "fixed:scale-gravity", CLUTTER_GRAVITY_CENTER,
                         NULL);

becomes the much more familiar:


  clutter_actor_save_easing_state (actor);
  clutter_actor_set_scale_with_gravity (actor, 2.0, 2.0, CLUTTER_GRAVITY_CENTER);
  clutter_actor_set_rotation (actor, CLUTTER_Y_AXIS, 360.0, x, y, z);
  clutter_actor_restore_easing_state (actor);

well, I cheated a bit: the easing mode of CLUTTER_EASE_OUT_CUBIC and the easing duration of 250 milliseconds are the default when creating a new easing state — but that’s just another benefit: you don’t need to specify an easing mode and a duration if you want to use the sensible defaults, whereas clutter_actor_animate() forces you to do that every time.

job done!

Darth Vader filling a jug with water filtered from the sea

we still don’t want existing Clutter applications to change behaviour and start animating everything just because you updated Clutter from 1.8 to 1.10; for this reason, all actors start off with an easing state with a duration of zero milliseconds — which means that all transitions happen immediately. at least, this will be true for the 1.x API series: for 2.x, the initial easing state will have a non-zero duration, which means that if you want to make an actor jump at a specified state then you’ll have to begin a zero-milliseconds duration.

well, kind of

Success Kid Meme image; top caption is: "Follows API ethos", bottom caption is: "Makes the World Better"

it’s important to make sure that every time you want to change a user interface you think of it as an animation; this API should immediately give you have a visual feedback of what that change is going to provide — without structuring your code around lots of variadic argument functions, with pretty loose type checking and “interesting” corner cases.

so, for the 1.10 cycle you should start opting in into this way of writing your application, and use easing states instead of using clutter_actor_animate().