Of Angels And Angles

GtkApplication class: I’ve updated the application class page on the wiki. Now, it has an updated layout of the API (which is what I’m currently working on) and the design requirements it should fulfil. While writing it I had some sort of epiphany about the whole library consolidation effort and its perception among the platform developers. Project Ridley as it stands is a double-edged sword: on one hand we’d like to have more functionalities moved from external libraries to GLib and GTK+; on the other hand, the size of the platform libraries maintainer teams is not growing at the same rate. If we are to move widgets, features and whatnot to GTK+ we must be sure not only that someone is actively working on them after inclusion, but also that someone is willing to work on the rest of the codebase, in order to review the patches leading to the inclusion of new functionalities. So, waiting for Project Ridley to come to the rescue is not going to cut it anymore: if you are proposing to move some functionality from a library to GLib or GTK+ be prepared to work on the whole code and not only on your pet feature.

GtkUnique: since a “single instance application class” doesn’t really make any sense without an “application class” to make it inherit from, I’m punting the GtkUnique inclusion in GTK+ until the application class lands in first – and that makes it part of the post-2.12 masterplan; hence, I’m going to remove the gtk namespace from gtkunique and releasing it as a standalone library for the time being. I’ll commit the namespace switch before this weekend: it’ll switch from GtkUnique to Unique; everything else will stay the same. Remember to check it out from GNOME SVN server:

  svn co http://svn.gnome.org/svn/gtkunique/trunk

GConfig: as I mentioned in the last blog post, I’m working on the next iteration of GConf. Aside from ongoing design and API churning, I’ve also submitted a talk proposal for the next GUADEC about how to tackle the whole ‘GConf issue’. GConf is part of the core GNOME platform, and it has been so since 2000; it’s almost seven years old, and now it begins to show its age. Since 2001, Havoc has been asking the community to implement the same set of (five) features; no one has answered his call yet. Maybe the community is to be blamed for this; maybe we need to rethink part of the GConf design to allow someone other than ‘the usual suspects’ to fix GConf shortcomings and add new features. For instance: the backend API is a really nasty piece of code and it’s not easy to drop a new backend into an existing GConf installation; probably, that’s also why, after all these years, we still have only the XML and had to wait a long time for the evo-ldap backends. I’m going to put a page on the wiki with what kind of API I’m thinking about.

talks: aside from the GConf talk, I’ve also proposed a talk/tutorial about the Perl bindings for GTK+. I’ll also do two talks about Perl, GObject and GTK+ at this year’s Nordic Perl Workshop which will be held at the end of April in Copenhagen.

Like Eating Glass

Desktop-devel-list (d-d-l) is an interesting place. You follow discussions that usually tend to fork off, moving through tangential arguments; but, in the end, some stuff keeps turning up. Lately, for instance, every thread seems to end up on discussing about Tracker.

Let’s take the discussion about having a GNOME “media center version”; you could think that such a discussion will end up laying out some ideas about a media center. Wrong: we ended up discussing about special folders – an argument that has already been discussed to the death. Obviously, if you read d-d-l all day you can’t really expect having time to actually work on the features (or the crack) proposed on the list. So, for a change, I decided to do stuff after saying what could be done. I decided to take an idea that has been floating around for ages and implement it.

This is a simple FileChooserDialog, but the places list have been generated using a bookmark file (read using GBookmarkFile) in $HOME/.local/share/places/gtk-bookmarks.xbel instead of $HOME/.gtk-bookmarks:

FileChooser using bookmark file
It’s completely identical to the FileChooser in trunk, really, but the places on the left are parsed using this.

The code, obviously, merges the places saved using the old format.

This, instead, is a trivial Perl application that can read all the places; it can also edit them, add new places and remove old ones:

GTK+ shortcuts editor

The fun part about switching the file chooser to the bookmark files is that it’s public API, so everyone can read, change and write these locations. We can add new locations to an application like we add Glade files, and let the file chooser populate itself by loading a file; so, instead of using:

  gtk_file_chooser_add_shortcut_folder (file_chooser, some_location);

we could use:

  gtk_file_chooser_add_shortcuts (file_chooser, PKGDATADIR "/shortcuts.xbel");

But wait, the keen reader familiar with the issue will interrupt, the whole point of this mess is localising the name the user sees in the interface. Indeed, that’s why the bookmarks have a title and a description; through intltool we can extract those two and put them into the po file for the translators to work on – exactly like we do for the Glade files. Before displaying the bookmark will pass the string through gettext, which will return the localised alias using the application’s domain – or we could add domain argument to the gtk_file_chooser_add_shortcuts() function above.

The file chooser can also load shortcuts automatically, using the application name to filter out what’s interesting.

Is this the most correct solution for this problem? I don’t really know, even though using bookmarks and applications make more sense than using dot-desktop files and MIME types (come on? MIME types? Like I should bind a directory to specific types of content and not to the applications that are most likely to use them – and what are “MIME types” anyway?). At least, however, this is a start and there’s some code to comment on.

The patches are roughly done, but the real treat would be to split the places section of the file chooser widget into its own widget and let other applications, like nautilus, use it directly without having to cut and past tons of code out of GTK+.

Twist The Knife

Dear LazyWeb:

I’m trying to clean up the python bindings for the next release of a GObject-based library, so I’m using pygtk and its codegen magic; unfortunately, being codegen.py an incredibly bad program, I can’t see why or how it’s failing to read the .defs and .override files, and why it doesn’t generate anything. Is there a way to have some sort of error message or information except for the quite useless statistics recap? I’m using the same build system used by pygtk, so this must work if you apply enough bad mojo somewhere. I don’t want to dwelve into the 1707 lines of dense python – I’d rather spend my time binding a library.

Thanks.

Three hours, and many curses, later: it seems that I have mistakenly deleted a '%%' between a ‘ignore-blob’ declaration and the body of the override file. This, for posterity, is logically equivalent to “ignore whatever exists after this space”. which is, all in all, logically coherent, and I’m more than willing to beat my head against the wall for my stupidity. But if codegen.py had a “verbose” mode (instead of me sprinkling the code with “print” statements) I would have found this way sooner than the three hours it took me. A simple line redirected to stderr telling me “hey, I’m ignoring this and that” would have been sufficient.

Little Earthquakes

After two weeks without working on it, this evening I finally returned to GtkUnique and finished the bacon-like backend. Now, beside using D-Bus and Xlibs, you can use Un*x sockets as an IPC method to send a command to a running instance of an application which is using GtkUnique.

Next items in the TODO are:

  • Add more documentation on the protocol used in the three backends;
  • Fix the Perl bindings;
  • Finish and publish the Python bindings;

In the meantime, you can grab GtkUnique 0.5.0 here or pull it from the bazaar repository.

Gtk+ 2.9.0 released

Finally, the first development release of GTK+ (codenamed The Magic Project Ridley aka libgnome sucks release by a developer whose name won’t be disclosed in this blog) has been finally sealed by Matthias Clasen yesterday, after battling with make distcheck.

There is so much goodness in this release that I’ll just wait for Kris to make a blog about it, and link the NEWS file and let you see the enormous work that has been done in the past nine months. So, find the contributor nearest to you and hug him (or buy him a beer); to help this hugging (and beer buying) procedure, here’s a list:

Ævar Arnfjörð Bjarmason, Akkana Peck, Alexander Larsson, Alexander Nedotuskov, Alex Graveley, Anders Carlsson, Andrei Yurkevich, Andrew Conkling, Andrew S. Dixon, Arjan van de Ven, Arnaud Charlet, Bastien Nocera, Behdad Esfahbod, Benedikt Meurer, Benjamin Berg, Benjamin Otte, Benoît Carpentier, Bodo-Merle Sandor, Bogdan Nicula, Brad Taylor, Calum Benson, Carlos Garnacho Parro, Carl Worth, Chris Lahey, Chris Lord, Christian Kirbach, Christian Lohmaier, Christian Neumair, Christian Persch, Christian Stimming, Christophe Belle, Claudio Saavedra, Clytie Siddall, Colin Walters, Cory Dodt, Coverity, Crispin Flowerday, Damien Carbery, Damon Chaplin, Daniel Drake, Daniel Kasak, Dan Winship, Dave Andreoli, David Baron, David Trowbridge, Davyd Madeley, Denis Auroux, Dennis Cranston, Diego González, Dom Lachowicz, Donald Straney, Duncan Coutts, Ed Catmur, Elie De Brauwer, Emmanuel Rodriguez, Eric Cazeaux, Evert Verhellen, Francisco Javier F. Serrador, Frederic Croszat, Guilherme de S. Pastore, Guillaume Cottenceau, Gustavo Carneiro, Hamed Malek, Hans Breuer, Havoc Pennington, Hylke van der Schaaf, Ian McDonald, Itai Bar-Haim, Jaap A. Haitsma, James Su, Jean-Yves Lefort, Jens Granseuer, Jeremy Cook, Jody Goldberg, Joe Marcus Clarke, Joe Wreschnig, Johan Dahlin, John Cupitt, John Ehresman, John Finlay, John Palmieri, John Spray, Jonathan Blandford, Jorn Baayen, JP Rosevaar, Jürg Billeter, Kalle Vahlmann, Kathy Fernandez, Kazuki Iwamoto, Kean Johnston, Kjartan Maraas, Kristian Rietveld, Larry Ewing, Leena Gunda, Lillian Angel, Li Yuan, Lorenzo Gil Sanchez, Maciej Katafiasz, Magnus Bergmann, Markku Vire, Mark McLoughlin, Marko Anastasov, Mark Wielaard, Mart Raudsepp, Martyn Russell, Mathias Hasselmann, Matthijs Douze, Maxim Udushlivy, Michael Emmel, Michael Natterer, Milosz Derezynski, Morten Welinder, Murray Cumming, Nickolay V. Shmyrev, Nicolas Setton, Niklas Knutsson, Olexiy Avramchenko, Owen Taylor, Paolo Borelli, Paolo Maggi, Peter Breitenlohner, Peter Harvey, Peter Lund, Peter Zelezny, Philip Langdale, Raphael Slinckx, Ray Strode, Richard Hult, Robert Ögren, Rodney Dawes, Ross Burton, Ryan Lovett, Sadrul Habib Chowdhury, Sebastien Bacher, Søren Sandmann, Stanislav Brabec, Stefan Kost, Stephane Chauveau, Steve Chaplin, Steve Frécinaux, Sven Herzberg, Sven Neumann, Thomas Broyer, Thomas Fitzsimmons, Thomas Klausner, Thomas Leonard, Tim Evans, Tim Janik, Todd Berman, Tommi Komulainen, Torbjörn Andersson, Tor Lillqvist (and his Evil Twin), Torsten Schoenfeld, Tze’ela Hebron, Vincent Untz, Wolfgang Thaller, Wouter Bolsterlee, Yang Hong, Yevgen Muntyan, Yong Wang. And, obviously, our fearless maintainer Matthias Clasen.

Kudos to all of them.

Third-graders

This is a comment I left on Philip’s blog in response to Ross’ blog.

question: what are we, third graders that we must do all this touchy-feely, “we must not make comments” stuff?

ross’ comment was a bit on the edge, but its his blog, and he has any rights to write that the player sucks; the other blog post from joe is the more relevant: the entire free software/open source thingie works because we have copyright and because we have peer pressure. the “author” of listen stole code, because it didn’t simply lift it and put it into his project: he also removed the copyright notices. I copy code from many projects (as far as the license enables me to do it safely) but I leave at least a note saying from where I took the code and who’s the author. if a big company did the same thing we would all be jumping and screaming around.

what strikes me the most is that, instead of integrating stuff by talking to the various projects and – at most – forking some code base, the guy just went lifting code, collating stuff like a frankenstein movie, and then releasing the resulting “monster” without even a mention of the other projects. and all these people say: “oh, the media player situation demands it” or: “oh, amarok is such a fine player that we need a poor man’s clone for gnome” – basically insulting every author of the other media players around, insulting an author that want his contribution to the f/oss community recognized as he well should, and justifying the copyright infringement for the sake of having their pretty little clone.

these are energy stoppers. If I was a developer of another media player I would simply cease all my work instantly, out of such blatant ingratitude.

After having read some of the comments on Ross’ blog, and after the querelle about the NLD10 stuff that happened on the desktop-devel-list, I’m wondering if the major problem of the Gnome community is its being made of third graders, where one must not say bad things about someone else’s work because of a “we are all special”-kinda-like agreement that, it seems, you implicitly sign when you get an account.

Come on! If I think that a projects sucks I’ll write that it sucks, ferchrissake! I expect none the less from my peers, and I expect none the less from the many people that is well above my skills. If I wrote a piece of software and someone comes along saying that it sucks because of this and that, then I’ll respond or I’ll say fuck dude, you are right and will change it, or I’ll say yep, but it’s my project and I will go on. Gracefully taking criticism for your work is a valuable indicator that you are not a child anymore.

If you cannot cope with this, then please don’t even begin coding; because peer pressure and peer review are what makes F/OSS such a great endeavour.