I spent some time cleaning up the Rust C extension and the FFI layer to make it easier to consume from C and through GObject Introspection. One of the biggest changes was exposing the PitiviTimelineRuler instance type in the public headers instead of treating it as a generic GtkWidget. That gives GIR enough information to generate proper bindings automatically.

I also fixed an issue that only showed up in headless CI environments. The widget was previously relying on gtk::init() during type registration, which doesn't work well without a display server. Switching to set_initialized() solved the problem and made the test suite much more reliable.

Rendering Improvements

The rendering code also received a fairly large cleanup. Previously, the widget stored several pieces of drawing state separately, including adjustments, cached Pango layouts, and font descriptions. These have now been grouped into a single DrawingState struct protected by one RefCell.

Besides making the code easier to reason about, this reduces unnecessary borrow checks during rendering and avoids situations where only part of the drawing state could be updated while signals were being emitted.

I also introduced a labels_dirty flag so timeline labels are only recalculated when they're actually needed during the snapshot phase. That removes quite a bit of redundant layout work while scrolling and zooming.

Timeline Marker API

The custom layout manager is nearly finished, and with it comes a much simpler way to place widgets on the timeline.

I am currently wrapping up an add_marker() API that will allow attaching any GTK widget to the ruler at a specific timestamp. The PitiviTimelineLayoutChild now exposes the widget's timestamp as a GObject property.

I'm looking forward to getting this merged, as it should make timeline overlays and markers much easier to implement.

Stability Fixes

I also addressed a few smaller edge cases along the way. One of them involved enforcing a minimum value for min_tick_spacing_px, preventing potential divide-by-zero errors when calculating the tick spacing.

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!

A full-resolution album of these photos is available under CC BY 4.0 for anyone in the GNOME community to reuse. https://www.flickr.com/photos/204880226@N08/albums/72177720334807665/

Progress

We are rewriting the Pitivi Ruler in Rust using a modern GtkSnapshot rendering pipeline to improve performance and memory safety. At its current stage the ruler is being constructed as a standalone widget in a personal repository that can be found here:

Pitivi Timeline Ruler

GTK_DEBUG=interactive cargo run --example sandbox

Any feedback on the code is greatly appreciated!

Updates

The widget is drawing well and a lot of the initial bugs have been ironed out.

A major structural change that has been made after mentor feedback was to pull state orchestration out of the widget itself, and keep more of the logic on the app side. The goal is a "dumb widget, smart app" framework, where the ruler acts as a stateless viewport. The app (or sandbox example) provides the logic for how to handle gestures and what to do when the user interacts with the widget. One example of this is that project_duration was removed as a property entirely, and logic around bounds is now handled entirely on the app side. This allows the widget to be used in a variety of contexts, and allows the app to handle bounds in whatever way is appropriate for the context.

Beyond the pivot on structure, some key systems-level refinements were made:

• Property types we refactored heavily as this moved past the rough prototype stage. zoom_level received a rename to ns_per_pixel to better reflect what the property actually represents. Many properties dealing with pixels were changed to unsigned integers, which allowed me to delete out some negative checks.

• The project does now include a rough doc string and comment draft for the widget, which will be fleshed out more as the widget matures and more of the public API is finalized.

• Cache clearing was added to set_ns_per_pixel to prevent modulo math escapes during purging of cached layouts when users change the zoom level.

Next Steps

The major milestone ahead is the implementation of a custom gtk::LayoutManager to handle the layout of children widgets.

Once the PitiviTimelineLayoutManager is implemented, the playhead rendering will be moved out of the ruler's snapshot pipeline and into the layout manager as a distinct child widget. This will allow Pitivi to easily inject custom markers, loop-brackets, and multiple playheads without modifying the underlying ruler engine.

I am currently studying Marc-André Lureau's rdw (Remote Desktop Widget) repository as a guide on how to make this update.

Progress

We are rewriting the Pitivi Ruler in Rust and gtk4 snapshot logic to improve performance and memory safety. At its current stage the ruler is being constructed as a standalone widget in a personal repo that can be found here:

Pitivi Timeline Ruler

GTK_DEBUG=interactive cargo run --example sandbox

Any feedback on the code is greatly appreciated!

Structure

I am structuring this around rendering a single interval of ticks between two major ticks once, then stamping that across the duration of the project, as seen in draw_single_interval().

With the ticks stamped across the timeline I am then rendering a cache of Pango labels for the timestamps that are stamped across the visible window. I made the decision to use a BTreeMap for the cache for ease of iterating chronologically through the stamps and for dropping out-of-bounds keys. The logic for this cache handling primarily lives in update_label_cache().

After some feedback from members of the video editing community, I made the decision that minor ticks should always be clean multiples of frames in the time period. This logic is implemented in calculate_minor_divisions().

Next Steps

The primary goal I am focusing on next is implementing the gesture handling, including click and drag actions. Once gestures are implemented I am going to begin moving a lot of the math to traits so that I can write a mock_env and a live_env to start writing some unit testing.

This led to issues with truncated timestamps, and had a glaring issue with other framerates (like 30fps). I needed a more robust solution that could handle any framerate and provide accurate tick positions.

I assumed that I could extract the framerate directly from ges::Timeline, however there is no direct getter in the Rust bindings. After some digging, I discovered that the framerate is actually stored in the gst::Caps of the timeline's video stream as a gst::Fraction.

My Approach

The steps I used:

• Enumerate the timeline tracks (timeline.tracks())
• Filter for the video track (checking ges::TrackType::VIDEO)
• Read the track's restriction_caps
• Extract the gst::Fraction

My helper

I wrote a helper function to extract the framerate from the timeline:

pub fn get_fps(&self, timeline: &ges::Timeline) -> Option<(i128, i128)> {
    timeline
        .tracks()
        .into_iter()
        .find(|track| track.track_type().contains(ges::TrackType::VIDEO))
        .and_then(|track| {
            let caps = track.restriction_caps().or_else(|| track.caps())?;
            let structure = caps.structure(0)?;
            let fps = structure.get::<gst::Fraction>("framerate").ok()?;

            // Extract the safe numerator and denominator
            Some((fps.numer() as i128, fps.denom() as i128))
        })
}

// ... inside the timeline injection logic:
if let Some((fps_num, fps_denom)) = self.get_fps(timeline) {
    self.fps_num.set(fps_num.max(1) as i32);
    self.fps_denom.set(fps_denom.max(1) as i32);
} else {
    // Default to 23.976 if we can't find a valid framerate caps
    self.fps_num.set(24_000);
    self.fps_denom.set(1_001);
}

I make some assumptions here, such as only one video track existing, and that the framerate is always present in the caps. This solution made the tick spacing and labels line up with the timeline’s actual frame boundaries at any framerate.

A bit about me

I am a Computer Engineering student and long time Linux user. GNOME has been my desktop environment for years and I was very excited to be working with the GNOME foundation.

I have a fairly significant amount of custom tooling that was all in Python and Bash, and about 16 months ago I began rewriting it in Rust, primarily to learn, however the performance and reliability improvements were quite noticeable. This led me to rewrite all of my scripts and tools in Rust. That experience put me in a great position to tackle the Rust rewrite of the Pitivi timeline ruler.

The Summer Project

The plan of attack with this project is first to create a standalone GTK4 Timeline Ruler widget in Rust, then modify Pitivi to use the new ruler via PyGObject.

I am currently building a basic test binary, which can be found at Project. This will be used to test the functionality of the widget and to ensure that it is working correctly before integrating it into Pitivi.

I am very excited to be working on this project and I look forward to sharing my progress with the community. I hope to learn a lot and contribute something meaningful to the GNOME ecosystem.