Sidebar: keep a thread in a fixed position with Pin here

[jamesainslie]

Problem or use case

When arranging several ongoing threads, I want to keep a reference or coordination thread in a familiar position while new work arrives above the other threads. For example, a thread placed in the third row should remain in the third row when I start another thread.

Manual Active ordering already landed through #9729, #9730, and #9731, resolving discussion #6985. That covers reordering and cross-device persistence. New threads intentionally appear above the arranged Active threads, so an existing thread's numbered position still changes.

Proposed solution

Add an optional Pin here action to hold a thread at its current numbered position. Keep the existing pin-to-top behavior available separately, and provide an explicit way to release the fixed position.

For example, starting with A, B, Reference, C, pinning Reference in the third row and creating New would produce New, A, Reference, B, C.

Smallest useful scope

Extend the existing ordering behavior with fixed-position placement, using the same saved state across web, desktop, and mobile. Existing manual reordering, section dragging, and settlement rules should remain the foundation. This proposal does not require a replacement ordering system or a new workspace/grouping feature.

Alternatives considered

The existing pinned section keeps a thread easy to reach, but always places it above Active work. Manual reordering lets me choose a relative order, but new arrivals change the numbered position. Repeatedly moving the reference thread back works but adds a maintenance step.

Risks or tradeoffs

Fixed positions add another concept to the sidebar, so the benefit needs to justify the extra action. Before implementing this upstream, the behavior needs agreement for project filters, top pins, multiple threads claiming the same position, shorter lists, and dragging a thread whose position is fixed.

The fork prototype counts thread rows in the current project scope, gives top pins precedence, places out-of-range positions at the end, and requires releasing a fixed pin before moving it. Those are candidate behaviors for discussion, not assumptions about upstream's preferred design. Pinning would continue to allow automatic settlement.

Prototype and contribution

I have a working fork prototype. This screenshot shows the Pin here action, and this result shows a thread held in the third row. These images are from the fork before integration with the latest upstream sidebar changes.

I am opening this in Ideas first, following CONTRIBUTING.md. Would fixed-position placement fit the intended sidebar model? If useful, I can narrow the existing implementation into a focused PR that builds on the ordering support already merged upstream.

[olafura]

This gist is a demonstration of how this feature could be built or customized with the Qt/QML branch. It is an example to try and adapt, not a complete implementation of the discussion request or a feature shipped in upstream T3 Code.

Here's a local Qt-sidebar prototype of the fixed-position rule. Pin Reference at Active row 3, then add New: A, B, Reference, C becomes New, A, Reference, B, C. Release returns to ordinary ordering. This gist uses the repository's existing Rosé dashboard example, with the controls above the page.

This version counts Active rows and saves positions per project scope on this client. Top pins stay separate; settlement and snooze still work. It doesn't implement shared web/mobile ordering or drag integration.

Demonstration gist and setup.

The screenshot uses demo data.

Code and checks assisted by Codex.

[olafura]

Sorry for the lack of context this is showing how using this technique in the linked discussion would help with your issue #10708