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
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