Bug 481113 - When not using Systemd or Plasma's Systemd session launch integration, changes to pinned apps are not saved when Plasmashell quits
Summary: When not using Systemd or Plasma's Systemd session launch integration, change...
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Task Manager and Icons-Only Task Manager (show other bugs)
Version: 5.93.0
Platform: Gentoo Packages Linux
: HI normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: qt6, wayland
: 481085 486021 487705 488337 488469 490359 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-02-09 09:38 UTC by ollilein
Modified: 2024-07-16 15:33 UTC (History)
28 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.1.0
Sentry Crash Report:


Attachments
plasmashell.log (44.39 KB, text/plain)
2024-03-13 21:44 UTC, Andreas Sturmlechner
Details
dbus-run-session startplasma-wayland output (24.06 KB, text/x-log)
2024-03-14 14:19 UTC, Jaroslav Krpálek
Details
Patch for libplasma-6.0.4 (457 bytes, patch)
2024-04-17 14:30 UTC, ollilein
Details
Patch for kglobalacceld-6.0.4 (2.00 KB, patch)
2024-05-21 18:54 UTC, yurzhang.oi
Details
Patch for libplasma-6.0.90 (4.29 KB, patch)
2024-06-12 14:41 UTC, ollilein
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ollilein 2024-02-09 09:38:00 UTC
SUMMARY
I have a strange Problem with the window bar, i have upgraded from plasma5 to plasma6 yesterday. Now when i try to remove or add an app to the window bar it shows me the change, but after a restart from wayland or a reboot it shows the former apps again, the change isn't persistent.
***
NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols.
See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***


STEPS TO REPRODUCE
1. Pin an app to the window bar
2. restart wayland
3. 

OBSERVED RESULT
I can't pin or unpin new apps to the window bar

EXPECTED RESULT
The window bar shows new apps i have pinned there.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: Gentoo 2.14
(available in About System)
KDE Plasma Version: 5.93.0
KDE Frameworks Version: 5.249.0
Qt Version: 6.6.1

ADDITIONAL INFORMATION
I use nvidia-drivers-550.40.07, but same problem with 545.29.06-r1
Comment 1 ollilein 2024-02-09 09:52:20 UTC
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.
Comment 2 fanzhuyifan 2024-02-09 16:45:53 UTC
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?
Comment 3 ollilein 2024-02-09 16:55:54 UTC
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.
Comment 4 Nate Graham 2024-02-21 20:15:06 UTC
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.
Comment 5 ollilein 2024-02-28 16:52:23 UTC
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.
Comment 6 Nate Graham 2024-03-01 20:39:47 UTC
*** Bug 482090 has been marked as a duplicate of this bug. ***
Comment 7 ollilein 2024-03-07 09:34:23 UTC
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.
Comment 8 gigastarcraft2 2024-03-08 11:04:49 UTC
(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.
Comment 9 Sam James 2024-03-08 19:38:50 UTC
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.
Comment 10 Nate Graham 2024-03-08 20:40:03 UTC
Folks able to reproduce this issue, are you by any chance *not* using the systemd boot feature?
Comment 11 gigastarcraft2 2024-03-08 22:05:36 UTC
(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.
Comment 12 Maria Keating 2024-03-09 03:49:37 UTC
(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).
Comment 13 yamagi 2024-03-09 10:07:49 UTC
I'm seeing this on Arch Linux with Plasma 6.0.1 and I'm using systemd boot.
Comment 14 ollilein 2024-03-09 14:07:40 UTC
(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.
Comment 15 ollilein 2024-03-09 20:03:54 UTC
(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.
Comment 16 ollilein 2024-03-12 18:21:17 UTC
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
Comment 17 Andreas Sturmlechner 2024-03-13 21:23:35 UTC
*** Bug 482469 has been marked as a duplicate of this bug. ***
Comment 18 Randall Winkhart 2024-03-13 21:30:00 UTC
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.
Comment 19 Andreas Sturmlechner 2024-03-13 21:44:26 UTC
Created attachment 167128 [details]
plasmashell.log

Here's a plasmashell log of me starting a wayland session from tty.
Comment 20 Andreas Sturmlechner 2024-03-13 21:55:55 UTC
(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/
Comment 21 Jaroslav Krpálek 2024-03-14 14:19:17 UTC
Created attachment 167168 [details]
dbus-run-session startplasma-wayland output

Throwing in my log for safe measure as well.
Comment 22 ollilein 2024-03-15 16:24:03 UTC
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.
Comment 23 Andreas Sturmlechner 2024-03-19 08:36:03 UTC
(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. :)
Comment 24 Jaroslav Krpálek 2024-03-19 16:44:11 UTC
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.
Comment 25 Mike Pagano 2024-03-21 18:57:06 UTC
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.
Comment 26 ollilein 2024-03-22 08:41:34 UTC
(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.
Comment 27 ollilein 2024-03-27 19:29:38 UTC
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.
Comment 28 ollilein 2024-04-15 09:28:17 UTC
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.
Comment 29 Bug Janitor Service 2024-04-16 09:01:13 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libplasma/-/merge_requests/1100
Comment 30 David Edmundson 2024-04-17 11:33:05 UTC
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
Comment 31 David Edmundson 2024-04-17 11:36:07 UTC
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
Comment 32 ollilein 2024-04-17 14:29:52 UTC
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.
Comment 33 ollilein 2024-04-17 14:30:39 UTC
Created attachment 168620 [details]
Patch for libplasma-6.0.4
Comment 34 Nate Graham 2024-04-26 16:24:48 UTC
*** Bug 486021 has been marked as a duplicate of this bug. ***
Comment 35 yurzhang.oi 2024-05-15 19:16:42 UTC
(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
Comment 36 Andreas Sturmlechner 2024-05-20 21:11:45 UTC
Reopening, I can confirm not fixed with the patch applied to libplasma-6.0.4.
Comment 37 Nate Graham 2024-05-21 17:20:07 UTC
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?
Comment 38 yurzhang.oi 2024-05-21 18:54:04 UTC
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.
Comment 39 ollilein 2024-05-22 17:30:20 UTC
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.
Comment 40 Nate Graham 2024-05-22 20:20:43 UTC
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?
Comment 41 Randall Winkhart 2024-05-22 20:32:26 UTC
(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.
Comment 42 Washington 2024-05-22 21:21:37 UTC
(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 :)
Comment 43 ollilein 2024-05-23 08:41:41 UTC
(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.
Comment 44 Nate Graham 2024-05-23 19:14:57 UTC
Thanks folks.
Comment 45 ollilein 2024-05-24 07:52:49 UTC
(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.
Comment 46 Eriwin Iosef 2024-05-27 13:44:00 UTC
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
Comment 47 Andreas Sturmlechner 2024-05-27 15:29:23 UTC
(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
Comment 48 ollilein 2024-05-28 09:11:42 UTC
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.
Comment 49 Bart Ribbers 2024-05-30 16:39:39 UTC
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.
Comment 50 Randall Winkhart 2024-05-30 22:07:11 UTC
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).
Comment 51 andrey.lastovenko 2024-06-05 13:21:37 UTC
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.
Comment 52 kaffeefilter 2024-06-07 12:12:40 UTC
workaround:

Pin the icons in taskbar then go to shell

kquitapp6 plasmashell && plasmashell

and reboot icons saved
Comment 53 Eriwin Iosef 2024-06-08 05:18:51 UTC
kaffeefilter@s70.org's workaround works!!
If I may ask, how did you find it?
Comment 54 kaffeefilter 2024-06-08 08:07:25 UTC
(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
Comment 55 David Edmundson 2024-06-08 08:29:55 UTC
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.
Comment 56 Eriwin Iosef 2024-06-08 09:24:03 UTC
(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.
Comment 57 Eriwin Iosef 2024-06-08 09:26:42 UTC
(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.
Comment 58 David Edmundson 2024-06-08 10:19:31 UTC
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.
Comment 59 David Edmundson 2024-06-08 10:26:13 UTC
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()});
Comment 60 Nate Graham 2024-06-11 13:56:58 UTC
*** Bug 488337 has been marked as a duplicate of this bug. ***
Comment 61 Nate Graham 2024-06-11 19:13:16 UTC
*** Bug 487705 has been marked as a duplicate of this bug. ***
Comment 62 Bug Janitor Service 2024-06-11 19:48:40 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libplasma/-/merge_requests/1144
Comment 63 Marco Martin 2024-06-12 09:18:28 UTC
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
Comment 64 Marco Martin 2024-06-12 09:51:20 UTC
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
Comment 65 Nate Graham 2024-06-12 13:35:51 UTC
*** Bug 481085 has been marked as a duplicate of this bug. ***
Comment 66 ollilein 2024-06-12 14:41:14 UTC
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.
Comment 67 Nate Graham 2024-06-14 15:57:02 UTC
*** Bug 488469 has been marked as a duplicate of this bug. ***
Comment 68 cwo 2024-07-16 15:33:18 UTC
*** Bug 490359 has been marked as a duplicate of this bug. ***