This change broke Kirigami on mobile for me :/

Original bug was reported here: network/neochat!371 (comment 339639) and bisecting ended up in this commit

urgh

Reverted the change in cd3d4bd8.

Further investigation revealed that this was not the right fix anyway; what I need to do is figure out why the titles start out invisible in the first place, rather than removing the animated opacity transition.

This conversation (or rather a monologue) might help:

https://t.me/c/1385473057/210002

The link opens in the web client for me and doesn't go anywhere. :/ Any chance you can paraphrase or paste it in here?

@ngraham That's probably because you are only in the "KDE Chat 🍁🍂🎃" from Matrix side. Try joining from the Telegram. The group is not public (as in "doesn't have a short link), so I can't reliably link it here for everybody :(

The idea was to manipulate the visible property directly, but add a Behavior onto it, and with a help of PropertyAction make a fade in / fade out animations both ways. Note the usage of behavior.targetValue in the code below.

The problem turned out to be deeper; it's not really an issue per se that there's an animated transition here, but rather the problem is that in System Settings, the title row doesn't begin life visible. It starts out invisible, then immediately becomes visible, thus triggering the animation. If it started out life visible as expected, then there would be no issue.

Do you mean, like, the behavior (and thus animations) should only be enabled after the component is completely initialized?

That could be one fix, yeah. Figuring out why the particular instance of it in System Settings begins live invisible and then immediately becomes visible would be another, since this doesn't seem to happen in other apps that I looked into.

After some investigation, I have concluded that the root cause issue is unfixable without a fundamentally different architecture for how page headers work in Kirigami. :( Here is a better workaround that shouldn't cause regressions, at least: !420 (merged).

After some investigation, I have concluded that the root cause issue is unfixable without a fundamentally different architecture for how page headers work in Kirigami. :( Here is a better workaround that shouldn't cause regressions, at least: !420 (merged).