Timeline UX & Ripple Performance

Help
1

I want to gather several suggestions related to Kdenlive’s UI and timeline behavior in a single post, and also describe a performance issue that I consistently run into when working with large projects. Some of this may already exist — if so, I would appreciate pointers on where and how to enable it.

UI and Timeline Navigation

  1. Centered playhead mode during playback
    A mode where, during playback, the playhead stays centered on screen while the timeline itself scrolls. Similar behavior exists in many DAWs and other timeline‑centric editors. This greatly simplifies working with long timelines and reduces the need for constant manual scrolling.

  2. Select clips under the playhead across all tracks
    A command or tool that selects all clips on all tracks intersecting the current playhead position. This would be useful for synchronous operations on video/audio or parallel tracks with identical structure.

  3. One‑shot command to center the view on the playhead
    A dedicated action that shifts the timeline so the current playhead position is centered in the visible area. Not a mode, but a single operation suitable for a shortcut.

  4. Clip Monitor and Project Monitor in the same panel
    The ability to place the Clip Monitor and Project Monitor into the same dock area (for example, via tabs or a split view). This would save screen space, especially on smaller displays.

  5. Timeline track list is too wide
    The left side of the timeline (track headers with mute/lock/etc. icons) takes up a significant amount of horizontal space. It would be useful to:

    • make it narrower;

    • add a compact mode;

    • or allow auto‑collapse / minimization to a minimal width.

  6. Project Monitor bottom toolbar
    The toolbar under the Project Monitor consumes noticeable vertical space. During active editing it is rarely used, except for occasional checks of the project’s end time. Making this toolbar hideable or collapsible would help.

Performance and Ripple Editing

The main issue is ripple‑editing performance on large timelines.

Context:

  • projects with 1000+ clips;

  • active work near the beginning of the timeline (operations get faster closer to the end);

  • frequent frame‑by‑frame ripple operations.

Observations:

  • Ripple operations become very slow with a large number of clips.

  • A single small ripple step (1 frame) can take up to ~3 seconds.

  • During this time the UI feels blocked, which severely disrupts editing flow.

There is also a behavioral issue:

  • Ripple editing via shortcuts requires multiple steps:
    select clip → move playhead → trigger command.

  • When shifting by 1 frame:

    • it works correctly in one direction;

    • in the other direction it requires a 2‑frame move, and the operation effectively removes an extra frame.

Actual Workflow and the Bottleneck

I actively use a macro pad with an encoder, mapping long key‑press sequences to a single encoder step. For example, one frame‑level ripple operation is implemented as a macro like:

Num 2 → Num + → Left → Left → Shift+9 → Num 2 → Num + → Left → Left → Shift+9

This setup exists because:

  • I work with two parallel tracks containing clips of identical length;

  • one encoder step = ripple for two clips;

  • the number of key presses is not an issue — I can map as many as needed.

The problem is not macro complexity, but performance:

  • one encoder step = ~3 seconds of waiting with 1000+ clips;

  • especially slow near the beginning of the timeline;

  • faster toward the end, which suggests O(n)‑like behavior relative to timeline length.

I really enjoy working with a macro pad — it simplifies editing and reduces cognitive load. However, at this point I am not limited by UI design or missing features, but by the performance limits of the software itself.

Questions

  • Is this a known limitation of the current ripple algorithm?

  • Are there plans to optimize ripple/editing operations for large timelines?

  • Are there recommended settings or alternative tools/workflows that scale better with 1000+ clips?

Any feedback, pointers, or references to existing functionality I may have missed would be greatly appreciated.

2

This is coming in one of the next major releases, probably as early as 26.04. IIRC, it’s already in the daily builds.

Select clips under the playhead across all tracks

Hold Shift when moving the mouse to select the clips the mouse goes over. Admittedly, this is not a straight Press This Key to Select All Clips Under the Playhead but close enough in my book.

One‑shot command to center the view on the playhead

This may come with the centered playhead feature above. But I like the idea and we should keep this in mind.

Clip Monitor and Project Monitor in the same panel

You already can do that. Not the split view but they can be placed in the same area and you can switch back and forth.

The left side of the timeline (track headers with mute/lock/etc. icons) takes up a significant amount of horizontal space.

I would like to see a proposal for that. Even on my fixed dimensions laptop screen I don’t mind the space the track header occupies, And info about track status is important. IMO, you really don’t gain that much space on the timeline, and for what? A few more frames? You are better off to use the zoom function of the timeline to focus in the area of interest.

Project Monitor bottom toolbar

There is WIP to optimize that. Not sure whether the Qt framework allows it to be collapsible but I do like the idea. Perhaps other users can chime in?

Which direction works? Can you please be a bit more specific?

Are there recommended settings or alternative tools/workflows that scale better with 1000+ clips?

Perhaps using sequences for logical groups of these clips may alleviate that? I don’t work with that many clips but I know that for ripple edits Kdenlive has to touch every single clip on one end of the ripple (depending on the direction).

3

On Windows you can have clip and project monitor in the same panel and switch by shortcut t between them.

On which OS are you? A possible fix was just rised.

4

Thanks for the tip — yes, holding Shift and dragging to select clips does work.

The issue I’m running into is more about single, atomic operations, especially when working mostly from a macropad / keyboard. Right now, if I want to reliably select exactly two clips under the playhead, I end up needing four key presses: num 1 → num + → num 2 → num +. That’s assuming audio and video are already linked. If they’re not linked (which happens quite often), the number of actions grows even more.

What I’m missing is one dedicated action that simply selects everything under the cursor in one go. Something optimized specifically for that use case, without having to carefully manage additive selections.

About the Clip Monitor / Project Monitor thing: you’re right, this one is on me. I was using the Snap version of Kdenlive (25.11.70), where this apparently isn’t available yet. I honestly didn’t realize there was already a newer version where this is implemented, so I assumed the feature just didn’t exist.

Regarding timeline horizontal space and track headers.

I’m working on a ~15" laptop. When editing vertical video, I usually dock the Project Monitor on the right side of the screen. On the left side, I almost always keep the Project Bin open, because a horizontal list works best for me. As a result, the timeline itself is already squeezed from both sides.

On top of that, the track headers take up a fairly large chunk of horizontal space. Personally, the only controls I ever use there are:

  • Hide track

  • Lock track

That’s it. I don’t collapse tracks, I don’t use the other buttons. Even with all buttons visible, there’s still a lot of empty space in the headers.

From my perspective, two possible improvements would help a lot:

  1. A compact / minimal track header mode that shows only Hide Track and Lock Track, with minimal padding.

  2. Or the ability to fully collapse track headers, leaving just a very thin strip (something you can grab or click) to expand them back when needed and access Hide / Lock quickly.

Either option would be a big win for small screens.

Finally, about Ripple (especially keyboard-based ripple operations). You asked for clarification, so I’ll try to describe it clearly.

Imagine two clips with a cut between them, and the playhead is exactly on that cut.

Left clip:

  • To increase the length of the left clip:

    • select the left clip

    • move the playhead two frames to the right (Right Arrow ×2)

    • press Shift+0
      → the clip grows by 2 frames

  • If you move the playhead only one frame to the right and press Shift+0, nothing happens. Increasing the left clip by one frame is not possible this way.

  • To decrease the left clip by one frame:

    • select the left clip

    • move the playhead one frame to the left

    • press Shift+0
      → this works as expected.

Right clip:

  • To increase the right clip by one frame:

    • select the right clip

    • move the playhead one frame to the left

    • press Shift+9

  • To decrease it by one frame:

    • select the right clip

    • move the playhead one frame to the right

    • press Shift+9

So the asymmetry is that:

  • right clip: can be increased and decreased by 1 frame

  • left clip: can be decreased by 1 frame, but increased only by 2 frames, not 1

That inconsistency is what feels off, and it becomes very noticeable when doing precise keyboard-based ripple edits.

Hope this explanation makes sense.

5

That was actually me. I opened that merge request myself and tried to tackle the issue directly.

To be honest, I was doing it a bit blindly — I didn’t fully understand all the internals and UI logic at the time. Still, in my local build it more or less worked, even though there were some UI glitches and layout issues.

At this point, it’s very possible that the real solution for me is simply updating Kdenlive, since this seems to be already addressed properly in newer versions. I just didn’t realize that earlier and assumed the feature was missing.

That said, if my merge request turns out to be useful in any way, that’s great. If not - it was a useful experiment on my side :slight_smile:

6

Snap is not officially supported, and the version you stated hints at a daily build. I highly recommend to use the Flatpak or AppImage versions of Kdenlive from our website.

The track header issue is worth looking into, so we’ll keep that on our radar.

That inconsistency is what feels off, and it becomes very noticeable when doing precise keyboard-based ripple edits.

That should be a bug report. Do you care open one? Thanks!

7

Then put the timeline below them, if optimising the width of the timeline is important to you?

Or create a secondary layout to switch between for when it is, isn’t?

Removing useful things from the timeline to support a somewhat pathological layout where it’s been deliberately squeezed into a tiny part of the available space doesn’t seem like the Ideal Answer for this one?