System information
- Version: v0.26.3 (1f6de85)
- Build info: GCC 16.2.1 - Release - LTO
- Provenance: binary_release
- OS: Arch Linux -
- QT Platform: wayland
- DE: Hyprland/Wayland
Describe the bug
List.Item.Detail.Metadata.TagList lays its tags out vertically - one chip per row -
the first time a detail pane is painted. As soon as the selection moves to another list
item, the tags re-flow horizontally as intended, and they stay correct from then on,
including when returning to the item that was wrong.
Only tag lists are affected; label and link rows in the same metadata bar look right
immediately.
To Reproduce
Minimal command:
import { Color, List } from "@vicinae/api";
const items = [
{ id: "1", title: "First", tags: ["alpha", "beta", "gamma"] },
{ id: "2", title: "Second", tags: ["delta", "epsilon", "zeta"] },
];
export default function Repro() {
return (
<List isShowingDetail>
{items.map((item) => (
<List.Item
key={item.id}
title={item.title}
detail={
<List.Item.Detail
markdown={`# ${item.title}`}
metadata={
<List.Item.Detail.Metadata>
<List.Item.Detail.Metadata.TagList title="Tags">
{item.tags.map((tag) => (
<List.Item.Detail.Metadata.TagList.Item
key={tag}
text={tag}
color={Color.SecondaryText}
/>
))}
</List.Item.Detail.Metadata.TagList>
</List.Item.Detail.Metadata>
}
/>
}
/>
))}
</List>
);
}
- Run the command.
- Look at the detail pane of the first item - the three tags are stacked one per line.
- Press Down to select the second item - its tags flow horizontally.
- Press Up to go back - the first item's tags are now horizontal too.
Expected behavior
Tags flow horizontally from the first paint, the way they do after any selection change.
Additional context
This looks like a first-layout-pass problem in
src/server/src/qml/qml/MetadataBar.qml:149 - identical on v0.26.3 and on main:
Flow {
Layout.maximumWidth: root.width * 0.65
Layout.alignment: Qt.AlignRight
spacing: 4
Repeater {
model: entry.tags || []
...
}
}
root is the outer Item of MetadataBar.qml; it never receives an explicit width and
is sized by its parent. On the first paint of a freshly created metadata bar root.width
is still 0, so Layout.maximumWidth evaluates to 0, the Flow has no horizontal room
and every chip wraps onto its own line. The next full layout pass - which a selection
change triggers - sees a real width and packs the chips normally.
The same root.width * 0.65 expression is used for label rows (line 92) and link rows
(line 119), but those contain plain Text inside a RowLayout, where a zero maximum only
affects wrapping/elision and is hard to notice. The Flow used for tags is the only place
where the wrong constraint changes the layout structure, which is why tags are the
visible symptom.
I have not tested a patch, so I don't want to assert the right fix - but it presumably
comes down to either giving the Flow a width that does not depend on root.width being
resolved at creation time, or re-triggering the layout once root.width becomes non-zero.
System information
Describe the bug
List.Item.Detail.Metadata.TagListlays its tags out vertically - one chip per row -the first time a detail pane is painted. As soon as the selection moves to another list
item, the tags re-flow horizontally as intended, and they stay correct from then on,
including when returning to the item that was wrong.
Only tag lists are affected; label and link rows in the same metadata bar look right
immediately.
To Reproduce
Minimal command:
Expected behavior
Tags flow horizontally from the first paint, the way they do after any selection change.
Additional context
This looks like a first-layout-pass problem in
src/server/src/qml/qml/MetadataBar.qml:149- identical onv0.26.3and onmain:rootis the outerItemofMetadataBar.qml; it never receives an explicit width andis sized by its parent. On the first paint of a freshly created metadata bar
root.widthis still
0, soLayout.maximumWidthevaluates to0, theFlowhas no horizontal roomand every chip wraps onto its own line. The next full layout pass - which a selection
change triggers - sees a real width and packs the chips normally.
The same
root.width * 0.65expression is used for label rows (line 92) and link rows(line 119), but those contain plain
Textinside aRowLayout, where a zero maximum onlyaffects wrapping/elision and is hard to notice. The
Flowused for tags is the only placewhere the wrong constraint changes the layout structure, which is why tags are the
visible symptom.
I have not tested a patch, so I don't want to assert the right fix - but it presumably
comes down to either giving the
Flowa width that does not depend onroot.widthbeingresolved at creation time, or re-triggering the layout once
root.widthbecomes non-zero.