Building GNOME Builder

At SCALE 13x in Los Angeles, Christian Hergert presented a session about his recent work on Builder, which is often referred to as an integrated development environment (IDE) for the GNOME desktop. But, as Hergert explained, the game plan for Builder extends far beyond the typical confines of IDE functionality. Builder, as he sees it, is GNOME's opportunity to reach newcomers who are learning about programming for the very first time—then to teach them the software-development skills that will help them become contributors.

Hergert started off by explaining the roots of the Builder project—a tale that began with a brief history of the GNOME project. Over the past 15 or so years, he said, GNOME has always placed a lot of emphasis on providing a good user experience. Often that has put GNOME in a position where it uncovers pain points elsewhere in the stack—many users, for example, first discovered bugs in their video drivers when they tried early versions of GNOME 3. Similar problems were uncovered with PulseAudio configuration and network-connection management when GNOME set out to implement better user interfaces for those subsystems.

One result of all of this work in other parts of the stack, though, is "the GNOME desktop environment" today means something much larger than the window-manager-and-dock that it meant in the early days. It includes a window compositor, media pipelines, input methods, filesystem abstractions, key management, tools for working with printers and devices, and APIs for geolocation and many other services. Thus, every year, the workload to maintain GNOME gets bigger—yet the GNOME community has remained approximately the same size for quite some time. Clearly, something more could be done to attract and cultivate new developers.

The other side of the story was Hergert's, rather than GNOME's. In 2012, he had published an open offer online, saying he would teach anyone the basics of coding in C if they just emailed him. Although he expected a handful of responses, he actually got thousands. In fact, he said, his inbox is still full of requests he has not had the time to answer. "And I'm a dinosaur," he added, "for using C. Imagine what the numbers would be if we were talking about Python or JavaScript."

Hergert tried to fulfill the C lesson requests students had asked for, he said, but ultimately failed. Initially he blamed himself for that, but, upon more reflection, he stopped taking it personally and started thinking about what sorts of questions the students had asked. The tools available were not up to the challenge: important utilities like Autotools were arcane and difficult to learn. But what struck him the most was that these students were interested in learning about free software, and the inability to "get started" with programming in general was essentially driving them away from GNOME and, presumably, toward other platforms.

What GNOME needs, he decided, is some way to guide newcomers through the getting-started process while also introducing them to the platform. Android, for instance, has a "developer mode" that does more than simply switch on new privileges: it also provides tools and helps the user learn about the software.

Those are the goals of GNOME Builder, the project that Hergert initiated in mid-2014. Builder will include an IDE, but the IDE will be geared toward developing software that works on GNOME—hooking into the build system, project management tools, diagnostics, and much more. Moreover, programming tutorials will be built-in, as will templates for working with GNOME libraries and a code-search tool that is linked to the GNOME source code.

The vision behind Builder is ambitious. Hergert voluntarily quit his day job to start the project; he was able to support himself for about four months working on Builder full-time, and subsequently ran a crowdfunding campaign that will pay for at least six more months of development time. In addition to himself, he said there are about 50 active contributors.

Currently the project involves two distinct pieces: the Builder user interface and the LibIDE shared library. It is "pre-pre-alpha," he said, but is fairly usable with C. Although he ultimately plans of focusing on other languages, Hergert said it was important to get C support working first in order to bootstrap the project. As of now, essential code editing, syntax highlighting, symbol resolution, and code search are working, and there is a sizable collection of boilerplate and template code for GNOME development that Builder can access. The initial keybindings and editor functionality implement a Vim mode, though Hergert said that an Emacs mode had landed just days earlier.

LibIDE is the focus of most of Hergert's development time. One of the more interesting features is live diagnostics: if the user types a syntactic error, the UI can highlight it using squiggly underlines akin to spellchecker warnings. That functionality is possible because the library uses Clang as its back end. Hergert said he would really like to use GCC as the compiler backend, but the GCC project's decision to not implement a library-like API (for things like accessing the abstract syntax tree) makes that impossible.

LibIDE supports Automake and Autotools at present, and will add additional build systems like Meson and CMake next. Similarly, although the library only supports Git version control now, other version-control systems like Bazaar are on the to-do list.

LibIDE is also scriptable with both JavaScript and Python. Hergert showed example scripts for automatically translating newlines on each save and for triggering a rebuild whenever a specific device (say, a Raspberry Pi) is attached over USB. The latter feature relates to Builder's support for cross-compiling—it is a specific goal to make Builder a useful IDE for writing programs for mobile devices and single-board computers. The scripting functionality can also be used to add new code-search providers, build extensions, and refactoring tools, he said.

He also discussed some of the GNOME integration work that is still under development. One example was writing a program that is meant to utilize a specific D-Bus service. The traditional approach might be to allow easy insertion of some boilerplate code, but that still leaves the user with the job of figuring out the right service to connect to and what syntactic sugar is required. Instead, LibIDE will provide a way to bring up a list of the currently running D-Bus services on the local machine; the user will only need to select the service of interest, and Builder will insert the properly customized code, rather than a blank boilerplate. Similarly, he hopes to have Builder automatically "do the right thing" for tasks like putting icons in the correct directory—tasks that, while supposedly simple, are often only dealt with well after development and during the packaging phase.

The session ended with a Q&A period. An audience member asked if writing the tutorials might be an opportunity to collaborate with an existing project like Codecademy. Hergert said that although he would like to do something like that, Codecademy is not a great fit, since it is not written with Linux systems (or GNOME in particular) in mind. Another question dealt with how Builder has uncovered pain points in the GNOME stack, like Hergert had mentioned at the beginning of his talk. He replied that there were some examples; he has decided that the normal GtkTextView widget does not work well for Builder's use case, and speculated that a "text grid" widget might be necessary, to correctly deal with monospaced text navigation.

In conclusion, Hergert commented that much of what goes into making an IDE work is not visible to the user. The Builder UI is minimalist; most of the work takes place behind the scenes: "if we do our jobs right," he said, "you won't have to care about anything but the UI." Looking forward, Hergert said that LibIDE and Builder will probably not be ready for inclusion in the upcoming GNOME 3.16 release (currently expected in approximately five weeks), but he thought that GNOME 3.18 was a reasonable target.