Bug 417636

Summary: Title rows of QML KCMs fade in and out, but others don't
Product: [Frameworks and Libraries] frameworks-kdeclarative Reporter: Patrick Silva <bugseforuns>
Component: generalAssignee: Nate Graham <nate>
Status: RESOLVED FIXED    
Severity: normal CC: kde, kdelibs-bugs, nate, olib141, plasma-bugs, postix
Priority: NOR    
Version: 5.84.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=447739
Latest Commit: Version Fixed In: 5.90
Sentry Crash Report:
Attachments: screen recording
new screen recording
screen recording 1
screen recording 2
screen recording 3

Description Patrick Silva 2020-02-14 13:25:12 UTC
Created attachment 126012 [details]
screen recording

SUMMARY
Please watch the attached screen recording and observe the fade effect of the KCMs titles.
Such behavior is inconsistent, it does not affect all KCMs.

EXPECTED RESULT
consistency

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 5.18.0
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1
Comment 1 Nate Graham 2020-02-15 23:11:14 UTC
We should probably not fade. Moving to kdeclarative where the QML KCM stuff lives.
Comment 2 Patrick Silva 2020-05-23 19:19:33 UTC
*** Bug 421967 has been marked as a duplicate of this bug. ***
Comment 3 David Edmundson 2020-05-23 22:19:03 UTC
According to gammaray the fade seems to come from PageRowGlobalToolBarUI id. breadCrumbLoader in repo Kirigami
Comment 4 postix 2020-05-24 09:06:44 UTC
(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.
Comment 5 Patrick Silva 2021-02-22 12:29:28 UTC
In Plasma 5.21, the whole header bar of QML KCMs fades.
Comment 6 Nate Graham 2021-02-22 18:21:45 UTC
Yep.
Comment 7 Patrick Silva 2021-02-23 12:27:36 UTC
is current behavior intentional?
Comment 8 Nate Graham 2021-02-23 15:09:47 UTC
Oh no, sorry.
Comment 9 Nate Graham 2021-11-08 21:45:42 UTC
*** Bug 445042 has been marked as a duplicate of this bug. ***
Comment 10 Bug Janitor Service 2021-11-11 03:48:46 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/418
Comment 11 Nate Graham 2021-11-11 12:46:25 UTC
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
Comment 12 Oliver Beard 2021-11-12 01:48:11 UTC
Thanks Nate, this bug was a particular eyesore.
Comment 13 Nate Graham 2021-11-12 02:22:16 UTC
You're welcome!
Comment 14 Patrick Silva 2021-11-15 13:07:51 UTC
Unfortunately the bug persists on neon unstable.
Comment 15 Nate Graham 2021-11-15 14:06:55 UTC
Then Neon unstable must not have rebuilt Kirigami yet or something?

The animation should be gone. Are you still seeing a non-animated "blink"?
Comment 16 Patrick Silva 2021-11-15 15:03:39 UTC
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.
Comment 17 Nate Graham 2021-11-18 20:24:45 UTC
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.
Comment 18 Nate Graham 2021-11-18 20:26:17 UTC
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
Comment 19 Nate Graham 2021-11-18 20:27:50 UTC
I'll try again.
Comment 20 Nate Graham 2021-11-19 21:31:33 UTC
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
Comment 21 Nate Graham 2021-11-19 21:37:46 UTC
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?
Comment 22 Nate Graham 2021-11-19 21:59:32 UTC
Hmm, maybe not. Fixing that doesn't fix the issue here.
Comment 23 Bug Janitor Service 2021-11-19 22:00:36 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kcmutils/-/merge_requests/69
Comment 24 Nate Graham 2021-11-19 22:14:54 UTC
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.
Comment 25 Nate Graham 2021-11-19 22:17:44 UTC
Ohh System Settings itself is drawing the header because those KCMs are not actually registering themselves as QML KCMs. :/
Comment 26 Bug Janitor Service 2021-11-19 23:17:32 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/420
Comment 27 Nate Graham 2021-12-03 15:45:38 UTC
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
Comment 28 Nate Graham 2021-12-07 02:49:34 UTC
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
Comment 29 Patrick Silva 2021-12-20 10:36:50 UTC
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
Comment 30 Nate Graham 2021-12-20 15:59:28 UTC
Can you attach another screen recording please?
Comment 31 Patrick Silva 2021-12-20 16:37:55 UTC
Created attachment 144722 [details]
screen recording 1

I'm attaching 3 videos due to file size limit.
Comment 32 Patrick Silva 2021-12-20 16:38:24 UTC
Created attachment 144723 [details]
screen recording 2
Comment 33 Patrick Silva 2021-12-20 16:38:46 UTC
Created attachment 144724 [details]
screen recording 3
Comment 34 Nate Graham 2021-12-27 22:33:30 UTC
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?
Comment 35 Patrick Silva 2021-12-31 13:18:25 UTC
(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