Category: Technology

couchdb-glib 0.1

As the first step on CouchDB desktop integration, here’s version 0.1 of couchdb-glib, a GLib-based API to talk to CouchDB.

This initial version only allows reading and does all operations synchronously (not a problem in most cases, since the communication is done to the local CouchDB instance, which is quite quick, at least from what my tests show so far). Next releases will have all the missing functionality.

And, well, no screenshots to show, so here’s some example code for you to enjoy.

Source code is in GNOME GIT, under couchdb-glib module.

AdminKit 0.0.1

Last week it was hacking week for the openSUSE-GNOME team, so I continued working on a little project I started a few weeks ago, which is, in the good old Richard Hughes tradition, a thing called AdminKit, which is a PolicyKit-based framework for allowing user applications to run administration tasks.

Most of the time hacking on this has been dedicated to the PolicyKit stuff, but now everything should be in place, and, apart from the 2 methods I added (RunAsRoot to replace gnomesu/gksu/kdesu, and AddUser as an example of how to use YaST’s command line interface for the operations), more methods (users management, firewall, samba shares, etc) can be easily added. With this and the GUI from gnome-system-tools, I think we can start providing a distro-independent (and acceptable to all of them) set of administration tools for GNOME (and KDE, if they adopt AdminKit), or just add the needed admin functionality to already existing applications. From now on, here are my ideas:

  • Move PolicyKit mechanisms already existing in some GNOME modules (gnome-panel’s SetTime and SetTimezone, for instance) to AdminKit, provided people agree on adopting it
  • See system-tools-backends and reuse as much knowledge/code as possible
  • See at changing gnome-system-tools’ GUI to use AdminKit (once the functionality needed is moved to AdminKit)
  • Add more admin operations, as needed. For openSUSE, we have quite a lot of functionality via yast’s command line interface, and other distros have similar stuff, so anything we need can be added AFAIK.

Get the code with:

git clone http://www.gnome.org/~rodrigo/git/osc-plugins.git

(cd AdminKit, the other top-level dirs contain unrelated projects)

And, soon, packages at my home build service repository.

openSUSE build service collaboration

One of the shortcomings of the openSUSE build service was, until recently, that it didn’t help outsiders (non-Novell employees) in contributing to the distribution’s packages. The build service team worked hard in the last few months, and now it is very easy for external people to send patches directly to be included in the main distribution.

First, you need to create a branch from the package you want to change:

osc branch GNOME:Factory gnome-utils

This creates a branch in your home project (home:$user:branches:GNOME:Factory), so just check it out:

osc co home:$user:branches:GNOME:Factory gnome-utils

Then, just work on changes, and when everything is ok and the package builds, just commit and submit a request

osc commit -m “Changed foo and bar”

osc submitreq create -m “Changed foo and bar”

Before submitting though, it might be wise to re-check your changes:

osc rdiff home:$user:branches:GNOME:Factory gnome-utils

which shows a diff of the changes in your branch.

osc commit/submitreq create will submit the changes to your branch and to the project you branched from (GNOME:Factory in this example), so that maintainers can review and accept (or reject) the submission. Maintainers just need to:

$ osc submitreq list GNOME:Factory

359 new home:rodrigomoya:branches:GNOME:Factory/gtk2-engines -> GNOME:Factory/gtk2-engines ‘——————————————————————-\nFri Jul 18 17:16:38 CEST 2008 – rodrigo@suse.de\n\n- Tag and upstream patches’

360 new home:vuntz:branches:GNOME:Factory/pango -> GNOME:Factory/pango ‘Tag pango64.patch’

363 new home:jproseve:branches:GNOME:Factory/glib2-branding-openSUSE -> GNOME:Factory/glib2-branding-openSUSE ‘Fix bnc#406741’

364 new home:rodrigomoya:branches:GNOME:Factory/fast-user-switch-applet -> GNOME:Factory/fast-user-switch-applet ‘Tag patch correctly’

365 new home:rodrigomoya:branches:GNOME:Factory/gnome-utils -> GNOME:Factory/gnome-utils ‘Tag some patches’

366 new home:jproseve:branches:GNOME:Factory/scrollkeeper -> GNOME:Factory/scrollkeeper ‘Tag patches’

367 new home:jproseve:branches:GNOME:Factory/icu -> GNOME:Factory/icu ‘Tag patches’

368 new home:jproseve:branches:GNOME:Factory/scrollkeeper -> GNOME:Factory/scrollkeeper ‘Tag patches’

which lists all the submissions waiting in the queue, and then just needs to review it:

$ osc submitreq show -d $id

which shows the patch for the submission identified by $id. And then, just accept or reject:

osc submitreq accept $id

osc submitreq decline -m “Your patch is wrong, don’t send me more” $id

Neat, isn’t it? This should help us a lot in getting users’ contributions quicker into the distro, as well as in a better patch reviewing system.

Where we are going we don’t need roads


Been reading this last week the decadence in GNOME thread in Planet GNOME, so just wanted to add some thoughts:

  1. First of all, I don’t think GNOME is in decadence at all. The development platform does nothing but improve (GTK/glib, new gio/gvfs, libgnome/bonobo/etc disappearing, good bindings for lots of languages, etc), and applications do the same.
  2. We offer incremental updates on each release, a lot of work is done, but it’s true that for some end users, they might not see changes big enough to consider it a new version. So maybe, apart from the time-based releases (which work pretty well, IMO), we should maybe try to have, apart from the individual modules’ roadmaps, some sort of desktop-wide features to accompany each release. If we set, for instance, a “all apps will use gio and support working with remote files” goal, I think that would make a better release feature that end users will better appreciate. Similar desktop-wide goals could be used for each release, which will change, IMO, the user’s impression of the new releases.
  3. I hear some people considering 3.0 should contain a lot of development platform changes. And well, while changes in the development platform are great (that’s why it’s improving all the time), I don’t think the future of GNOME (the desktop) releases should be so tied to the platform. On the contrary, the platform should adapt to the applications being written. Some years ago we did a lots of improvements to the platform because we were writing big apps (Nautilus and Evolution).
  4. Since I started using GPSs, I ended up visiting forums and mailing lists about the subject, finding that most people use illegal software (cracked programs downloaded from P2P networks) and maps (ditto, got from P2P), so if we could offer a free software-based solution for these people, they would probably move on. This is of course just one example, which is even being already covered by OpenStreetMap, but I’m sure there are lots of similar markets out there that we could try to cover better to bring 1000s of new users to our desktop.
  5. As for innovation, this is probably something we need to improve. There is innovation for sure (Gimmie, Pulseaudio integration, Compiz Fusion (not really a GNOME thing, but it’s got GTK-based tools that nicely integrate into GNOME), Banshee 1.0 (try it, it’s great!), Clutter, etc), but it’s true it’s not easy to make revolutionary changes (like using gimmie instead of our current panel, for instance), since it means convincing a lot of people in endless discussions. I think part of the problem is that people working on similar stuff are not put together to come to decisions (like distros working on similar solutions for the same thing 🙂 ), so we probably need improvement there, like having the hack meetings that were discussed recently.

Back home / debugging

I’m now back home after a couple of weeks of lots of traveling. I first was 4 days in London, visiting my sister, then was 5 days at home, sick with a flu most of the family got while in London, then last weekend to beautiful Salamanca for a conference at the University. Back home on Sunday, still a bit sick, and on Monday flied back to Stansted for a 2 days visit to Michael, for some debugging and bug fixing fun.

So, in this 1.5 days of fun action at Michael’s, I’ve learnt a few useful bits:

  • Some useful tools, like LD_DEBUG, pmap, fuser, c++filt
  • Technique: this was the best part of it, since Michael is what we could call a superhacker, so watching him debugging stuff to look for a problem’s cause is very helpful (even though you can’t read everything he writes, since he does it so quickly 🙂 ), and he has some nice habits in his technique that should help me a lot, now that I’ve learnt them, in my bug hunting work.
  • I had an idea about writing scripts using lots of these tools for our users to use them for reporting super-useful bug reports, so will be writing a little bit about that as soon as I start looking at it.

While visiting Michael and his wonderful wife and daughters, I had the opportunity to meet my sister and family on Tuesday for dinner, since they were visiting Cambridge that day, where they will be moving soon, so I will have the opportunity to visit both my family and Michael (for more debugging and technique learning fun) more often.

GUADEMY 2008

Last weekend I’ve been in Valencia for the II GUADEMY, organized by PoLinux (the Linux Users Group of the Universidad Politécnica, where the event took place).

The purpose of this II GUADEMY was to really serve as a starting point for further sharing between free desktops (it’s true it was just about GNOME and KDE, although I’m sure we could easily get other free desktops in), and I really think that it has succeeded. There were some core KDE and GNOME developers around, even though lots of GNOME/KDE Spanish developers were missing (where were you?), and even though not big decisions have been made, I feel that this is the beginning of a new era in free desktops sharing. Of course, it’s a very long trip what we just started, but seeing people from both desktops willing to cooperate as much as possible means we (the people that believe in further sharing) are not that wrong 🙂

So, here are my conclusions from what I have seen/heard during this weekend with lovely weather and very little sleep in Valencia:

  • We are sharing some stuff now, much more than a few years ago (HAL, DBus, PackageKit, WebKit, poppler, fd.o specs, etc), but we still have a lot of duplication (duplicated screensaver / power management / login manager / etc cores, with lots of security and other issues).
  • People generally agree in sharing code, but sometimes in the form of “here’s our implementation, based on our technologies, use it if you want”, which doesn’t work. There were complains about how GIO was written without taking KDE’s KIO people into account, and about KDevelop new code, which didn’t take into account Anjuta’s people. So, we need to fix this.
  • We need a process to determine what to share, as Will said in our talk, and, from what I got from Vincent‘s talk, Freedesktop.org is in need of an official board that can establish a formal process for accepting standards and implementations, and also it needs to get more KDE people involved so that it’s not seen as a GNOME-only thing. It seems to me the natural way would be to fix fd.o’s situation and use it for further sharing.
  • The whole Saturday morning was dedicated to talk about the GUI toolkits’ future, with Carlos Garnacho, Holger Freyther and Javier Fernández from igalia. It was really interesting to see what the future might bring us, since free GUI toolkits need not only to cope with better look&feels, but also with different devices, given the mobile device market is making a lot of use of our technologies.
  • Some further examples of things that could be shared: an indexing/metadata system, PIM data access and management.
  • I missed Sunday’s talks, since my bus was leaving at 11AM, but I’ve heard there were some joint conclusions in the last session, so let’s see if someone that attended publishes them.
  • Vincent didn’t want to believe me, but really, normal Spaniards don’t usually go to places like Los Bestias 🙂 (details from Jos). I wouldn’t really recommend it to anyone, except for stag parties (if you ever go to this kind of parties), but it was fun to see something different, we laughed a lot during the dinner. Fortunately, we arrived a bit late, so we just had to listen to the Karaoke for a few minutes, after that, it was shut down.
  • Not related to GNOME/KDE, but I convinced a couple of more people to use their GPSs to record their travels and send them to me for uploading to the OpenStreetMap database, even though one of those guys’ GPS suffered a disgusting accident 🙂

Just wanted to end up with a big congratulation to the organizers, they managed to do a great conference, with core international speakers, even though the planning started quite late. Now looking forward to GUADEMY III, which might perfectly take place, why not, in the joint GUADEC/Akademy in 2009.

You can see the slides of my talk here. These don’t include Will’s plan for code sharing process, which I guess he’ll publish soon.

Desktop effects activation (compiz)

The discussion about how/where to put the activate-desktop-effects thing in the appearance capplet seems to not reach a good solution for all distros, at least for now, so, while waiting for a good solution for all upstream, and since in openSUSE desktop effects means compiz, I added a patch to the simple-ccsm openSUSE package to activate compiz directly from the same place where it is configured.

So, the ‘Desktop Effects’ icon in the GNOME control center:

starts now simple-ccsm, which contains a check box to activate/deactivate compiz.

The old ‘Desktop Effects’ capplet (aka gnome-xgl-settings) will soon die, since gnome-xgl-switch script has been moved to the XGL package, and the hardware database is already on a separate package.