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
GNOME applications—was certainly noteworthy, but there were
other plans made as well.
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
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
not clear how many GNOME contributors are among those disgruntled. On the
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
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
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".
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
attract application developers to a platform. One could argue about the
choices made, but it is significant (and important as Reitter said) that a
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.
to post comments)