Bug 417636

We should probably not fade. Moving to kdeclarative where the QML KCM stuff lives.

*** Bug 421967 has been marked as a duplicate of this bug. ***

According to gammaray the fade seems to come from PageRowGlobalToolBarUI id. breadCrumbLoader in repo Kirigami

(In reply to Nate Graham from comment #1)
> We should probably not fade. Moving to kdeclarative where the QML KCM stuff
> lives.

The fade feels like more like a lag due to inefficient performance to me. Thus, I'm in favor not to fade.

In Plasma 5.21, the whole header bar of QML KCMs fades.

Yep.

is current behavior intentional?

Oh no, sorry.

*** Bug 445042 has been marked as a duplicate of this bug. ***

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/418

Git commit 67ec2a1873e3d750529043b243043cfd2e2f9ec6 by Nate Graham.
Committed on 11/11/2021 at 03:44.
Pushed by ngraham into branch 'master'.

PageRowGlobalToolBarUI: don't animate opacity

Doing so causes flickering in System Settings and KInfoCenter because of
how the titles are rendered. It also doesn't make conceptual sense since
the style of toolbar generally doesn't change so the user would never
actually see the animated opacity change in the first place.
FIXED-IN: 5.89

M  +3    -10   src/controls/private/globaltoolbar/PageRowGlobalToolBarUI.qml

https://invent.kde.org/frameworks/kirigami/commit/67ec2a1873e3d750529043b243043cfd2e2f9ec6

Thanks Nate, this bug was a particular eyesore.

You're welcome!

Unfortunately the bug persists on neon unstable.

Then Neon unstable must not have rebuilt Kirigami yet or something?

The animation should be gone. Are you still seeing a non-animated "blink"?

Created attachment 143583 [details]
new screen recording

I have just rebuilt kirigami. As we can see in the screen recording attached to this comment, the KCMs titles have fade effect yet.

That's not a fade effect; as you can see from your video, there is no more fading. The title does start out invisible and then becomes visible, though. That's a separate bug. Probably the root cause, in fact. I will probably end up reverting the fix in favor of trying to figure out what's causing that.

Git commit cd3d4bd8c29b5dac266f496484d28352ea0364db by Nate Graham.
Committed on 18/11/2021 at 20:25.
Pushed by ngraham into branch 'master'.

Revert "PageRowGlobalToolBarUI: don't animate opacity"

This reverts commit 67ec2a1873e3d750529043b243043cfd2e2f9ec6.

This fix caused regressions and did not fix the root cause of the issue
described in 417636, only masking it instead. A better fix must be
found.

M  +10   -3    src/controls/private/globaltoolbar/PageRowGlobalToolBarUI.qml

https://invent.kde.org/frameworks/kirigami/commit/cd3d4bd8c29b5dac266f496484d28352ea0364db

I'll try again.

The answer to the question of why the header isn't visible by default and then becomes visible later is probably somewhere in kcmutils:src/kcmoduleqml.cpp

Appears to be caused by

        QMetaObject::invokeMethod(d->pageRow,
                                  "push",
                                  Qt::DirectConnection,
                                  Q_ARG(QVariant, QVariant::fromValue(d->configModule->mainUi())),
                                  Q_ARG(QVariant, QVariant()));

So I guess the problem is that we're always pushing the first page explicitly, rather than initializing the component with its initial page?

Hmm, maybe not. Fixing that doesn't fix the issue here.

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kcmutils/-/merge_requests/69

Next area of investigation: figure out why the Mouse and Touchpad QML KCMs don't suffer from the problem, but all other QML KCMs do.

Ohh System Settings itself is drawing the header because those KCMs are not actually registering themselves as QML KCMs. :/

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/420

Git commit b9ad2b347df0b6712628cc7df554e0664ba04484 by Nate Graham.
Committed on 03/12/2021 at 15:27.
Pushed by ngraham into branch 'master'.

Set initial page using initialPage property, rather than pushing

Found while investigating 417636. Not the cause of that issue, but it
seems more semantically correct to set the initial page using the
initialPage property (which exists for just that purpose) rather than
pushing it onto the stack.

M  +1    -5    src/kcmoduleqml.cpp

https://invent.kde.org/frameworks/kcmutils/commit/b9ad2b347df0b6712628cc7df554e0664ba04484

Git commit 3f1967bc7b9f21b6cb5c7423376fe3cf79ad5fbd by Nate Graham.
Committed on 07/12/2021 at 02:48.
Pushed by ngraham into branch 'master'.

PageRowGlobalToolBarUI: don't animate opacity, take two

This work was originally attempted in
67ec2a1873e3d750529043b243043cfd2e2f9ec6 but that had to be reverted as
it caused regressions. This commit atteampts the same fix, but without
any regressions, and based on a better understanding of the problem and
how this fixes it. Details below:

The problem here is that the breadcrumbs view is in a loader that's not
active by default; when the pagerow header style is breadcrumbs, it will
get loaded a few milliseconds after the rest of the page loads. This
causes a brief, barely noticeable but nonetheless noticeable flicker.
The existing code attempts to hide this by animating the opacity.
However this does not work because only the breadcrumbs content is
animated; the background is not. So the breadcrumbs and background have
two different transitions, which looks weird. Even if this were fixed,
there is a bigger conceptual problem: having the background transition
along with the content would make the entire header seem to appear and
disappear.

So the best transition in this case is no transition and an instant
appearance and disappearance. Due to the use of a loader, this cannot be
guaranteed and so there will always be a very brief flicker. This does
not seem fixable without fundamental refactoring of how page headers
work in Kirigami.

Accordingly, this commit simple removes all animated transitions and has
the content appear instantly as soon as the loader is finished loading.
FIXED-IN: 5.90

M  +1    -11   src/controls/private/globaltoolbar/PageRowGlobalToolBarUI.qml

https://invent.kde.org/frameworks/kirigami/commit/3f1967bc7b9f21b6cb5c7423376fe3cf79ad5fbd

The titles of the following KCMs have fade effect on neon unstable yet:

Shortcuts
File Search
Accessibility
Window Rules
SDDM
Firewall
Almost all KCMs under Startup and Shutdown
Almost all KCMs under Appearance

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.23.80
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.3
Graphics Platform: Wayland

Can you attach another screen recording please?

Created attachment 144722 [details]
screen recording 1

I'm attaching 3 videos due to file size limit.

Created attachment 144723 [details]
screen recording 2

Created attachment 144724 [details]
screen recording 3

That's not a fade, it's a flicker. And it's another issue which will need a separate solution--unfortunately a much more involved one that will likely require rewriting Kirigami's header handling code which is quite messy right now, and makes a proper fix nearly impossible.

Can you open a new bug report for that?

(In reply to Nate Graham from comment #34)
> That's not a fade, it's a flicker. And it's another issue which will need a
> separate solution--unfortunately a much more involved one that will likely
> require rewriting Kirigami's header handling code which is quite messy right
> now, and makes a proper fix nearly impossible.
> 
> Can you open a new bug report for that?

Done. Reported as bug 447739