The GNOME platform in the 0 cost application deployment era

We’re living interesting times, the web is gaining momentum, the explosion of the smartphones and the mobile market is changing the ways people think about computing, the model to deliver applications and services to the consumer and his role in the usage has radically changed.

The way people create, build and deploy applications has radically changed, 10 years ago you couldn’t even think about deploying a large application without packaging it in a box with a manual and spend large amounts of money to deliver it to the shop shelves, you couldn’t even think about people actually buying it without some sort of advertising in the hi tech magazines.

Today, all that it takes to check what’s new and exciting is a browser, even if the application you want to try is locally installed. In this regard, the traditional closed desktop provides a pretty well understood deployment model for ISVs willing to create and deliver an application, a .msi installer on windows, a .dmg image for Mac OS X where you just drag and drop an icon to your app folder.

Platforms like the iPhone and Android makes application creation, packaging and distribution a well documented straightforward process, except for one thing, their app stores are censored so we have an advantage here that we are not exploiting.

The Unix world in general, and the Linux world in particular is a little special in this regard. By nature, we have a diversity of tools to manage and deploy applications and libraries in our system (yum, apt, ips, ports…), tools like PackageKit can overcome some of the problems of such diversity, although it is getting mainstream slower that we would like to. In general users should be alright with this as things stand today.

However, it is not the users the ones I’m worried about here, it is the CS students and enthusiast wanting to do small fancy apps, it is the small companies with no resources to employ a team of package maintainers to create and maintain a dozen versions of packaging scripts. The very people with the talent to create new exciting apps that can attract and engage users, the very people that can create an ecosystem where creating and distributing large apps for Linux is not a path full of pain. Applications like Photoshop, Autocad, SPSS are not going to get open sourced anytime soon, some of them may never be, the question is, can we attract them to make the free desktop a more appealing option for users? For some people and institutions those apps are the one and only reason to stick to Windows or Mac, so this problem is worth considering.

Yet, it doesn’t look we are getting close to support application distribution models klik in the upstream desktop environments where you could download a file and run your app straight away. This is what the developers want. This is what the users want. We are just not listening them here.

Creating apps for our stack is a pain in the ass, the good practices are fairly undocumented, essential resources are fragmented within several web sites, with different APIs models, there’s a lack of consistency and ease of use. Yes, I know, this is open source, this is the way it’s been so far, you can’t kill diversity.

But… I think we are in a point in time where it is critical to assure our success, or the spreading of freedom we envisioned might be threatened by our competition and we will lose large amounts of control over our technologies as a community once again. Most importantly, I do not only think these radical changes are necessary, I think that we can actually make them happen with no much effort, we just in need for some focus and learn from what others have done to make their platforms attractive. We can bring our stack back to the peak of innovation and leave behind our early 90’s development and distribution style once and for all.

We already have a compelling desktop people want to use, it’s been a hell of an effort to get where we are, things like the new Shell and Zeitgeist can give us some hype on OSNews and Slashdot, but at the end of the day, innovation happens elsewhere, so we better focus on empowering all that creative and passionate people out there who wants to create apps that their family and friends can use.

On GNOME Shell

One thing that came to my mind after the summit was that after John McCann’s presentations on various GNOME Shell topics, people went from the so called ‘gnomeshellskepticism’ to actually start getting it, and by the end of the event most people were using it by default.

A lot is yet to be done to get it to a final state and they seem to have a real vision for it. But it was still bugging me the fact that an explanation of the philosophy and showing some of the features in action made such a difference.

After realizing this I somewhat started to considering that a first login introduction in form of an assistant or a video could make a huge different on terms of success of adoption of the new shell, this approach works pretty well for games, where usually the first time you play it there’s some sort of introduction showing you the basic controls and the interface.

Boston Summit Fun

I’m at the Boston GNOME Summit at M.I.T. nice to visit the US a second time and get a grasp on another city. This is my first summit and so far it’s been really nice to experience a different kind of event than GUADEC. I like the environment and the fact that is less crowded and more relaxed. It allows you to have the time to actually talk quietly with the people around.

Gtk+ Font Dialog Revamp

A while ago I tried to approach the Gtk+ standard font dialog usability issues and started some discussions in my blog.

After having some discussions that didn’t really help me to get anywhere, I decided to find someone with a real usability background so I poked Máirín Duffy and she agreed to team up to solve this problem by doing some mockups for me to implement in pygtk and the run usability tests with the prototypes.

I’m glad I found someone to actually approach this problem from a proper UI design cycle rather than making things up based on gut feelings and random suggestions from other developers based on their personal preferences.

In about a week we should be able to come up with the first prototype.

GSettings/dconf

Ryan and myself have done some PR on dconf and GSetings and trying to push the proposals of inclusion of the basic infrastructure into GLib to move forward. It seems we have a way forward. This is good news for the de-Bonobo-ization goal for GNOME 3.0. and getting a more performant configuration system and a proper GObject friendly API for the platform.

GNOME Shell

Loads of sessions and audience around the GNOME Shell projects, I have to say that I’ve been exceptic about the direction of the Shell, but after the sessions and the overview of the RedHat guys and been running it from Karmic for a while I think it’s coming along not that badly and that we could get.

Generic data model for GObject: libmodel “Is this going to be forever?” 0.1

I present you libmodel 0.1.

We’ve been busy at Codethink lately, one of the projects we came up with is a long overdue generic data model library for GObject.

Let me give you a bit of background. As Martyn mentioned already, Tracker 0.7 is out, and with it there’s a new lot of possibilities than just storing metadata from your filesystem. Thanks to our GSoC, Adrien Bustany, we’ve got flickr, facebook and twitter miners, that allows us to store feed streams from these social networks locally. Also, more and more data providers are showing up in the GNOME stack, like Google Data and CouchDB libraries.

Building applications on top of Tracker using the D-Bus/SPARQL interfaces directly seemed a bit of an overhead for us and as stated by many people already, the current situation in GObject about abstract data models was not any good, until now.

So we decided to take this bullet and see what can we came up with, Ryan Lortie did some research on the existing solutions within other popular frameworks (.NET, CoreData, Java, Qt) and came up with this first approach, that has already served us quite well.

Some of the design goals are: high bindability for other platforms to be able to implement the data model abstract classes/interfaces, lazy loading of data within a collection, atomic signals for notifications of multiple changes in a collection, simplicity and more importantly, it should be FUN to implement a model and use it.

libmodel is implemented in Vala to allow us to move quickly to an API that we are happy with, as for now is a collection of abstract classes for Lists, Dictionaries, References and Objects. check the documentation and the source code for more info. Note that this work has to mature and that we already have some changes in the current API planned.

Have fun with it, and let us know what you think about it! Oh, and stay tuned as more tasty bits are yet to come.