Sticky notes widget "freezes" - caused by binding loop in ScrollView.qml?

hi all,

the widget: /usr/share/plasma/plasmoids/org.kde.plasma.notes does “freeze” regulary after the first reboot or log off and on after “installing” it.

it is still possible to copy and paste text, change the size, open the context menu, but it is not accepting keystrokes anymore, and the blend in options (bold/italic etc.) are not shown anymore.

i found the following “general” error in the journalctl, related to ScrollView.qml:

plasmashell[6317]: qrc:/qt/qml/org/kde/plasma/components/ScrollView.qml:45:27: QML ScrollBar: Binding loop detected for property "visible"

plus this specific notes error, earlier:

plasmashell[1784]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notes/contents/ui/main.qml:155:13: QML ScrollView: Binding loop detected for property "rightPadding"

this, interestingly, leads to follwing QML code in main.qml:

PlasmaComponents3.ScrollView {
                id: scrollview
                anchors {
                    top: parent.top
                    left: parent.left
                    right: parent.right
                    bottom: fontButtons.top
                    bottomMargin: Kirigami.Units.largeSpacing
                }

followed by 239 further lines.

i tried to completely remove this “scollbar” part out of the source, as expected that wasn’t working since there are other related parts, and i really love to understand and dig into things, but i’m not a real coder.

Do you think the error may be related to the ScrollView.qml loop?

my system:

Operating System: Kubuntu 24.10
KDE Plasma Version: 6.1.5
KDE Frameworks Version: 6.6.0
Qt Version: 6.6.2
Kernel Version: 6.11.0-9-generic (64-bit)
Graphics Platform: Wayland
Processors: 8 × 11th Gen Intel® Core™ i5-11300H @ 3.10GHz
Memory: 16,5 GB of RAM
Graphics Processor: Mesa Intel® Xe Graphics
Manufacturer: LENOVO
Product Name: 82NH
System Version: Yoga Slim 7 Pro 14IHU5 O

thanks you everybody and have a great day
best, me (-:

GPT analysis of the given ScrollView error & code:

assuming that the loop indicated by journalctl:

plasmashell[6317]: qrc:/qt/qml/org/kde/plasma/components/ScrollView.qml:45:27: QML ScrollBar: Binding loop detected for property “visible”

is referring to this file:

/usr/lib/x86_64-linux-gnu/qt6/qml/org/kde/plasma/components/ScrollView.qml

the relevant code would be:

    T.ScrollBar.vertical: PlasmaComponents3.ScrollBar {
        parent: controlRoot
        x: controlRoot.mirrored ? 0 : controlRoot.width - width
        y: controlRoot.topPadding
        height: controlRoot.availableHeight
        active: controlRoot.T.ScrollBar.horizontal.active
    }

    T.ScrollBar.horizontal: PlasmaComponents3.ScrollBar {
        parent: controlRoot
        x: controlRoot.leftPadding
        y: controlRoot.height - height
        width: controlRoot.availableWidth
        active: controlRoot.T.ScrollBar.vertical.active
    }

and this is what GPT recognises:

Breakdown of the Problem:

  1. Binding the active property:
  • You are binding the active property of the vertical scrollbar (T.ScrollBar.vertical) to the horizontal scrollbar’s active state (controlRoot.T.ScrollBar.horizontal.active) and vice versa. This could potentially lead to a situation where the vertical scrollbar’s active state is dependent on the horizontal scrollbar, which in turn might be dependent on the vertical scrollbar’s state.
  1. Cyclic dependency:
  • If the active state of one scrollbar triggers a change in the visibility of the other (or itself), and this change is tied to the active state of the other scrollbar, you could create a situation where the system continuously tries to resolve these values, leading to the “binding loop” error.

p.s. i tried to substitute the given logic with a GPT suggested modified code as solution, but that didn’t work, the error and log entry still persists.

edit: it seems there is no relation between the notes and the ScrollView error

although it appeared close to me, there seem to be no relation between the error analysed in the second post, and the notes freeze. i tested this on another machine (KDE neon, plsama 6.2), and although the ScrollView loop was present in the logs, notes worked without problems.

log entry:

kwin --replaceplasmashell[1318]: qrc:/qt/qml/org/kde/plasma/components/ScrollView.qml:45:27: QML ScrollBar: Binding loop detected for property "visible":

machine:

Operating System: KDE neon 6.2
KDE Plasma Version: 6.2.3
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0
Kernel Version: 6.8.0-48-generic (64-bit)
Graphics Platform: Wayland

wow, this was a hell of a ride.

after i digged deeper into building my own widget, btw. i didn’t find a real hello world tutorial for plasma 6 though, i did a substitute with a TILDA terminal, in the size of my wished sticky note and autoload nano -S /mynotes in it.

after really studying the debugging options for kde.org.plasma.notes and analysing loads of journalctls + enabled specific loggings (.config/QtProject/qtlogging.ini) , i thought to try it with a fresh .config/plasma-org.kde.plasma.desktop-appletsrc.

and here it comes:

  • the bug only occures, if the notes widget is placed on a vertical panel at the right side of the desktop!

if i set the widget to the exsiting bottom-panel, it works like a charm.

this is, i mean, i love it. for a structural thinker, loving stringent logic, this was a beautiful vacation to (from the perspectives of an amateur) VUCA lands (-:

i’ll verify this on my other machine, and then, if given, open a bug report for it.

Hey! If you do end up submitting a bug report for this (or if you already did), would you mind sharing the link here as well? Not being able to edit my sticky note properly was driving me up a wall and I think you might just’ve found out why, haha. Ultimately I think I can just ditch the right panel (I was only using it to work around a different issue, and for now it seems to have stopped happening + there’s another bug report looking into that one), but if there is a report I’d love to be able to follow it/provide additional info if it’d help the devs.

Thanks for digging into this and sharing your findings either way! Thought I was the only one having this mystery problem lol.

1 Like

hey Latibulia! thank you for your contribution. i tested the eventual bug on a install on other machine, and the problem didn’t occured on KDE neon with plasma 6.5. so i didn’t want to create any work for the devs, if i’m the only one with this problem.

i’m going to file a bug report this weekend, and share the link here.

p.s. since it seems that you’re new to this forum, not that i would be an represantative or something, but let me say:

welcome to the forum and have a good time :penguin:

1 Like

done:
https://bugs.kde.org/show_bug.cgi?id=496877

best, me (-: