Created attachment 177086 [details] a screenshot showing three different icon positions for SwipeListItem SUMMARY SwipeListItems that have a visible button can have this button in the wrong place, including over the text. This does not seem to happen for freshly created items, only pre-existing ones. I'm going to give demonstrations steps for kdeconnect-app, but a user on reddit posted a screenshot (https://www.reddit.com/media?url=https%3A%2F%2Fpreview.redd.it%2Fqyv4keij51ae1.png%3Fwidth%3D1366%26format%3Dpng%26auto%3Dwebp%26s%3D342539faca0b844e108393af35fe7c584c5f7a7f) that shows a similar issue in Elisa, which I have also reproduced. Both use SwipeListItem in the respective ListViews. STEPS TO REPRODUCE 1. Open kdeconnect-app, click a device in the sidebar, press the Plugin Settings toolbar button, press the settings button on the Run Command plugin entry 2. Press Add Command…, add one of the sample commands, then repeat with a different sample command. Note the appropriate button placement. 3. Close kdeconnect-app, repeat step 1. Add a third sample entry for comparison. OBSERVED RESULT See the attached screenshot: the first entry has the Delete button at the left edge, overlapping the text, the second (pre-existing) entry has the button too far to the left (but only a bit), and only the third freshly-created one has it in the correct place. EXPECTED RESULT All buttons are in the same position within the SwipeListItem, and ideally the one currently used by newly created items. SOFTWARE/OS VERSIONS Operating System: TUXEDO OS KDE Plasma Version: 6.2.80 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.1 Kirigami and KDE Connect built today from master. The poster on reddit says this happens on (stock) Fedora as well, not sure about which version. ADDITIONAL INFORMATION The first button is always moved to the left edge. There seem to be minor differences between the cases of kdeconnect-app and Elisa; in the case of Elisa, the button on the second entry is a bit too far to the right (and extends beyond the ListView) rather than a bit too far left; adding a fresh entry seems to reset them all to the correct position (but does not do so for KDE Connect).
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. ***