👋 First, thanks for dockview. We use it as the layout engine for an internal monitoring app, with a central content area surrounded by dockable side/bottom panels.

As we built on it, we kept needing a "central area fills, side/bottom panels keep their size" layout. The existing priorities all redistribute proportionally, so we ended up customizing our fork to add a Fill priority — and it's been solid in production. We'd rather contribute it back than maintain it privately. Below is the idea + our implementation; very open on the design.

Summary

Add a LayoutPriority.Fill so a designated view absorbs all remaining space while its siblings keep their fixed sizes across resize / add / remove. Today the only priorities are Low / High / Normal, which all participate in proportional redistribution, so there's no clean way to model the common "main area fills, side panels stay put" layout.

Motivation

IDE-style layouts usually want: a central editor/content area that takes whatever space is left, and side/bottom panels that don't change size when:

• the user resizes a different panel,
• a panel is added or removed,
• the window resizes.

With proportional priorities, any of those operations rescales every view. Consumers end up fighting this with manual setSize calls on every layout change (fragile). A first-class Fill priority solves it declaratively.

Note for reviewers: this is the behaviour visible in the drop-compass demo (#1377 ) — side panels stay fixed while the content fills. It is intended (this feature), not a bug.

Proposed behaviour

• A view with LayoutPriority.Fill receives all surplus/deficit space; siblings are held at their current size.
• Existing Low/High/Normal behaviour is unchanged when no Fill view is present (backward compatible).
• Works through resize, add, remove, and serialization round-trips.

Proposed API (open to discussion)

• Extend the existing enum: LayoutPriority.Fill = 'fill'.
• Set it where priority is already set (e.g. addPanel({ ...priority }) and/or a runtime setter on the group/view).

Implementation status

I have a working implementation in a v7-based fork. It touches the layout core:

• splitview — Fill branch in distribute / layout / relayout / saveProportions / resize (+ an addView guard for _size > 0).
• gridview BranchNode — Fill propagates up the tree (highest precedence).
• gridviewPanel — priority setter.

Because it changes core layout math, I'd like to align on design before a PR:

1. Is Fill something you'd want in core, or solved differently (e.g. constraints)?
2. API surface — extend LayoutPriority, or a separate flag?
3. Expected interaction when multiple Fill views exist (current impl: split surplus among them).
4. Serialization expectations.

Happy to open a PR or split it into smaller steps once the direction is agreed.