I’m proud to announce that s-t-b HEAD now includes the ported patches by Darren Kenny and Erast Benson to support OpenSolaris and Nexenta. This means that s-t-b now supports the three major Unix based platforms: Linux (lots of distros here), FreeBSD and SunOS, and the best of all… 2.0 is really near!
Just returned from the GNOME developers meeting celebrated in Zaragoza (Spain). It has been quite productive, with workshops about the longstanding GNOME-Hispano project “libro de programación en GNOME”  and Evince (courtesy of KaL) and Planner (Courtesy of acs) hacking sessions, there came new people interested in GNOME development  and of course we were partying overnight too!
On my side, I’ve also managed to make g-s-t, liboobs and s-t-b releases, and porting to the DBus architecture 95% of the cool patches by Darren Kenny and (I think) Erast Benson to add support for OpenSolaris and Nexenta, with this patch I think s-t-b 2.0 is very close!
As a developer
Pros: Perl “sucks”, it doesn’t suck per se, but not getting contributions *sucks* . Python on the other hand is hype, currently there’s much more people willing to contribute coding in Python than coding in Perl, but that’s not news.
If there’s a Python replacement for the backends, I bet that there will be much more people willing to look at that code, and that can easily translate to more contributions, so if a framework to add support for other distributions is done too, that will make many people happy .
I strongly believe that s-t-b concept and structure is the right way, but experience forced me to think that it was in the wrong language.
Cons: Maybe most of the concepts would be reused, but there would be heaps of code that wouldn’t, the project status would be almost resetted to 0, it would go from supporting tenths of distros to supporting 1.
The big plan behind s-t-b, dbus, liboobs and g-s-t wasn’t just ditching the XML interface, it was to split things down to make contributions as painless as possible at any level (DBus also allows to do things that were nearly impossible with the XML interface, but that’s a different issue), For example the codebase in the backends has been shaved to 11KLOC (according to sloccount, much of it is common boilerplate, specific code for one distro must not reach more than 300-500 LOC). I’d like people to have a look at the code modifications before willing to replace parts of it (the new g-s-t structure also allows that quite more easily)
Replacing the frontends with python scripts is a different horse, reusing just the g-s-t glade interfaces reminds me what my beloved mentor Chema (RIP) told me once about RedHat doing the same a long time ago
I’ve failed, I once thought that s-t-b would be an excellent collaboration framework for distributions, the reality is that the only big distro using it now plans to switch, some other distros ship g-s-t as a curiosity and others don’t do that at all. The patches from distros, although very appreciated, have been very few, so s-t-b is miles away from where it could be (Maybe it’s just my lack of leadership, or that I’m a poor unemployed guy and don’t represent any big FS company, who knows)
In the case that Umbrella tries to do a multidistro framework (I bet it will success over s-t-b with time, people love Python after all), I don’t think I will collaborate regularly with code, I’ve been struggling with g-s-t for more than 4 years, and I’m not willing to start the very same thing from scratch. However, I’m fully available to give advice, after all I think I earned enough know-how on the subject.
I really hope that people won’t think I’m pissed off, Michael and Daniel are quite happy with their decision, if they are happy and take this to the end, I’m happy too. It’s just that I’m a practical guy, and I should focus on other parts of the desktop where my code would be more appreciated.
And now, off to my guitar lesson…
 Really, I think I could count contributors to s-t-b in the last year with the fingers of one hand. even my last post got no response at all
 You wouldn’t believe the ammount of people that tried to convince me to rewrite s-t-b in Python
After some months of apparent inactivity in gnome-system-tools, during the last couple of weeks I’ve been moving to HEAD the changes done in the experimental branches and closing heaps of bugs. Finally today I’ve been able to make releases for system-tools-backends 1.9.0, liboobs 0.1.0 and gnome-system-tools 2.15.0.
These releases mean a significant step forward, s-t-b now features a DBus interface (Thanks to Net::DBus, courtesy of Dan Berrange, thanks!), liboobs provides a GObject interface totally abstracted of the communication layer, and g-s-t takes advantage of it.
This also means that lots of code have been refactored/deleted, this specially concerns me in the backends. Given the wide range of distros it supports , and my impossibility to test them all , I’d thank if anyone could test the tools in their favorite distro. For the record, I’ve already tested them in Debian/Ubuntu and everything worked as expected :). If you want to help, I’ve setup a wiki page explaining how to compile & test g-s-t HEAD, so please if you find something that doesn’t work as expected in your distro, file a bug or send me a mail (carlosg at gnome dot org), I’ll take care of fixing it.
 Really, lots. But testing with latest Ubuntu/Debian, SuSE, FreeBSD, Gentoo, Fedora, … should cover 99% of the code paths
 Liboobs eases the creation of automated tests, but I’m also lacking enough HDD space
Said and done, I’m leaving my job in a couple of weeks.
Quite fun overall again, lots of friends came to see us and it seems they’ve enjoyed too (unless they lied to us! ;).
/me singing (badly), Merche to the right
Merche and I again
Merche, David at the drums and Kike at the bass guitar
Too bad that there isn’t any good photo of Felix (the other guitarrist)!
Hmm, 7 months without posting, I’m beating all records…
Work-wise, sucking, I badly need a break, and I think I’ll take it soon.
In fact, we’re playing again this saturday (4th Feb), so if you live anywhere near Madrid, don’t forget to drop here!
 Spanish only ATM (sorry) and missing a recent/decent photo, that one is with the former guitarrist…
GNOME and hacking stuff
I haven’t been giving much love to the gnome system tools lately, unsurprisingly, I missed the schedule for including all the features I wanted for 2.14 (mainly liboobs, with improved communication, error control, etc…), but there were much progress in this and I hope to see it in 2.16.
Instead, during the last months I’ve been focusing mainly in GtkAssistant (now in CVS! sweet!) and in GtkNotebook drag and drop support (still ongoing, but progressing nicely), it’s been very entertaining and instructive.
Finally moved my butt and made some system-tools-backends and gnome-system-tools releases (2 of the latter, don’t ask why), they mainly include the new services-admin UI, besides some other goodies and squashed bugs.
There have been some changes in the services backend, none of these should cause any harm, but if you use gentoo, SuSE, slackware or FreeBSD and want to help, don’t hesitate to test the new tool and tell me how it went
that’s all, thanks!
After some refactorization and some thinking about how and where to do all the services categorization, I’m getting at least a good working prototype of services-admin with reworked UI/concept, hopefully this code will hit CVS tomorrow.
New services-admin main window
BTW, Thanks Jeff for switching my blog in p.g.o, blogs.gnome.org is quite neat
It’s still in some need of coding love, and I should add categorise at least the most used services for providing useful descriptions, so there’s still work to do.
Calum: Maybe what I missed when adding accessibility support to the gnome-control-center shell were some docs about where to begin when adding accessibility support to custom widgets. The better source of information I could find was other widgets’ code, as the API may look quite raw if you’re unfamiliar with it
Finally had time to apply NotZed’s suggestions (Thanks!) to the small evo plugin I wrote to remove duplicates, and as of evo 2.3.2, plugins can be compiled independently, eliminating the need of patching evo sources, really good stuff
IMHO, the next great step would be to create a small repository for plugins (i.e.: a evolution-plugins-extras VCS module), cluttering evo sources with plugins that will be barely used might not be very desirable, and OTOH cluttering the CVS with small software pieces like this would be crazy.
So, while I don’t know where to put the thingy, the code is here. Enjoy!