Rust ūüĖ§ GNOME Hackfest – Mexico City, 2017

Glorieta del √Āngel de la Independencia, Credits: laap mx@flicker cc-by-nc-nd

As you know a bunch of GNOMies have been in touch with Rustaceans to improve the Rust and GNOME binding integration. To accelerate the effort, we have decided to organize a hackfest soon-ish. After¬†some digging and given that the great Federico has been involved in the effort we’ve figured that it was rather poetic to do it in Mexico City, birthplace of GNOME! Check out the wiki page for more details.

We will be meeting at the Red Hat office from the 29th to the 31st of March to try to advance the state of GObject bindings and try to make Rust emit GObject code as well. Get in touch with me or Federico if you want to attend!


First Rust+GObject coding session

Last Wednesday, Nicholas Matsakis from Rust/Mozilla and I sat down on a video chat to start getting our hands dirty on moving ahead with making Rust a part of the GNOME ecosystem.

While there are two efforts to produce GNOME bindings for Rust, gi-rust and gtk-rs, however none of them provided the means to emit GObject subclases so we decided to tackle this problem.

During the first half of the session we reviewed how GObjects are created from C, I used Vala’s output to illustrate how this is done. We didn’t dive¬†on too much detail on how properties and signals are emitted nor interfaces, however¬†we focused on detail on how to inherit from a GObject.

After that we went ahead and wrote what, probably, is the first piece of Rust code that emits a GObject in this playground repo. Nothing too fancy, but a starting point to get us somewhere.

The next step is to figure out how to take this and turn it into something that a Rust developer would find Rust-like. One of the options we’re exploring is to use Rust macros and try something like this:

  class Foo : Bar {
    fn method_a () -> u8 {

The other alternative would be to decorate structs, traits and whatnot, but this would be a bit more cumbersome. Turns out that Rust’s macro system is quite powerful and allows you to define a custom syntax.

That’s the progress so far, the next step would be to try to start implementing¬†some bits and pieces for the macro and see how far we can get.¬†I’d like to thank Mozilla and Nicholas specially for the amount of attention and effort they are putting into this, I must say I’m quite excited and looking forward to make progress on this effort.

Stay tuned, and if you’d like to help don’t hesitate to reach out to us!

Thoughts on DX: GNOME and Rust

A few months ago I spent some time to learn some basic Rust, I was interested in¬†getting an informed view of the language, specifically about the¬†safety and concurrency idioms as well as its compatibility with the C ABI and automatic memory management¬†while being¬†non GCed. I must say I was pleasantly surprised with the tooling, cargo is a breeze and is a wonderful resource. More recently though I’ve been investing time to actually understand¬†the memory ownership model and how it plays with channels/concurrency. I must say that what these guys have achieved is really clever with a language that once you get the grasp of things feels actually really nice to use.


For a long while now I’ve been worried that the GNOME project would struggle to grow its contribution and stay attractive if it stuck to C in the long run (i.e. next 10-20 years). GObject hasn’t really caught on beyond the GNOME ecosystem. So we’re basically maintaining a whole low level framework, and we have to come up with something by ourselves everytime a new technology comes in (i.e. JSON, REST…). Given our limited resources, I’ve been wondering if there are better alternatives.

For people wanting to contribute to the core libraries consumed by the ecosystem, the only options are C and Vala.¬†Vala has been a great tool for prototyping, I love it myself, but¬†debugging it is a nightmare, it’s filled with security issues and even if we fixed those really difficult problems, we’d be maintaining our own language on top of everything else. I would like to see us maintaining less stuff other than a desktop and the application development framework, not more.

I trully believe Rust gives us a way out of this situation, with certain nice side benefits, Rust really ticks¬†most boxes: C ABI compatibility, safety, modern syntax, vibrant community, ever growing set of libraries and tools and a culturally aligned organization backing it: Mozilla. So when Federico made the brave step of start using it in one of our libraries I was very encouraged by the notion that this might actually happen. I’ve been pleasantly surprised to see positive reactions to his effort by many core developers on twitter.

Now, imagine for a moment, that we decide to somewhat¬†embrace Rust in our libraries, and we start adopting it in places like GTK+. Suddenly we have the opportunity to engage in the¬†growing enthusiasm around Rust, and we have a channel to technologies and tools being built outside of our own community such as WebRenderer,¬†Servo…

Additionally, we release ourselves from the burden of maintaining core libraries for everything so we can focus on producing a great desktop and application development story.

Ultimately though, there are many challenges, achieving full GObject compatibility can be difficult, we would need to be able to consume GI bindings from Rust and eventually emit GI bindings too, and in the end it would be up to the core of the community to lead an effort like this so there needs to be consensus too. It is quite a bit of work, but I believe it is worth considering as it might give us back a lot resources to focus on other stuff.

Please don’t read this as a formal proposal, I think something like that should come,¬†I’m mostly putting my thoughts on this out there and see what the rest of the community thinks.

Need an ARM board to do GNOME development?

Now that the donations are in, it’s time to start putting them to use. If there’s any cool project you would like to use one of the available ARM boards or if you’re interested in doing enablement of those boards to make GNOME run on them please get in touch with me on IRC or drop me a line at aruiz¬† gnome org.

I have to note that requests to use them as your home server or for non-GNOME related stuff are discouraged, these boards were donated with the purpose of improving support for the ARM ecosystem in GNOME.

Here’s the list of the HW and who has them.

There are a few Banana Pi available (most with a Mali 400 GPU and two BPi M2s with a PowerVR SGX54MP2), so these are trickier to get GNOME Shell running on, if anyone enjoys reverse engineering GPUs, Malis are very popular these days and they get very little love as the Lima project is a bit silent for some time now. People looking into porting llvmpipe to ARM are also more than welcome!

As per the Qualcomm boards, they run with the freedreno driver (by the way, props to Rob Clark for his amazing work on this driver) and I was able to run a GNOME on Wayland  on them using the official Debian image, so they are more suitable if you want to focus on the upper layers of the stack.

I would like to reiterate my gratitude to Banana Pi and Qualcomm for their generosity for the hardware, as well as ARM and Codethink for the server side stuff that is already being used in our GNOME Continuous efforts.

And of course, I’m going to GUADEC! I’ll be taking the boards with me, so if you think you have something interesting to do with them and you are attending just find me around.


GNOME Foundation is looking for ARMv7 hardware

The GNOME Continuous effort is proving a great way for the project to achieve, however right now we’re only building and testing things on Intel based architectures. As ARM devices like the Raspberry Pis, Cubieboards, C.H.I.P.s and the just announced Endless Mini become more prominent we want to make sure GNOME software is ready for those platforms as well to the extent possible.
gnomelovesarmSo I have asked the board for permission to try to reach out to organizations willing to donate ARMv7 servers to the GNOME Foundation for our continuous infrastructure. If you know of any organization (company, foundation, university…) with access to such hardware that might be willing to lend or donate it to us please get in touch with me at aruiz at gnome dot org.

Note that we don’t really need physical access to the hardware as long as it’s connected 24/7 on a decent internet connection.

Thanks a lot!

Updates on GNOME Calculator

GtkBuilder templates

Last GUADEC Michael Catanzaro asked for help out loud trying to find a new maintainer and I decided to take the bullet. For a couple of months I felt a bit guilty since I was merely doing new tarballs containing pretty much just translations.

However at some point a couple of months ago I sat down and started reviewing patches people were submitting and got up to speed with the current state in bugzilla, the review process allowed me to get familiar enough with the codebase to start finding things I would enjoy doing.

The biggest task I’ve been trying to accomplish is to move all the UI code to GtkBuilder .ui files and rework the codebase to use them as reusable templates. Vala has great support for this, here’s an example on how to create a MathWindow class, with a widget as a private member and a callback:

This has allowed me to remove quite a few lines of code making the project a bit more maintainable. It has been also a good opportunity to get familiar with gresource

DX Hackfest & XDG App

During the DX hackfest I spent some time to package GNOME Calculator as an XDG App, the only problem the app had was that it was using gvfs to retrieve currency data from the network. I ported this to ye’olde libsoup and everything went on smoothly. On the third day I caught a bad case of food poisoning so on the last day of the hackfest I was rather useless.

I would like to thank Philip Withnall for organizing the hackfest, Javier Hernandez for hosting me in his couch, our friends from the Betacowork space in Brussels for coping yet another year with the GNOME and LibreOffice hackers, and the GNOME Foundation as well as many other companies for sponsoring people to attend.

Incoming! Fleet Commander 0.7

We’ve just released the 0.7 series which should be the first version that is somewhat stable to use (think of it as alpha) and as we speak is under review for inclusion with Fedora 24.

For the last year I have been massaging the prototype we had at GUADEC in Strasbourg into a reliable product, and recently Oliver Gutierrez has joined the team to help with the web development affairs, I would like to summarize some of my work here so that you guys know what’s all about and what are the future plans.

For those unfamiliar with the project, Fleet Commander intends to be a centralized configuration management interface for system administrators managing GNOME deployments. Think about schools, universities or an office (either small or big). The idea is to reduce the amount of work needed to centralize the customization of the user experience. These days most sysadmins use a bunch of scripts, packaging or manual configuration machine-after-machine to achieve this goal.

Screenshot from 2016-02-03 17-53-23.png

Fleet Commander in action

The screenshot above shows the main profile editor, those who remember the Sabayon tool might be familiar with this concept. What you see is a virtual session running on libvirt, and basically picking up a VM I created with Boxes as a template. The idea is that the sysadmin replicates the “base image” that the users have in the network inside a VM, and makes the configuration changes that he needs.

After that the profile is placed as a json file and you can control which users and groups it applies to from the admin UI. This files are served by an HTTP endpoint that is consumed by a host daemon that retrieves all the profile data, turns each profile into a dconf db, and creates a dconf profile that aggregates all those dbs at login-time.

Right now this will work on anything that uses dconf (except for some potential issues where people use relocatable schemas), Stephan Berg from LibreOffice fame has written dconf support upstream and will make things magically work.

We’re quite proud of the release but the setup is a bit more complicated that I’d like it to be (we need to exchange an SSH key to access the libvirt host), future plans include FreeIPA/SSSD integration and migrating the UI into a Cockpit plugin which will make our codebase a lot leaner to maintain.

We’re working on an updated wiki page to explain how to set it up once it hits Fedora 24, stay tuned!