Bug 481113

I have deleted my /home directory to see what happens when i start fresh. But the same error exist, so that i can't pin an App permanently to the window bar.

I then restored my backup and now i have the former apps back pinned, but like i said i can't remove or add an app.

In the Logs there is nothing about it.

What do you have on your window bar? Is it the Icons-Only task manager, or something else? Does this also happen when you create a new panel and add the icons-only task manager?

I use a standard control panel on the desktop, when i create a new standard control panel at the top and pin apps there they vanish after a restart and it's only the standard firefox icon there.

I have two screens, each with a standard control panel, and on both these error persist.

The old pinned apps from plasma5 are shown but i can't add new apps or remove apps.

The same error was with plasma6 5.0.92 (Beta 2) a few weeks ago, then i changed back to plasma5 and wanted to try RC2 5.0.93, but the same error persist.

Sounds like the changes aren't being saved when Plasmashell quits. I had this issue months ago, but it got fixed a while ago and now it's all working fine for me.

I have upgraded to 
KDE Plasma Version: 6.0.0
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2

The Problem is still there, the pinned or unpinned apps aren't saved during restart from plasma (wayland).

I created a new control panel, this has the same error.
I had created a new clean user, and there the problem exists, too.

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

I upgraded to:
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.1
Qt Version: 6.6.2

but the problem still exist.

(In reply to ollilein from comment #7)
> I upgraded to:
> KDE Plasma Version: 6.0.1
> KDE Frameworks Version: 6.0.1
> Qt Version: 6.6.2
> 
> but the problem still exist.

Same here.

Has anybody hit this on non-Gentoo yet? I haven't started looking at this yet, but it's an important factor if everyone hitting it is on Gentoo.

Folks able to reproduce this issue, are you by any chance *not* using the systemd boot feature?

(In reply to Nate Graham from comment #10)
> Folks able to reproduce this issue, are you by any chance *not* using the
> systemd boot feature?

I am on Artix OpenRC.

(In reply to Sam James from comment #9)
> Has anybody hit this on non-Gentoo yet? I haven't started looking at this
> yet, but it's an important factor if everyone hitting it is on Gentoo.

I experienced the bug on Alpine.

(In reply to Nate Graham from comment #10)
> Folks able to reproduce this issue, are you by any chance *not* using the
> systemd boot feature?

Not using systemd boot here when experiencing the issue due to the installs being openrc systems (both Alpine and Gentoo).

I'm seeing this on Arch Linux with Plasma 6.0.1 and I'm using systemd boot.

(In reply to Nate Graham from comment #10)
> Folks able to reproduce this issue, are you by any chance *not* using the
> systemd boot feature?

I am on Gentoo and use systemd as my init system, for boot i use grub and not systemd-boot.

(In reply to ollilein from comment #7)
> I upgraded to:
> KDE Plasma Version: 6.0.1
> KDE Frameworks Version: 6.0.1
> Qt Version: 6.6.2
> 
> but the problem still exist.

I made an error whith the version of KDE Frameworks, actually i use version 6.0.0 not 6.0.1.

I updated Plasma today to 6.0.2 and the bug still persist.

KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2

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

Since the other issue has been pointed over to this one, just wanted to add that this is NOT a Gentoo-specific issue. Seems to appear on most (if not all) non-systemd distros.

Created attachment 167128 [details]
plasmashell.log

Here's a plasmashell log of me starting a wayland session from tty.

(In reply to yamagi from comment #13)
> I'm seeing this on Arch Linux with Plasma 6.0.1 and I'm using systemd boot.
Just for clarification, which one did you mean:

1) Speaking of the bootloader: https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/
2) Or Plasma systemd startup: https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/

Created attachment 167168 [details]
dbus-run-session startplasma-wayland output

Throwing in my log for safe measure as well.

I made a whole new clean gentoo install on with bootloader grub and init system openrc.
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2

Still the bug persist on this new install.

(In reply to ollilein from comment #22)
> I made a whole new clean gentoo install on with bootloader grub and init system openrc.
Please note that this is *not in any way* related to your choice of bootloader. :)

If the systemd boot feature is the .desktop files copypasted into /etc/xdg/autostart, then I'm using that, otherwise, don't know what that implies or entails.

Just to help others, running X11, you can perform all your UI customization's and then logout and use wayland afterwards.
In an X11 session, everything appears to function as expected.

(In reply to Mike Pagano from comment #25)
> Just to help others, running X11, you can perform all your UI
> customization's and then logout and use wayland afterwards.
> In an X11 session, everything appears to function as expected.

I can confirm this, when i start a X11 session and pin or unpin apps then it get saved and the newly pinned/unpinned apps are available in the wayland session.

I updated to
KDE Plasma Version: 6.0.3
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.3

and the bug still exist.

I updated to
KDE Plasma Version: 6.0.3
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0

and the bug still exist.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/libplasma/-/merge_requests/1100

Git commit c37a224bc7a33c6bd5ba7c546fec74880ad463b4 by David Edmundson.
Committed on 17/04/2024 at 11:31.
Pushed by davidedmundson into branch 'master'.

Sync config to disk when values change

When client code calls Plasmoid.confiuration.a = b the value in the
KConfigPropertyMap changes, but the underlying KConfigSkeleton does not
have any signals emitted until that value is flushed.

We need to connect it to the existing mechanism to sync changes after a
timeout.
Related: bug 481085, bug 482469, bug 482090, bug 482773, bug 483083

M  +1    -0    src/plasma/applet.cpp

https://invent.kde.org/plasma/libplasma/-/commit/c37a224bc7a33c6bd5ba7c546fec74880ad463b4

Git commit f7b3e98bd5c777a8c7510ec0edaaba6412cac474 by David Edmundson.
Committed on 17/04/2024 at 11:33.
Pushed by davidedmundson into branch 'Plasma/6.0'.

Sync config to disk when values change

When client code calls Plasmoid.confiuration.a = b the value in the
KConfigPropertyMap changes, but the underlying KConfigSkeleton does not
have any signals emitted until that value is flushed.

We need to connect it to the existing mechanism to sync changes after a
timeout.
Related: bug 481085, bug 482469, bug 482090, bug 482773, bug 483083


(cherry picked from commit c37a224bc7a33c6bd5ba7c546fec74880ad463b4)

M  +1    -0    src/plasma/applet.cpp

https://invent.kde.org/plasma/libplasma/-/commit/f7b3e98bd5c777a8c7510ec0edaaba6412cac474

I updated to:
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
And the bug still exist.

Then i created a patch for libplasma-6.0.4 from https://invent.kde.org/plasma/libplasma/-/commit/f7b3e98bd5c777a8c7510ec0edaaba6412cac474 and build it with the patch applied.

But the bug still exist.

Created attachment 168620 [details]
Patch for libplasma-6.0.4

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

(In reply to ollilein from comment #33)
> Created attachment 168620 [details]
> Patch for libplasma-6.0.4

I tried this patch too but the bug still exists for me.

KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.0

Reopening, I can confirm not fixed with the patch applied to libplasma-6.0.4.

I wonder if this could have been caused by the bug that https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/49 fixed. Apparently in some distros, kbuildsycoca is run frequently/repeatedly, and there was previously an issue that could cause some things to not get saved properly.

Can anyone test with Plasma 6.0.5, which includes this fix and is being released today?

Created attachment 169688 [details]
Patch for kglobalacceld-6.0.4

(In reply to Nate Graham from comment #37)
> I wonder if this could have been caused by the bug that
> https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/49 fixed.
> Apparently in some distros, kbuildsycoca is run frequently/repeatedly, and
> there was previously an issue that could cause some things to not get saved
> properly.
> 
> Can anyone test with Plasma 6.0.5, which includes this fix and is being
> released today?

I created a patch from this merge request and applied it but the bug still exist.
I haven't tried Plasma 6.0.5 yet, if it is fixed in 6.0.5, maybe some other change fixed it.

I updated to
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.1

I tried with my standard user and a new clean user, but the bug still persist.

Ok, thanks.

Is there anyone here who's affected and uses BOTH systemd as their init system and ALSO Plasma's systemd boot integration (https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/)?

Or is everyone affected using either something other than systemd, or has disabled the Plasma systemd boot integration?

(In reply to Nate Graham from comment #40)
> Ok, thanks.
> 
> Is there anyone here who's affected and uses BOTH systemd as their init
> system and ALSO Plasma's systemd boot integration
> (https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/)?
> 
> Or is everyone affected using either something other than systemd, or has
> disabled the Plasma systemd boot integration?

I've only noticed the issue on non-systemd setups. I am also still experiencing the issue, but I haven't tested on 6.0.5 yet. I will report back once 6.0.5 is shipped by my distro.

(In reply to Nate Graham from comment #40)
> Ok, thanks.
> 
> Is there anyone here who's affected and uses BOTH systemd as their init
> system and ALSO Plasma's systemd boot integration
> (https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/)?
> 
> Or is everyone affected using either something other than systemd, or has
> disabled the Plasma systemd boot integration?

I'm using the latest KDE Neon, I upgraded from the previous version (5.xxx). This issue did not exist in the previous version. I don't know whether my system is running systemd-startup or not, it's just the stock version :)

(In reply to Nate Graham from comment #40)
> Ok, thanks.
> 
> Is there anyone here who's affected and uses BOTH systemd as their init
> system and ALSO Plasma's systemd boot integration
> (https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/)?
> 
> Or is everyone affected using either something other than systemd, or has
> disabled the Plasma systemd boot integration?

I am using systemd as init system, but i think i don't use systemd-boot integration since i start wayland with the .bashrc script in the home folder, because sddm is making trouble on my system.

Thanks folks.

(In reply to Nate Graham from comment #40)
> Ok, thanks.
> 
> Is there anyone here who's affected and uses BOTH systemd as their init
> system and ALSO Plasma's systemd boot integration
> (https://blog.davidedmundson.co.uk/blog/plasma-and-the-systemd-startup/)?
> 
> Or is everyone affected using either something other than systemd, or has
> disabled the Plasma systemd boot integration?

For a while i tried to setup a system with openrc, but there the bug is present, too.

Hello, I'm facing the same issue here ever since plasma 6 in Artix Linux using dinit, and also on Arch(systemd), no changes seen in 6.0.5 release:
 
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.1

(In reply to Nate Graham from comment #37)
> Apparently in some distros, kbuildsycoca is run frequently/repeatedly, and
> there was previously an issue that could cause some things to not get saved
> properly.
We do nothing of that kind in Gentoo ourselves unless this is somehow triggered in rare KDE Plasma non-systemd code paths. Please note this bug means that Plasma 6 remains masked in Gentoo for the time being, so most users still get Plasma 5.27.11 unless taking additional steps to upgrade.

Not fixed in 6.0.90 either.

KDE Plasma Version: 6.0.90
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.1

I updated to:
KDE Plasma Version: 6.0.90
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.1

and can confirm that the bug is still present.

I can currently reproduce this on Alpine Linux using Plasma 6.0.5 with KDE Frameworks 6.2.0, but only on one of 3 machines (a new laptop).
My desktop and previous laptop have been upgraded from Plasma 5 before and do not experience this issue, but my new laptop that has only ever had Plasma 6 resets on every login.

No systemd, just OpenRC.

I can also confirm this affects Alpine Linux. 

Doing a fresh install on Alpine 3.20 using "setup-alpine" followed by "setup-desktop" leads to this behavior under both the Wayland and X11 sessions (which is odd, because on my Artix Linux system with 6.0.5, this bug only affects the Wayland session).

I am facing the same problem using the plasma-meta metapackage on Arch Linux. None of the solutions helps, I don't know what to do.

workaround:

Pin the icons in taskbar then go to shell

kquitapp6 plasmashell && plasmashell

and reboot icons saved

kaffeefilter@s70.org's workaround works!!
If I may ask, how did you find it?

(In reply to Eriwin Iosef from comment #53)
> kaffeefilter@s70.org's workaround works!!
> If I may ask, how did you find it?

i'm not a developer, but my internet research pointed to plasmashell, that saves the icon list on close.
Try and error, nothing more

There's two bugs at play here:

 - 1) we should be saving when a change happens not just on shutdown

 - 2) plasmashell isn't being shut down cleanly when systemd isn't managing it

I shall follow up on 1. 

We've seen that in other places, that I fixed with libplasma + c37a224bc7a33c6bd5ba7c546fec74880ad463b4, but clearly there's more.

(In reply to kaffeefilter from comment #54)
> (In reply to Eriwin Iosef from comment #53)
> > kaffeefilter@s70.org's workaround works!!
> > If I may ask, how did you find it?
> 
> i'm not a developer, but my internet research pointed to plasmashell, that
> saves the icon list on close.
> Try and error, nothing more

I see. Thanks. And I thought naively doing an strace would have somehow pointed out the problem.

(In reply to David Edmundson from comment #55)
> There's two bugs at play here:
> 
>  - 1) we should be saving when a change happens not just on shutdown
> 
>  - 2) plasmashell isn't being shut down cleanly when systemd isn't managing
> it
> 
> I shall follow up on 1. 
> 
> We've seen that in other places, that I fixed with libplasma +
> c37a224bc7a33c6bd5ba7c546fec74880ad463b4, but clearly there's more.

I support 1) as well. Doing it on shutdown is just improper I feel, unless there's a good reason why it's kept that way in the first place. It also possibly removes it's dependency of systemd's shutdown phases, if that makes sense.

Doing it on shutdown *as well* is fine, it not syncing when a change happens isn't design, it's a bug in the code somewhere.

Identified. 

On config change, the signal propagates up to CoronaPrivate::syncConfig  but no-one is ever calling Applet::save().
We're writing the config to disk, but without syncing between the KConfigLoader and the KConfig.

Adding     saveLayout(q->config()); to CoronaPrivate::syncConfig  before the config()->sync() seems to resolve it.



but it's definitely not a right fix as saveConfig is also emitting propagateConfigChanged, which is semantically what triggers a sync to disk.
I don't understand what this current code is trying to do, will need to do some archeology first.

Edit: I *think* the old code was meant to be:

 - on change start a applet-wide timer and save to the kconfig instance
 - that emits a signal that tells us to sync, which starts a global timer to do a  sync to disk

I removed the former with e08eb3caf329df648d39de8db5182bb862569ef5 as it was clearly broken and not hooked up to anything, but I think the problem was that it should have been.

I'm I'm right I should revert that, and change:

+        connect(d->configPropertyMap, &KConfigPropertyMap::valueChanged, this, &Applet::configNeedsSaving);

to call 

connect(d->configPropertyMap, &KConfigPropertyMap::valueChanged, this, [this](){ d->scheduleModificationNotification()});

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

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

A possibly relevant merge request was started @ https://invent.kde.org/plasma/libplasma/-/merge_requests/1144

Git commit 3bc199d92402e316541d6dec00af9fee66afc341 by Marco Martin, on behalf of David Edmundson.
Committed on 12/06/2024 at 09:16.
Pushed by mart into branch 'master'.

Applet: run full Applet::save when a config value changes

Plasma had two timers for configuration saving:
 - One applet specific, which eventually calls Applet::save
 - One at a corona level, which eventually calls KConfig::save

The former was incorrectly removed because it wasn't hooked up to
anything useful, but the real bug is that it should have been.

When a value changes in the KConfigPropertyMap we need to run through
Applet::save to sync that config loader with our main config. This
implicitly emits the configNeedsSaving which will trigger corona to sync
to disk.

M  +3    -1    src/plasma/applet.cpp

https://invent.kde.org/plasma/libplasma/-/commit/3bc199d92402e316541d6dec00af9fee66afc341

Git commit 1f3f984c02bcf6719fb96182e47546ce62dbef73 by Marco Martin, on behalf of David Edmundson.
Committed on 12/06/2024 at 09:51.
Pushed by mart into branch 'Plasma/6.1'.

Applet: run full Applet::save when a config value changes

Plasma had two timers for configuration saving:
 - One applet specific, which eventually calls Applet::save
 - One at a corona level, which eventually calls KConfig::save

The former was incorrectly removed because it wasn't hooked up to
anything useful, but the real bug is that it should have been.

When a value changes in the KConfigPropertyMap we need to run through
Applet::save to sync that config loader with our main config. This
implicitly emits the configNeedsSaving which will trigger corona to sync
to disk.

M  +3    -1    src/plasma/applet.cpp

https://invent.kde.org/plasma/libplasma/-/commit/1f3f984c02bcf6719fb96182e47546ce62dbef73

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

Created attachment 170421 [details]
Patch for libplasma-6.0.90

I have made a patch for libplasma-6.0.90. And what should i say the bug is solved, now pining and unpining apps to the task manager works.

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

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

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