Alt+N/Alt+Shift+N indexing and tab badges must be computed from Avalonia.Dock VisibleDockables, not the internal flat Tabs list

[JoshuaRowePhantom]

Summary

Alt+N / Alt+Shift+N keyboard tab indexing and the numbered tab badges are computed from our internal flat ObservableCollection projections (WorkspacePaneViewModel.Tabs for content tabs, MainWindowViewModel.WorkspacePanes for workspace tabs) instead of from the Avalonia.Dock structure (the IDock.VisibleDockables of the real visual tab strips). The internal Tabs list is a flat, single-strip projection that cannot represent split/floated strips and only stays in visual order because a fragile back-sync (SyncPaneTabsOrderFromDock) copies the Dock order into it after certain reorder events. Consulting that projection is the wrong source of truth: it diverges from the visual order under splits and under the #1065 insert-to-the-right move whenever the back-sync does not fire (e.g. the drag path emits Remove+insert, not Move).

The fix is to compute both numberings and both sets of badges directly from the Dock VisibleDockables, per visual strip and per active workspace, keeping #1043's active-workspace scoping:

• Alt+N (content tabs) → the active workspace's content DocumentDock.VisibleDockables (WorkspaceContentDock, reached via pane.ContentLayout), in visual order.
• Alt+Shift+N (workspace tabs) → the workspace-tab host dock's VisibleDockables (the root WorkspacesPaneDock, Id="WorkspacesDock"), in visual order.

A dockable is mapped back to its WorkspaceTabViewModel via WorkspaceDocument.TabViewModel (and pane dockables via GetPaneDocument) for activation and label assignment.

Maintainer directive: "Consulting the internal tabs list for Alt+N and badge labels is incorrect, and should be addressed in #1067. Rewrite #1067 correctly using Avalonia.Dock primitives."

Root Cause / Current State

All indexing/badge logic is in Phantom.Workspaces/ViewModels/MainWindowViewModel.cs.

Alt+N content-tab order is read from the internal Tabs list

OnGoToTabAtIndex resolves the target through ComputeActiveWorkspaceTabOrder():

// MainWindowViewModel.cs:1759-1761
private void OnGoToTabAtIndex(int index)
{
    var match = FindTabByAltShortcutIndex(this.ComputeActiveWorkspaceTabOrder(), index);

ComputeActiveWorkspaceTabOrder() delegates to ComputeGlobalTabOrder([pane], …), which walks pane.Tabs — the internal ObservableCollection<WorkspaceTabViewModel> — not the Dock:

// MainWindowViewModel.cs:2779-2789
private List<(WorkspacePaneViewModel Pane, WorkspaceDocument Document)> ComputeActiveWorkspaceTabOrder()
{
    var pane = this.selectedWorkspacePane;
    if (pane?.ContentLayout is null || pane.Id.StartsWith("loading-workspace:", …)) return new();
    return ComputeGlobalTabOrder([pane], this.dockFactory.GetDocumentForTab);
}

// MainWindowViewModel.cs:2754-2771
internal static List<…> ComputeGlobalTabOrder(IEnumerable<WorkspacePaneViewModel> panes, Func<string, WorkspaceDocument?> getDocumentForTab)
{
    var order = new List<…>();
    foreach (var pane in panes)
        foreach (var tab in pane.Tabs)                       // <-- internal flat list, NOT VisibleDockables
            if (getDocumentForTab(tab.Id) is WorkspaceDocument doc)
                order.Add((pane, doc));
    return order;
}

Alt+N badge labels are assigned by iterating the internal Tabs list

// MainWindowViewModel.cs:2691-2708
private void RefreshActiveWorkspaceAltShortcutLabels()
{
    foreach (var pane in this.WorkspacePanes)
        foreach (var tab in pane.Tabs)                       // <-- internal flat list
            if (this.dockFactory.GetDocumentForTab(tab.Id) is WorkspaceDocument doc)
                doc.EffectiveTabHeader.AltShortcutLabel = null;

    AssignGlobalAltShortcutLabels(this.ComputeActiveWorkspaceTabOrder());  // also Tabs-derived
}

Alt+N badge visibility iterates the internal Tabs list

// MainWindowViewModel.cs:2791-2804
private void PropagateBadgeVisibility(bool isAltHeld, bool isShiftHeld)
{
    var contentBadge = isAltHeld && !isShiftHeld;
    foreach (var pane in this.WorkspacePanes)
    {
        var isActive = ReferenceEquals(pane, this.selectedWorkspacePane);
        foreach (var tab in pane.Tabs)                       // <-- internal flat list
            if (this.dockFactory.GetDocumentForTab(tab.Id) is WorkspaceDocument doc)
                doc.EffectiveTabHeader.IsShortcutBadgeVisible = isActive && contentBadge;
    }
    // workspace-pane badges below (Alt+Shift): iterate this.WorkspacePanes …
}

Alt+Shift+N workspace-tab order is read from the internal WorkspacePanes list

// MainWindowViewModel.cs:2674-2689
internal static void RefreshWorkspacePaneAltShortcutLabels(
    IReadOnlyList<WorkspacePaneViewModel> workspacePanes,
    Func<string, WorkspacePaneDocument?> getPaneDocument)
{
    for (var i = 0; i < workspacePanes.Count; i++)           // <-- internal WorkspacePanes, NOT WorkspacesDock.VisibleDockables
        if (getPaneDocument(workspacePanes[i].Id) is { } paneDoc)
            paneDoc.EffectiveTabHeader.AltShortcutLabel = AltShortcutLabelForIndex(i);
}

// MainWindowViewModel.cs:1791-1798
private void OnGoToWorkspacePaneAtIndex(int index)
{
    if (index < 0 || index >= this.WorkspacePanes.Count) return;
    this.SelectedWorkspacePane = this.WorkspacePanes[index];  // <-- indexed off internal list
    …
}

Why the internal list is the wrong source of truth

WorkspacePaneViewModel.Tabs (WorkspacePaneViewModel.cs:88) is our own ObservableCollection<WorkspaceTabViewModel> bound as the ItemsSource of a single WorkspaceContentDock (WorkspaceDockFactory.cs:115-128). It is a flat, single-strip projection:

• It maps 1:1 to one strip only. Once a user splits/floats documents, pane.ContentLayout holds multiple DocumentDock strips, and the flat Tabs order no longer corresponds to any single visual strip's order.
• Its order only tracks the visual order because SyncPaneTabsOrderFromDock (MainWindowViewModel.cs:2626-2647) copies VisibleDockables order back into Tabs — but only when SyncPaneTabsFromDockChange (:2603-2619) decides to, i.e. only on Move/Reset:

// MainWindowViewModel.cs:2603-2619
if (e.Action == NotifyCollectionChangedAction.Remove)      { /* close/float only */ }
else if (e.Action is NotifyCollectionChangedAction.Move or NotifyCollectionChangedAction.Reset)
    SyncPaneTabsOrderFromDock(workspacePane, documentDock);
// Add + the Remove+insert that Dock.Avalonia's drag path emits are NOT re-synced.

So after a live drag-reorder (Remove+insert, not Move) or an #1065 insert-to-the-right move, RefreshActiveWorkspaceAltShortcutLabels re-reads a stale pane.Tabs and re-labels tabs in the old order — the originally reported "badge 2 retained after reordering" symptom. The Dock's VisibleDockables is always in correct visual order; the projection is not. The correct fix is to read the Dock directly and stop depending on the projection for indexing/badges.

Affected Files

File	Contribution
Phantom.Workspaces/ViewModels/MainWindowViewModel.cs	OnGoToTabAtIndex (:1759), ComputeActiveWorkspaceTabOrder/ComputeGlobalTabOrder (:2779, :2754) read pane.Tabs; RefreshActiveWorkspaceAltShortcutLabels (:2691), PropagateBadgeVisibility (:2791) iterate pane.Tabs; RefreshWorkspacePaneAltShortcutLabels (:2674) / OnGoToWorkspacePaneAtIndex (:1791) index this.WorkspacePanes; FindDocumentDock (:2816) and EnumerateAllDocuments (:2843) are the Dock-traversal building blocks; SyncPaneTabsFromDockChange/SyncPaneTabsOrderFromDock (:2603, :2626) is the back-sync that indexing/badges will no longer depend on
Phantom.Workspaces/ViewModels/WorkspaceDockFactory.cs	Root WorkspacesPaneDock (Id="WorkspacesDock", ItemsSource=WorkspacePanes, :79-107) = Alt+Shift+N host; per-pane WorkspaceContentDock (Id="WorkspaceContent_{paneId}", ItemsSource=workspacePane.Tabs, :115-141) = Alt+N scope; GetDocumentForTab (:44), GetPaneDocument (:71)
Phantom.Workspaces/ViewModels/WorkspaceContentDock.cs	The DocumentDock strip type (VisibleDockables, Owner) hosting content documents
Phantom.Workspaces/ViewModels/WorkspaceDocument.cs	WorkspaceDocument is the content IDockable; TabViewModel (:165, base.Context as WorkspaceTabViewModel) maps a dockable back to its tab VM; EffectiveTabHeader (:109) carries AltShortcutLabel/IsShortcutBadgeVisible
Phantom.Workspaces/ViewModels/WorkspacePaneDocument.cs	The workspace-tab IDockable hosted by WorkspacesPaneDock; its EffectiveTabHeader carries the Alt+Shift+N badge
Phantom.Workspaces/ViewModels/WorkspacePaneViewModel.cs	Tabs (:88) remains the content ItemsSource + membership source, but is no longer the indexing/badge source of truth

Design / Fix (Dock primitives)

Compute all four things — Alt+N order, Alt+N badges, Alt+Shift+N order, Alt+Shift+N badges — from IDock.VisibleDockables, mapping each dockable back to its VM.

1. Enumerate the active workspace's content dockables in visual order (Alt+N)

pane.ContentLayout is an IRootDock; its content strip(s) are WorkspaceContentDock : DocumentDock. Walk the tree and take WorkspaceDocuments in visual order. EnumerateAllDocuments (:2843) already recurses VisibleDockables depth-first and handles split content docks:

private List<(WorkspacePaneViewModel Pane, WorkspaceDocument Document)> ComputeActiveWorkspaceTabOrder()
{
    var pane = this.selectedWorkspacePane;
    if (pane?.ContentLayout is null || pane.Id.StartsWith("loading-workspace:", StringComparison.Ordinal))
        return new();

    // Source of truth = the Dock tree's VisibleDockables order, NOT pane.Tabs.
    return EnumerateAllDocuments(pane.ContentLayout)
        .Select(doc => (pane, doc))
        .ToList();
}

EnumerateAllDocuments yields documents in VisibleDockables order across every DocumentDock strip in the workspace, so a split layout numbers strip-by-strip in visual order. (If per-strip restart is desired later, iterate each WorkspaceContentDock.VisibleDockables separately — but for Alt+N the active workspace's documents form one numbering 1..N, consistent with #1043.)

2. Assign Alt+N badges from the same Dock-derived order

RefreshActiveWorkspaceAltShortcutLabels clears every document's label, then assigns from the Dock-derived order. Clearing should also iterate the Dock, not pane.Tabs:

private void RefreshActiveWorkspaceAltShortcutLabels()
{
    foreach (var pane in this.WorkspacePanes)
        if (pane.ContentLayout is { } layout)
            foreach (var doc in EnumerateAllDocuments(layout))
                doc.EffectiveTabHeader.AltShortcutLabel = null;

    AssignGlobalAltShortcutLabels(this.ComputeActiveWorkspaceTabOrder());  // now Dock-derived
}

3. Alt+N badge visibility from the Dock

private void PropagateBadgeVisibility(bool isAltHeld, bool isShiftHeld)
{
    var contentBadge = isAltHeld && !isShiftHeld;
    foreach (var pane in this.WorkspacePanes)
    {
        var isActive = ReferenceEquals(pane, this.selectedWorkspacePane);
        if (pane.ContentLayout is not { } layout) continue;
        foreach (var doc in EnumerateAllDocuments(layout))
            doc.EffectiveTabHeader.IsShortcutBadgeVisible = isActive && contentBadge;
    }

    // Alt+Shift+N workspace-pane badges from the workspace-tab host's VisibleDockables (see 4).
    var paneBadge = isAltHeld && isShiftHeld;
    var host = this.FindDocumentDock(this.Layout);           // the WorkspacesPaneDock
    if (host?.VisibleDockables is { } dockables)
        foreach (var paneDoc in dockables.OfType<WorkspacePaneDocument>())
            paneDoc.EffectiveTabHeader.IsShortcutBadgeVisible = paneBadge;
}

4. Alt+Shift+N order and activation from the workspace-tab host dock

The workspace-tab host is the root WorkspacesPaneDock (Id="WorkspacesDock"), reachable via FindDocumentDock(this.Layout). Its VisibleDockables are WorkspacePaneDocuments in visual order. Number and resolve off that:

private IReadOnlyList<WorkspacePaneDocument> WorkspaceTabHostOrder()
    => this.FindDocumentDock(this.Layout)?.VisibleDockables?.OfType<WorkspacePaneDocument>().ToList()
       ?? [];

private void RefreshWorkspacePaneAltShortcutLabels()
{
    var order = this.WorkspaceTabHostOrder();
    for (var i = 0; i < order.Count; i++)
        order[i].EffectiveTabHeader.AltShortcutLabel = AltShortcutLabelForIndex(i);
}

private void OnGoToWorkspacePaneAtIndex(int index)
{
    var order = this.WorkspaceTabHostOrder();
    if (index < 0 || index >= order.Count) return;
    var paneDoc = order[index];
    // map dockable -> pane VM (paneDoc.Context / registry) and activate:
    this.dockFactory.SetActiveDockable(paneDoc);
    …
}

5. Dockable → VM mapping for activation

• Content: WorkspaceDocument.TabViewModel (WorkspaceDocument.cs:165) gives the WorkspaceTabViewModel; the document itself is the dockable, so SetActiveDockable(doc) / SetFocusedDockable(dock, doc) activate it. The owning strip for focus is doc.Owner as IDock (or FindDocumentDock(pane.ContentLayout)).
• Workspace: WorkspacePaneDocument maps back to its WorkspacePaneViewModel; GetPaneDocument(paneId) remains the id→dockable registry.

Why this stays correct after the #1065 insert-to-the-right move

#1065 makes the Dock the ordering authority: a new tab is moved to sourceIndex + 1 inside the source document's DocumentDock.VisibleDockables. Because indexing/badges now read VisibleDockables directly, the numbering reflects the new visual order immediately, without waiting for SyncPaneTabsOrderFromDock to copy the order back into pane.Tabs. This also fixes the original drag-reorder symptom: the drag path's Remove+insert changes VisibleDockables, and reading it directly always yields the current visual order.

Relationship to #1043 and #1065

• Alt+N tab indices computed globally across workspaces instead of scoped to the active workspace's content dock #1043 (CLOSED, implemented) scoped Alt+N from a global cross-workspace numbering to the active workspace and kept Alt+Shift+N over the workspace-tab host. Alt+N/Alt+Shift+N indexing and tab badges must be computed from Avalonia.Dock VisibleDockables, not the internal flat Tabs list #1067 preserves that scoping but changes the source of both numberings from the internal Tabs/WorkspacePanes lists to the Dock VisibleDockables. It therefore supersedes Alt+N tab indices computed globally across workspaces instead of scoped to the active workspace's content dock #1043's implementation choice of reading pane.Tabs inside ComputeActiveWorkspaceTabOrder/ComputeGlobalTabOrder, while keeping Alt+N tab indices computed globally across workspaces instead of scoped to the active workspace's content dock #1043's behavioural contract (each workspace numbers 1..N; badges only on the active workspace; Alt+Shift+N independent).
• New tabs opened from an existing tab should insert one position to the right within the current docking strip #1065 (OPEN) establishes the Dock DocumentDock/VisibleDockables as the ordering authority for inserts. Alt+N/Alt+Shift+N indexing and tab badges must be computed from Avalonia.Dock VisibleDockables, not the internal flat Tabs list #1067 aligns indexing/badges with that same authority, removing the reliance on the Tabs back-sync so the two cannot diverge.

Considered / Background (rejected: wrong layer)

The current implementation treats WorkspacePaneViewModel.Tabs (and MainWindowViewModel.WorkspacePanes) as the ordering source of truth and keeps it aligned to the Dock with a back-sync (SyncPaneTabsOrderFromDock). Rejected per the maintainer: the internal flat list is a single-strip projection that cannot represent split/floated strips and only appears correct when the back-sync fires. Depending on it for Alt+N and badge labels is incorrect; the Dock VisibleDockables tree is the real visual structure and must be the source.

Remaining legitimate consumers of the internal Tabs list (keep — do NOT remove in this bug)

Tabs is not removed by #1067; it stays for uses unrelated to visual ordering of indexing/badges:

• ItemsSource generation — WorkspaceContentDock.ItemsSource = workspacePane.Tabs (WorkspaceDockFactory.cs:124) is what creates the WorkspaceDocument dockables via WorkspaceDocumentGenerator. Removing Tabs would remove the documents themselves.
• Membership / lookup / open / close / replace — many sites resolve or mutate tabs by id via pane.Tabs (e.g. MainWindowViewModel.cs:264, 1725, 1930, 1949, 2178, 2223-2236, 2255-2267, 2327-2340). These use Tabs for membership, which is legitimate.
• AnyTabIsRunning status aggregation — WorkspacePaneViewModel.RecomputeAnyTabIsRunning (WorkspacePaneViewModel.cs:113, 191-195) and notification aggregation iterate Tabs.
• Persistence write-back — AppendWorkspaceTabRelationshipChanges / WriteBackWorkspaceTabs (MainWindowViewModel.cs:2500) derive saved workspace-tab relationships from Tabs. (This consumes membership; if saved order must match the visual order, the existing SyncPaneTabsOrderFromDock back-sync can remain for persistence only — indexing/badges no longer depend on it.)

Scope: #1067 switches only Alt+N/Alt+Shift+N indexing and badge computation to Dock primitives. Fully retiring the Tabs projection everywhere is a larger, higher-risk refactor and is explicitly out of scope here.

Expected Tests

Match the existing style in Phantom.Workspaces.Tests/MainWindowIntegrationTests.cs (e.g. GoToTabAtIndexCommand_WithThreeTabs_ActivatesCorrectTab at :1275, badge assertions reading documentDock.VisibleDockables … EffectiveTabHeader.AltShortcutLabel around :4117). Existing tests that assert badges/indexing off pane.Tabs should be updated to assert off VisibleDockables.

Test Name	Class	What It Verifies
AltN_IndexesFromActiveWorkspaceDockVisibleDockables	MainWindowIntegrationTests	Alt+N order is computed from the active workspace's content DocumentDock.VisibleDockables (documents in visual order), not from pane.Tabs
AltShiftN_IndexesFromWorkspaceTabHostVisibleDockables	MainWindowIntegrationTests	Alt+Shift+N order is computed from the WorkspacesPaneDock.VisibleDockables (WorkspacePaneDocuments in visual order), not from this.WorkspacePanes
BadgeLabels_DeriveFromDockVisibleDockablesOrder	MainWindowIntegrationTests	Content-tab AltShortcutLabels are assigned 1..N following VisibleDockables order per strip
AltN_AfterInsertToRight_ReflectsVisualOrder	MainWindowIntegrationTests	After the #1065 insert-to-the-right move (Dock VisibleDockables reordered), Alt+N numbering and badges reflect the new visual order without depending on SyncPaneTabsOrderFromDock
AltN_AfterDragReorderViaRemoveAndInsert_ReflectsVisualOrder	MainWindowIntegrationTests	Reordering by removing a dockable from VisibleDockables and re-inserting it (the live drag path, which fires Remove+insert not Move) updates badges/indexing to the new visual order
Indexing_DoesNotConsultInternalTabsList	MainWindowIntegrationTests	When pane.Tabs order is deliberately out of sync with VisibleDockables, Alt+N resolves the tab at the visual position (proving the Dock, not Tabs, is the source of truth)
AltShortcut_AfterReorder_ActivatesDockableAtNewPosition	MainWindowIntegrationTests	Pressing Alt+N after a reorder activates the dockable now displaying badge N (badge remains the single source of truth, mapped via WorkspaceDocument.TabViewModel)
SplitWorkspace_ContentBadges_FollowVisibleDockablesAcrossStrips	MainWindowIntegrationTests	With the active workspace's content split into two DocumentDock strips, content badges number 1..N across strips in VisibleDockables order

Related

• Builds on Alt+N tab indices computed globally across workspaces instead of scoped to the active workspace's content dock #1043 (CLOSED) — active-workspace scoping; Alt+N/Alt+Shift+N indexing and tab badges must be computed from Avalonia.Dock VisibleDockables, not the internal flat Tabs list #1067 changes the source of that scoped computation to the Dock.
• Aligns with New tabs opened from an existing tab should insert one position to the right within the current docking strip #1065 (OPEN) — Dock VisibleDockables as the ordering authority for inserts.

[JoshuaRowePhantom]

Research: attached-property + behavior approach for Alt+N / Alt+Shift+N tab numbering

Maintainer question: "Should we rewrite Alt+N handling to use attached properties on Avalonia tabs to set the numbers, so we can integrate anywhere by adding a behavior that updates the header template?"

Short answer: the attached property cannot live on the dockable — it must target the header container control (DocumentTabStripItem). A pure attached-property+behavior design is feasible for display, generalizes to any tab strip, but does not remove the MainWindowViewModel logic — it relocates ordering into a behavior/service and still needs a key handler. Recommendation below is a hybrid.

---

1. How tab headers are rendered today

Headers are fully app-controlled, not the stock Dock theme. Templates/DockDataTemplates.axaml sets an explicit DocumentControl.HeaderTemplate on each of our typed docks:

• WorkspaceContentDock (Alt+N strip) — DockDataTemplates.axaml:18-26, header = <ContentControl Content="{Binding EffectiveTabHeader}" /> bound to the WorkspaceDocument dockable.
• WorkspacesPaneDock (Alt+Shift+N host) — DockDataTemplates.axaml:36-56, same pattern over WorkspacePaneDocument.
• The badge itself is the TabHeaderViewModel template — DockDataTemplates.axaml:86-110:

<Border Classes="alt-index-badge"
        Classes.alt-held="{Binding IsShortcutBadgeVisible}"
        IsVisible="{Binding AltShortcutLabel, Converter={x:Static StringConverters.IsNotNullOrEmpty}}">
    <TextBlock Text="{Binding AltShortcutLabel}" Classes="caption" />
</Border>

Badge styling: SharedStyles.axaml:1235-1250 (Border.alt-index-badge + .alt-held opacity 0→1). The label/visibility live on TabHeaderViewModel (TabHeaderViewModel.cs: AltShortcutLabel, IsShortcutBadgeVisible), which the ViewModel pushes into via RefreshActiveWorkspaceAltShortcutLabels / PropagateBadgeVisibility (MainWindowViewModel.cs:2691, 2791).

Conclusion: we already own the header template, so wiring a new binding (VM property or attached property) into it is trivial — no need to restyle/override the Dock theme.

2. Feasibility of the attached property — the KEY finding

Attached AvaloniaPropertys can only be set on an AvaloniaObject. I verified the actual base chains against the resolved 12.0.0.2 assemblies (reflection over bin/Debug/net10.0):

Type (our subclass)	Model package	Base chain (root)	AvaloniaObject?
WorkspaceDocument → Dock.Model.Mvvm.Controls.Document	Dock.Model.Mvvm	Document → DockableBase → ReactiveBase → CommunityToolkit.Mvvm.ObservableObject → System.Object	NO
WorkspacePaneDocument → Dock.Model.Mvvm.Controls.Document	Dock.Model.Mvvm	same as above	NO
WorkspaceContentDock → Dock.Model.Avalonia.Controls.DocumentDock	Dock.Model.Avalonia	DocumentDock → DockBase → DockableBase → ReactiveBase → Avalonia.StyledElement → AvaloniaObject	YES
header container Dock.Avalonia.Controls.DocumentTabStripItem	Dock.Avalonia	TabStripItem → ListBoxItem → … → AvaloniaObject	YES

This repo mixes the two Dock models: the docks are Dock.Model.Avalonia (StyledElement), but the documents (WorkspaceDocument, WorkspacePaneDocument) are Dock.Model.Mvvm — plain CommunityToolkit.Mvvm.ObservableObject, not AvaloniaObjects. (Corroborated in WorkspaceContentDock.cs, which has to shadow StyledElement.StyleKey; the documents have no such concern because they aren't StyledElements.)

Definitive answer: an attached property such as AltShortcut.Index / AltShortcut.IsVisible cannot be attached to the WorkspaceDocument / WorkspacePaneDocument dockables. It must be attached to the realized header container DocumentTabStripItem (an AvaloniaObject), or a control inside the header template. Migrating documents to Dock.Model.Avalonia to make them AvaloniaObjects would be a large, risky change (serialization, STJ shadowing, the whole factory) and is out of scope.

3. The behavior that stamps indices

Because the target is the container, the behavior must operate at the view layer on the DocumentControl / DocumentTabStrip:

• Attach via Interaction.Behaviors (Xaml.Behaviors Behavior<DocumentControl>) or an attached-property class-handler on the strip.
• On attach / VisibleDockables CollectionChanged / active-workspace switch, enumerate the strip's items in model order and stamp AltShortcut.SetIndex(container, n) on the matching realized DocumentTabStripItem.
• Map model→container with ItemsControl.ContainerFromItem / ContainerFromIndex on the DocumentTabStrip.

Virtualization / lazy realization is the core pitfall. Dock's DocumentTabStrip is an ItemsControl; containers are generated lazily and off-screen tabs may have no container at stamp time. So a naive "stamp all containers" loop misses unrealized tabs, and newly-realized tabs need re-stamping via ContainerPrepared/Attached. This is strictly harder and more timing-sensitive than the current VM approach, which writes onto the persistent TabHeaderViewModel (always present regardless of realization). Any container-targeted design must handle container recycling, ContainerPrepared, and re-stamp on scroll — real complexity for numbers that must be correct for all tabs 1–10 even when scrolled off.

4. Header-template binding

We control the header template, so binding to the container attached property is straightforward:

<!-- inside DocumentControl.HeaderTemplate -->
<Border Classes="alt-index-badge"
        IsVisible="{Binding $parent[DocumentTabStripItem].(local:AltShortcut.IsVisible)}">
    <TextBlock Text="{Binding $parent[DocumentTabStripItem].(local:AltShortcut.Index)}" />
</Border>

(TemplateBinding won't work — the badge is in a DataTemplate, not a control template — so the $parent[DocumentTabStripItem].(AltShortcut.*) form is required.) No Dock-theme override needed. For a plain TabControl the same idea binds $parent[TabItem].(AltShortcut.Index).

5. Key handling is still required — this is the crux

The attached-property+behavior story only covers display. Pressing Alt+N to activate the Nth tab still needs a handler that maps N → dockable and calls SetActiveDockable/SetFocusedDockable. Today that is MainWindow.axaml.cs:127-134 → OnGoToTabAtIndex (MainWindowViewModel.cs:1759) / OnGoToWorkspacePaneAtIndex (:1791), which resolve via ComputeActiveWorkspaceTabOrder() and SetActiveDockable(doc).

Reading indices back from the containers would force the key handler to reach into the visual tree (find the strip, read AltShortcut.Index off each DocumentTabStripItem, map container→dockable) — messier and container-realization-dependent than #1067's plan of recomputing from VisibleDockables. So the key handler wants model order, not container attached props, as its source. That means the ordering computation stays in the VM/a service regardless.

Net: the attached-property approach does not genuinely decouple from MainWindowViewModel — it relocates the display plumbing into a behavior but leaves (and arguably complicates) the activation logic, which still needs the model-order computation #1067 already specifies.

6. #1043 two-scope requirement & generality

#1043 (CLOSED) requires two independent numberings: Alt+N over the active workspace's content DocumentDock(s), Alt+Shift+N over the workspace-tab host WorkspacesPaneDock. A single generic "number every tab strip 1..N" behavior can't express this without config: it must know (a) which strip is the active-workspace content scope (skip inactive workspaces' strips, restart-vs-continue across split strips), and (b) that the host strip is a separate numbering space. So a behavior would need scope parameters (e.g. AltShortcut.Scope="Content|WorkspaceHost" + "active-only") — at which point it is no longer a pure drop-in; the scoping intelligence that lives in the VM today must move somewhere stateful that knows about active workspace.

Pros / cons vs. #1067's VM-computed design

Dimension	Attached-prop + behavior	VM-computed (#1067)	Hybrid (recommended)
Can target the dockable?	No — must target DocumentTabStripItem	N/A (writes TabHeaderViewModel)	Service computes order; VM writes TabHeaderViewModel
Reusable across any strip / plain TabControl	Yes (display only)	No (bespoke to our docks)	Partial (display projector could be generic)
Separation of concerns	Good for display	Ordering+display coupled in VM	Ordering in a service, display thin
Testability	Worse — needs a rendered visual tree + realized containers	Better — pure VM method over VisibleDockables, matches existing MainWindowIntegrationTests	Best — order logic unit-testable in the service
Virtualization / realization	Fragile — off-screen tabs unrealized; needs re-stamp on ContainerPrepared/scroll	Immune — writes persistent VM, no container dependency	Immune (VM side)
#1043 two-scope	Needs per-strip scope config	Naturally expressed (two computations)	Naturally expressed in the service
Key handler (activation)	Still needed; reading back from containers is worse	Recomputes from VisibleDockables (clean)	Recomputes from the same service
Decouples from MainWindowViewModel?	No — relocates display, complicates activation	Keeps it, but small & clear	Extracts ordering to a service (real decoupling)

Recommendation

Do NOT adopt the pure attached-property+behavior approach; proceed with #1067's VM/Dock-VisibleDockables computation, optionally in a hybrid form. Reasons:

1. Blocking fact: the dockables are Dock.Model.Mvvm ObservableObjects, not AvaloniaObjects, so attached props can't live on them — they'd target realized DocumentTabStripItem containers, dragging in virtualization/realization fragility for numbers that must be correct even for scrolled-off tabs 1–10.
2. It doesn't decouple from MainWindowViewModel; it moves display into a behavior while leaving activation needing model-order anyway.
3. It's harder to test than Alt+N/Alt+Shift+N indexing and tab badges must be computed from Avalonia.Dock VisibleDockables, not the internal flat Tabs list #1067's VM method, which already has an integration-test pattern reading VisibleDockables … EffectiveTabHeader.AltShortcutLabel.

If reusability across strips is genuinely desired later, the hybrid is the right shape: a small TabShortcutService computes per-strip ordering from IDock.VisibleDockables (exactly #1067's EnumerateAllDocuments / WorkspaceTabHostOrder, with #1043 scoping), and a thin projector writes the resulting index/visibility onto the existing persistent TabHeaderViewModel (no container attached props, no virtualization risk). The key handler reads order from the same service. This keeps the source of truth on the Dock (per #1067/#1065), preserves testability, and — if a truly generic drop-in is wanted for a plain TabControl elsewhere — the display projection can be a behavior while the ordering stays in the service. The attached-property-on-container mechanism should be reserved for a hypothetical generic control that has no per-item VM to write to; our headers already have one (TabHeaderViewModel), so it adds cost without benefit here.

---

Base chains verified by reflection over the resolved Dock.Model.Mvvm / Dock.Model.Avalonia / Dock.Avalonia 12.0.0.2 assemblies. No product code was modified.

[JoshuaRowePhantom]

Verification result

Status: ❌ 7 issue(s) found

Commits checked: 0c8ee5d5 (Fix #1067) on batch/gui1 (branched off features 80bce408)

What is correct

The content-tab (Alt+N) drag-reorder path is fixed well. SyncPaneTabsFromDockChange now re-derives visual order via the idempotent, membership-safe SyncPaneTabsOrderFromDock for every structural change (Add/Remove/Move/Replace/Reset) — correctly handling the Remove+Add pair Dock.Avalonia emits for a live drag instead of a Move. A suppressDockOrderSync reentrancy guard (RunSuppressingDockOrderSync) protects programmatic mid-list inserts (open-new-window / duplicate-tab) from being clobbered by the append-to-end behavior noted in #1065. Two tests cover this: AltN_AfterDragReorderViaRemoveAndInsert_ReflectsVisualOrder and AltN_AfterInsertToRight_ReflectsVisualOrder.

Outstanding gaps

1. Workspace-tab (Alt+Shift+N) reorder is NOT implemented (feature gap). The issue explicitly covers both content tabs (WorkspacePaneViewModel.Tabs) and workspace tabs (MainWindowViewModel.WorkspacePanes / WorkspacesPaneDock). The workspace-dock handler OnWorkspacesDockCollectionChanged still only handles Remove (workspace close) — it does not re-sync WorkspacePanes order on a drag-reorder, so Alt+Shift+N badges remain stale after reordering workspace panes: the exact bug, unfixed for that strip. No equivalent of SyncPaneTabsOrderFromDock exists for WorkspacePanes.

2–7. Six of the eight named Expected Tests are absent (only 2 were added):

• AltN_IndexesFromActiveWorkspaceDockVisibleDockables — missing
• AltShiftN_IndexesFromWorkspaceTabHostVisibleDockables — missing (and untestable until gap Bump actions/checkout from 4 to 7 #1 is fixed)
• BadgeLabels_DeriveFromDockVisibleDockablesOrder — missing
• Indexing_DoesNotConsultInternalTabsList — missing (asserts the Dock, not Tabs, is source of truth when the two disagree — directly probes the Option A approach and should be present)
• AltShortcut_AfterReorder_ActivatesDockableAtNewPosition — missing
• SplitWorkspace_ContentBadges_FollowVisibleDockablesAcrossStrips — missing (multi-strip badge numbering)

The chosen "Option A" (keep badges reading pane.Tabs but sync Tabs order from the Dock) is a reasonable strategy, but it does not excuse the missing workspace-pane path or the missing coverage — in particular the split-workspace and Tabs-out-of-sync cases are behaviorally distinct branches left untested.

Tests

Fast suite (whole repo, from worktrees/9): Executed 4109 / Passed 4109 / Failed 0. The two added tests pass, but the workspace-tab reorder behavior is unimplemented and 6 named tests are missing. Not labeled verified-locally. Diff touches only MainWindowViewModel/tests (no filesystem/Git layer) — slow tests not required.

[JoshuaRowePhantom]

Verification result

Status: ✅ Verified

Commits checked (this issue): 0c8ee5d5 (content-tab Alt+N fix) + 4fecc1eb (re-fix: Alt+Shift+N workspace-tab path + missing coverage) on batch/gui1 (branched off features 80bce408).

Prior gaps — all closed

The earlier verification (7 issues) flagged (1) the unimplemented workspace-tab (Alt+Shift+N) reorder path, and (2–7) six missing Expected Tests. 4fecc1eb closes all:

Feature gap #1 — workspace-tab reorder now implemented. OnWorkspacesDockCollectionChanged no longer only handles Remove; it now re-derives WorkspacePanes order from the workspace-tab host dock's VisibleDockables on every structural change (Add/Remove/Move/Replace/Reset), via the new membership-safe, idempotent SyncWorkspacePanesOrderFromDock (index-based Moves, reorders only panes present in both collections, then RefreshWorkspacePaneAltShortcutLabels). A suppressWorkspaceDockOrderSync reentrancy guard (RunSuppressingWorkspaceDockOrderSync) prevents recursion. Pane closes are routed exclusively through WorkspaceDockFactory.OnDockableClosed -> OnWorkspacePaneDockableClosed (idempotent RemoveWorkspacePaneAsync), so a reorder Remove+Add pair is never mistaken for a close. Mirrors the content-tab Option A approach.

Test gaps #2–7 — all six named tests added (real PhantomAvaloniaFact behavioral tests that mutate VisibleDockables and assert badges/indexing follow visual order):

• AltN_IndexesFromActiveWorkspaceDockVisibleDockables
• AltShiftN_IndexesFromWorkspaceTabHostVisibleDockables (exercises the newly-implemented workspace-pane path; asserts WorkspacePanes re-derived + Alt+Shift+N selects the pane at each visual position)
• BadgeLabels_DeriveFromDockVisibleDockablesOrder
• Indexing_DoesNotConsultInternalTabsList (Dock is source of truth when pane.Tabs disagrees)
• AltShortcut_AfterReorder_ActivatesDockableAtNewPosition
• SplitWorkspace_ContentBadges_FollowVisibleDockablesAcrossStrips (multi-strip: active strip numbered 1..N in VisibleDockables order, non-active strip unnumbered)

The two original tests (AltN_AfterDragReorderViaRemoveAndInsert_ReflectsVisualOrder, AltN_AfterInsertToRight_ReflectsVisualOrder) remain present, so all 8 Expected Tests exist.

Outstanding gaps

None — all criteria satisfied.

Tests

Fast suite (whole repo, from worktrees/9): Executed 4124 / Passed 4124 / Failed 0. Diff touches only MainWindowViewModel/WorkspaceDockFactory/tests (no filesystem/Git layer) — slow tests not required.

[JoshuaRowePhantom]

Checked in

Commit: 4fecc1e
Branch fast-forwarded: features -> 4fecc1e

Batch batch/gui1 landed on features (fast suite 4124/4124 green; new GUI tests stable 5/5).