When Felipe first emailed us about the GUADEC 2026 travel grant, we were thrilled to learn that we were going to have the opportunity to attend the conference in person.

This was my first GUADEC, and it was a pleasure to meet the GNOME community and put faces to names. The conference was held in A Coruña, Spain, which turned out to be an amazing city with great food, friendly people, and beautiful views along the coast.

Community

The first thing I would like to mention was how patient and open the community was to both my fiancée Laureen and me. We knew going into the conference that we were much more junior than many of the developers attending, but everyone was incredibly approachable.

I received a great deal of help debugging issues in my local development environment, as well as guidance on some of the more difficult parts of my GSoC project.

Talks

The talks were very informative and I took way too many notes to include them all here without turning this into a novel. That said, I wanted to write a short summary of a couple of talks that I found interesting:

Varlink for System Components

Sebastian Wick gave a talk about modernizing the system component stack. His proposed idea for allowing more memory safety and zero cost abstractions was to write components in Rust, however this introduces the issue of introspection. For asynchronous functionality, Tokio and Glib both have main loops, and moving data between the loops can introduce a lot of overhead. GObject bindings can also make Rust's memory safety essentially moot.

Sebastian spoke about potentially not using GObject in some cases, and instead exposing more functionality over IPC using Varlink. Varlink is language agnostic, and services could be consumed from many languages without requiring GObject bindings. This process also would be very simple, allowing signals to occur as JSON strings that are easily observable. This would require some new crates to replace Glib functionality, and some more complicated functionality like file thrashing and sftp could be particularly difficult.

It is early, the ecosystem is still being built, but Sebastian argued that usage patterns will evolve and getting involved now will help shape the future of GNOME and Rust.

Using GTK in C++ with Peel

Sergey Bugaev hosted a workshop on using GTK from C++ with Peel. Peel is a library that allows you to use GTK in C++ to make GTK applications and widgets. Sergey made a simple widget that can draw using stylus input, and he walked us through the process of creating a simple application using Peel. The workshop was very informative.

I really regret not coding his example myself, I wish a recording of the lecture had been taken. That said, his repo can be found at https://gitlab.gnome.org/bugaevc/peel and his readme has instructions for usage and a basic code example.

Debugging with Tracy

Ivan Molodetskikh gave a talk that seemed really handy to me about using Tracy to profile performance for Mutter, GNOME shell, and applications. I had never heard of Tracy before this talk, however the capabilities seemed very handy. Tracy visualizes "zones" on a timeline, allowing you to see exactly where execution time is being spent across threads. The Tracy zones must nest correctly, where parent zones cannot end before their child zones. It can also show where threads are waiting. This allows for a very clear visualization of where time is being spent in the application, and can help identify bottlenecks or bugs.

The major downside to Tracy is that it requires a lot of setup, and the application must be compiled with the Tracy client library. Ivan gave a fairly in-depth breakdown of how to add Tracy profiling to an application, and I will go back to the recording of his talk to actually implement it in the future.

Technical Take Aways for My Project

• Sergey Bugaev helped me get the GIR generation for my C API working correctly. We also improved the FFI by exposing PitiviTimelineRuler directly in the public header rather than accepting a generic GtkWidget* and performing a runtime type check. This makes the API more type-safe and simplifies the Rust implementation. The GIR generation currently works after calling gtk::init() from pitivi_timeline_ruler_get_type() , but Sergey pointed out that this approach will likely fail in CI because the generated scanner shouldn't require GTK to be initialized this way. I'm still trying to build a solid mental model of how GIR generation and introspection work, so if anyone has experience with bindings, I'd love to hear your thoughts.

• Federico also spent some time reviewing my project with me. He suggested refactoring PitiviTimelineRuler so all of the mutable drawing state lives inside a single RefCell rather than several individual ones, I think the result would look something like this:

#[derive(Default)]
struct DrawingState {
    cache: BTreeMap<...>,
    font: Option<...>,
    handler_id: Option<...>,
}

#[derive(Properties)]
#[properties(wrapper_type = super::MyWidget)]
pub struct MyWidget {

    #[property(get, set)]
    zoom_level: Cell<u64>,

    state: RefCell<DrawingState>,
}

Thanks to GNOME Foundation

I want to give a special thanks to the GNOME Foundation for granting us the travel grant to attend GUADEC 2026. It was a wonderful experience and I look forward to attending future conferences in person!