The GNOME developer experience hackfest [LWN.net]

By Jake Edge
February 7, 2013

For three days just prior to FOSDEM, GNOME contributors gathered in Brussels to discuss and work on the "developer experience". The developer experience hackfest was well attended, attracting people from all over the world. It was also quite productive, judging from various blog postings about the meeting. The headline decision—making JavaScript the preferred language for developing GNOME applications—was certainly noteworthy, but there were other plans made as well.

The JavaScript choice makes sense on a number of levels, but it also has clearly caused a fair amount of disdain to be directed at the GNOME project. Any language chosen would have likely resulted in much the same level of discontent. As Travis Reitter noted in his announcement: "The important thing was that we had to make a decision." That helps in having a single answer to the "how do I develop a GNOME application?" question, which is part of the justification for the move:

It allows us to focus when we write developer documentation, fixing bugs in the development environment and the development of tools. This reduces our [maintenance] costs and enables us to be vastly more efficient.
It enables code and knowledge sharing to occur, so that people can easily copy and paste code from existing applications, or find information about common problems and challenges.
It provide a coherent and easy-to-follow path for new developers.
It allows us to include the full GNOME framework within the language itself.

None of the existing supported languages are being deprecated because of the decision; it's really just a matter of focus for the project. While there have been a fair number of complaints heard about the choice, here at LWN and elsewhere, it's not clear how many GNOME contributors are among those disgruntled. On the other hand, some GNOME developers who might seem like candidates for grumbling are on-board with the change. John "J5" Palmieri is a big Python fan who worked on GObject Introspection for that language, but is pleased with the decision:

Day in and day out I work with many computer languages. While I may hold my favorites close to me, I have also come to recognize there are times when even languages I may not be fond of are a better fit for a particular problem space. Like it or not, JavaScript is pervasive and really is the way forward for rapid development in GNOME. It must have been a tense moment when the decision was made but I applaud that a hard decision was made and we can now move forward with a clear vision of delivering a great developer story for the GNOME desktop.

Another interesting discussion took place in the "application distribution and sandboxing" subgroup, as reported by Alexander Larsson. The group considered two different pieces of the application infrastructure puzzle: how to deploy (i.e. create, install, and run) application bundles and how to protect the rest of the user's session from application misbehavior.

For deployment, GNOME is considering having applications declare their library dependencies, in either a coarse or fine-grained manner, and then installing and running them in an environment that guarantees those dependencies regardless of what the system itself is running. That would be done using containers that provide a private view showing the platform dependencies that the application said it requires. As Larsson describes, there are some benefits to that approach:

With this kind of isolation we guarantee two things, first of all there will never be any accidental leaks of dependencies. If your app depends on anything not in the supported platform it will just not run and the developer will immediately notice. Secondly, any incompatible changes in system libraries are handled and the app will still get a copy of the older versions when it runs.

Beyond that, the idea of application isolation can be extended to provide a fully isolated sandbox for untrusted applications. It would require D-Bus routing in the kernel, which is proving to be a hard sell, but "hopefully this will work out this time", Larsson said. There is interest in adding a facility like the Android Intents system to allow sandboxed applications to communicate. Since that kind of communication implies a security domain transition, the group came up with the name "Portals" for this new feature. The discussion continues post-hackfest, he said, "hopefully we can start [to] implement parts of this soon".

The JavaScript decision was also helpful for the documentation subgroup, as Meg Ford and Allan Day reported. Those two, along with several others, started reworking the GNOME developer web site, including adding new tutorials for first-time application developers. Significant redesign of the site with several new features was discussed. Ford described some of those:

We had several new ideas which I think will really improve the resources for coding, including making all of the API documentation available as a single download (perhaps available in the SDK download). Another idea that I thought was particularly good is adding code search to the online API documentation so developers can easily find existing code in git.gnome.org to use as a reference. The idea here is to possibly use the re2 library, which Google open sourced after it shut down Google Code Search.

It would seem that the GNOME project has chosen the direction for its "developer story". That story is an important piece of the puzzle when trying to attract application developers to a platform. One could argue about the choices made, but it is significant (and important as Reitter said) that a choices was made. JavaScript is certainly popular, and many developers are already comfortable using the language. That may prove helpful in attracting some of those developers, but having one place to point when someone asks about developing a GNOME application is likely to be more important still.

(Log in to post comments)