| Summary: | SwipeListItem places existing action buttons in the wrong place on desktop | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kirigami | Reporter: | cwo <cwo.kde> |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | efeciftci, nate, newton, notmart, thantzarni83 |
| Priority: | NOR | ||
| Version First Reported In: | Master | ||
| Target Milestone: | Not decided | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/frameworks/kirigami/-/commit/12202392ddc087ee7703da8ca844038875798008 | Version Fixed/Implemented In: | 6.15 |
| Sentry Crash Report: | |||
| Attachments: | a screenshot showing three different icon positions for SwipeListItem | ||
|
Description
cwo
2025-01-03 22:06:11 UTC
Can reproduce in the KDE Connect app with those steps. Very strange indeed. The two instances that cause the problem (I think there was a third one reported on Matrix, but I forgot what exactly and it might be proted to something else by now) all override the contentItem. This seems to be the issue After some debugging with debug statements, the first entry seems to think its availableWidth (at least initially) is 0 and so places the icon right at the beginning. The other ones don't. but are also slightly wrong. After some more debugging with Gammaray, it seems like the anchors for the Item that the action buttons are parented to (a loader with nothing loaded) are still using the default contentItem's anchors. Apparently they're assigned just long enough to get the Loader's anchors set to them, then they are replaced by the contentItem: binding in the SLI, and the complicated anchor assignment somehow make it so they aren't updated when that happens. The now-unused default contentItems don't have their size set correctly, but remain at whatever they happened to be as things got set up. So the buttons end up anchored to ghosts of something that has already left the scene. I have no idea how to fix this. We could just anchor them to something else (like the SLI itself) and that works in my quick testing if you jiggle some other things around, but the code is full of "Here Be Dragons" warnings to not mess with paddings etc. – it does a lot of things and I could easily see that breaking other use cases. *** Bug 503542 has been marked as a duplicate of this bug. *** A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/1809 I believe this bug is now fixed. However, I’ve only tested the fix on my desktop PC. Additional testing in tablet mode is recommended before considering this bug resolved. Should https://invent.kde.org/frameworks/kirigami/-/commit/fa73f2a040e5c6e22985b0c2a16849ad800cde5b have fixed it? Git commit 12202392ddc087ee7703da8ca844038875798008 by Nate Graham, on behalf of Efe Çiftci. Committed on 03/06/2025 at 17:59. Pushed by ngraham into branch 'master'. SwipeListItem: Fix action button positions The `SwipeListItem` was assigning anchors to the `Loader` before the `Loader` had completed, causing those anchors to become invalid once the actual `contentItem` was loaded. This commit resolves this issue by making anchor assignment time-deterministic using States. FIXED-IN: 6.15 M +17 -7 src/controls/SwipeListItem.qml https://invent.kde.org/frameworks/kirigami/-/commit/12202392ddc087ee7703da8ca844038875798008 |