libmodel and GTK+ from Codethink Labs!

A few months ago we announced libmodel to the masses, the shiny data model API for GObject, one of our pet projects from Codethink Labs.

Last week we decided to spend some time doing R&D at the company and I asked Ryan how hard would it be to come up with a generic GtkTreeModel implementation, in two days he put together libmodel-gtk!

This solves a quite important problem, GtkTreeModel, and abstract Model APIs are meant to be implemented pretty much for every use case unless you are doing extremely simple stuff, so that you can add smart filtering and sorting from the data source. However, the GtkTreeModel has an API quite hard to implement so everyone end up using List and TreeStore.

Now that we have a libmodel implementation, doing TheRightThing(TM) and wrap the API around the real data store becomes trivial. I quickly put together this twitter client using libsoup-2.4 and json-glib, and it is the first time that I have fun writting an data driven (let alone online) app for GTK+ in quite some time 🙂

Grab the source here, it's only 230 lines of Vala, most of it picture retreival/treemodel code actually, to compile it you'll need a fairly recent vala release. Copile using this command line:

~$ valac -g --thread --pkg gtk+-2.0 --pkg json-glib-1.0 --pkg libsoup-2.4 --pkg model-gtk model-twittfeed.vala

We are already planning having some standard set of providers, there's already a filesystem implementation in the model-examples repository, we are cooking a Tracker one and I should be adding a JSON one soon, other implementations are welcome! I would be quite excited to see SQLite, XML, CouchDB ones as well.

This is the kind of things that makes me really proud of working at Codethink, there's an exceptional bunch of smart guys willing to kick the complexity out of the way with elegance and simplicity!

Kudos to Ryan for this one, we should be putting together another release soon.

BuilDj’s first contribution patch!

Some news from the BuilDj front.

We've got our first contribution! Woohoo! C++ support was kindly added thanks to Simon Wenner, it is really nice to see people joining so soon! Thanks a lot Simon. I've been also starting to document the specification a bit in the l.g.o website.

I think I didn't make clear what my goal was in my last post given some of the comments. My goal is to bring IDEs and build systems closer, I'm using waf as a reference implementation, and honestly, because it's the only one that allows an alternative "front-end" and offers a development platform and hooks all over the place in a somewhat elegant way. As I said, CMake, Anjuta, Eclipse, NetBeans and all sort of implementations are more than welcome, but we need something to focus and try things out as a start.

By the way, I'll be hanging out in #buildj at irc.gnome.org in case anyone wants to collaborate!

If I was Microsoft…

…I would be demanding this to the EU right now:

 I think the EU got things the other way around this time. I don't think the EU should force people to make a choice of browser, specially taking into account that the web browsers choice should not matter as long as they respect standards. If IE does not respect standards, Microsoft should be punished for not respecting them. Let's face it, most people will choose based on which icon they think is the prettier, and honestly, I don't expect them to have a well informed choice, I think they shouldn't have to choose, the choice shouldn't matter. Obviously, the browser vendors do not care much if this is not the right approach as the ones pushing hard will benefit from getting a higher market and becoming part of an oligopoly.

The misconception here is that the so called ballot only fixes a symptom of a deeper and more important problem. The real problem here is Microsoft's monopoly over the consumer computing market, and the root cause of that monopoly is their draconian deals with the OEMs. I don't even have the choice to buy a Windows-less laptop, let alone a Linux preloaded one.

The EU should act immediately on that situation, and it is outrageos that it allows it while at the same time, they put so much energy in deciding what applications goes inside of Microsoft's own product.

I'm against this, because I think it totally goes against good principles when it comes to designing a good user experience for a product and I somewhat illustrate that with the picture above. By the way, who chooses which browsers goes there? Based on which criteria? How can the EU citizens revise that process? 

I'm against the EU having the power to decide which apps or user workflow goes in a software product, I find it outrageous on Windows, I would find it outrageous in Mac OS X and I would find it outrageous in a Linux distribution.

IE embedded in every copy on Windows is not the problem a copy of Windows embedded with every single computer we buy is.
(well, and maybe IE's total lack of respect for web standards up to some extend too)

How about this ballot for a real change:

 

Introducing BuilDj: Software Project Definition Format that GNOME deserves

In the GNOME beer event, I had a nice chat with ebassi about the problems around our build configuration system and how things like CMake, SCons and Waf do not get the full picture and do not cover some of the really strange corncercases that autotools supports and therefore, coming up with a solution would be a 1 year work with a team of really experienced engineers.

As stubborn as I am, I decided to prove him wrong so I give you BuilDj:

The Problem

My main problem with our current Autotools situation are these:

• It is not portable as it encourages strong use of Bash and command line tools which ends up making it really hard to use on a non POSIX system, you know, like that used by 92% of the desktop users, even if the source code itself is perfectly portable.
• It gets on your way, a lot. Sometimes I refrained from writing some testcases just to avoid to add the Autotools boilerplate.
• Really bad documented, still.
• You need to learn M4/Autoconf, Automake, Make and Bash to use it properly, as if learning C, C++ or Vala and worrying about the problem the programmer is trying to solve is not hard enough.
• None extends it because it's hard to extend.
• Its hard to read and understand even if you eventually wrote it yourself, makes code refactoring a big pain.
• You simply can't parse autotools and have an IDE or a continous integration tool to understand what's there.
• The most important one, it scares peoples away, damaging our mindshare, making potential contributors go away. It drains the fun out of our platform.

Requirements

We need a human+machine friendly project description format, that it's pleasant to the eye when you read it, that it's intuitive enough to let you understand what's going on even if you never saw it before.
A format that gets out of your way!

It should support all of the common tasks a GNOME maintainer does (in-line .pc and .desktop file definition, mkenums, gobject introspection support, cross-compilation support, pkg-config oriented, xdg mimetype registration/definition, integration with intltool), but it should suppor them in a meaningful and unobtrusive way.

It should not be a programming language, but support embedable programming extensions with a well documented API, so that IDEs can integrate it.

My Proposal

 A JSON description format called BuilDj that is build-system agnostic (although its reference implementation is done with Waf)

{
"project":
{
"name": "BuilDj Test",
"version": "0.0.1",
"url": "http://www.codethink.co.uk"
},
"requires":
{
"gtk+-2.0":
{
"type": "package",
"version": "2.14",
"mandatory": "True"
}
},
"targets":
{
"my_shared_lib":
{
"type": "sharedlib",
"tool": "cc",
"input": ["lib.c"],
"version": "1.2.3"
},
"my_gtk_program":
{
"type": "program",
"tool": "cc",
"input": ["gtk_program.c"],
"uses": ["my_shared_lib"],
"packages": ["gtk+-2.0"]
},
"my_vala_program":
{
"type": "program",
"tool": "vala",
"input": ["vala_program.vala"],
"packages": ["gtk+-2.0"]
}
}

I don't even need to explain what that means right? By the way, this stuff already works, check the git repository.

Currently it is implemented as a waf wscript that parses the project.js json file, I'm not really interested in entering the build system wars but focuing on having a reference implementation of the format.
I choosed waf because it was the only one that offered most of the features I want as an approachable API and it only adds python as a dependency.

Implementations of the format in other systems are more than welcome, but current development will stick to waf in the foreseeable future.

I'm planning to propose and mentor this work as a Summer of Code project so that we can implement the missing basic features and support for a few GNOME apps.

There's a lot of work to do, support for C++, library and function checking, system type sizes, full cross compilation support. We already have some mockups and plans for those, and the waf maintainer has shown himself quite happy to accept patches upstream for the general purpose tools and that make things easier.

Despite the missing features, it surprisingly itches some of my own scratches already.

P.S. Anjuta and MonoDevelop guys, if you're listening, I'd love to get your feedback!

On design, designers, engineers and inspiration

Being at the GNOME UX Hackfest even for just one day was an energizing experience, sort of eye opener in a way. And it made me think about the situation GNOME is been for a while (desktop-devel being dead, foundation-list too alive, and things like that…)

I tried to remember what made me contribute, and I remember that it was posts like this, the ones that made me excited and pushed me to spend endless hours learning about C and this GObject thingie, so that I can improve the very desktop I loved to use, and I could help to prove to the world that great and usable products could be made the opensource way. At some point down that path, I made GNOME technologies a goal of its own.and I stopped focusing on creating a great desktop (prolly because up to some extend the experiencie of trying to implement those ideas was not as pleasant).

I have the feeling that we, hackers, have done a pretty bad job at encouraging our designers among the community to challenge us and push the boundaries and goals of our own technologies further, actually, we've let those boundaries to stop the designers' proposals. Bad, bad, bad idea.

This is an open letter to the GNOME design community:

Folks, *BE VOCAL*, really, please, challenge us, communicate, blog post like there's no tomorrow, propose your stuff, draw mockups, file bugs… take over the project!

It can be difficult at times, we hackers can be quite energy stoppers, but please, ignore us, push design back in our veins. I want jokes and fun back to the project, I want pirate hats in our hackergotchis, I want Rupert jokes, I want a new planet theme, I want crazy pictures of crazy GNOME hackers doing crazy things. I want that magic back, and I have the gut feeling you can bring that back guys. It is only through design that we will enter new grounds, innovate and excite new contributors.

Update: RubenV just pointed me out to this example that nails exactly what I'm trying to communicate here.