I believe in the forum thread you said the following:

*** below from discuss ***

I disabled the effects and can see the change in `./config/kwinrc` - but it does not say `=false` but `[$d]`:

[Plugins]
shakecursorEnabled=false
translucencyEnabled[$d]
wobblywindowsEnabled[$d]

(In reply to Rik Mills from comment #1)
> I disabled the effects and can see the change in `./config/kwinrc` - but it
> does not say `=false` but `[$d]`:
> 
> [Plugins]
> shakecursorEnabled=false
> translucencyEnabled[$d]
> wobblywindowsEnabled[$d]
This is the cause of the behavior; the [$d] values in your config are blocking user-set overrides to the system defaults. So it's a feature, not a bug. :) 

The question is what or who set them. It's not coming from upstream KDE, so this will be caused by your distro, yourself (by accident or ion purpose in the past, and you forgot about it — it happens!), or some software you've installed.

I don't think this is a downstream behavior. I don't believe attributes marked as [$d] should be deleted at logout, but that appears to be what is happening. I posted this a minute ago but got "mid-air collision". I've reopened it for your reconsideration:

Further research from the OP shows that while he can set the behavior he wants during a desktop session,  the user configurations, normally found in `.config/kwinrc`, are completely removed when he logs back in.  I suspect this remove occurs at logout by kwin or some other process.

To Reproduce:

1. Set the env by logging out of the desktop and doing the following:
export XDG_CONFIG_DIRS=$HOME/.config/kdedefaults:/etc/xdg:/usr/share/kubuntu-default-settings/kf5-settings
echo '[TabBox]
TouchBorderActivate=
TouchBorderAlternativeActivate=

[Effect-translucency]
MoveResize=75

[NightColor]
Mode=Constant

[Effect-DesktopGrid]
LayoutMode=1

[Effect-PresentWindows]
LayoutMode=1

[Plugins]
overviewEnabled=true
translucencyEnabled=true
wobblywindowsEnabled=true
' |sudo tee /usr/share/kubuntu-default-settings/kf5-settings/kwinrc
rm ~/.config/kwinrc

2. Log in and in Desktop Effects, disable wobble and translucency. Then inspect ~/.config/kwinrc:
 [Plugins]
translucencyEnabled[$d]
wobblywindowsEnabled[$d]

3. Log out and in again, then enable  “Fall Apart” effect. Then inspect ~/.config/kwinrc: 

[Plugins]
fallapartEnabled=true
translucencyEnabled[$d]
wobblywindowsEnabled[$d]

4. Log out and back in again and Inspect ~/.config/kwinrc:

[Plugins]
fallapartEnabled=true

At this point, wobbly windows and translucency are re-enabled.

(In reply to Nate Graham from comment #2)
> (In reply to Rik Mills from comment #1)
> > I disabled the effects and can see the change in `./config/kwinrc` - but it
> > does not say `=false` but `[$d]`:
> > 
> > [Plugins]
> > shakecursorEnabled=false
> > translucencyEnabled[$d]
> > wobblywindowsEnabled[$d]
> This is the cause of the behavior; the [$d] values in your config are
> blocking user-set overrides to the system defaults. So it's a feature, not a
> bug. :) 
> 
> The question is what or who set them. It's not coming from upstream KDE, so
> this will be caused by your distro, yourself (by accident or ion purpose in
> the past, and you forgot about it — it happens!), or some software you've
> installed.

I installed KDE for the first time in my life about 2 months ago. It was KDE 6.4 which came with Kubuntu 25.10. Then I upgraded it to KDE 6.5 based on the backport repository:

sudo add-apt-repository ppa:kubuntu-ppa/backports
sudo apt update
sudo apt full-upgrade

Until that version everything was ok with these desktop effects. It only started after I upgraded to Kubuntu 26.04 with KDE 6.6.4 - the version which comes with Kubuntu and where I don't use and PPA any longer. The value [$d] is written as soon I press the "Apply" button in the settings after I disabled the checkboxes for these plugins.

However - in /usr/share/kubuntu-default-settings/kf5-settings/kwinrc I find the following lines:

[Plugins]
overviewEnabled=true
translucencyEnabled=true
wobblywindowsEnabled=true

Created attachment 191866 [details]
systemsetting writing the wrong values

(In reply to Nate Graham from comment #2)
> (In reply to Rik Mills from comment #1)
> > I disabled the effects and can see the change in `./config/kwinrc` - but it
> > does not say `=false` but `[$d]`:
> > 
> > [Plugins]
> > shakecursorEnabled=false
> > translucencyEnabled[$d]
> > wobblywindowsEnabled[$d]
> This is the cause of the behavior; the [$d] values in your config are
> blocking user-set overrides to the system defaults. So it's a feature, not a
> 
> The question is what or who set them. It's not coming from upstream KDE, so
> this will be caused by your distro, yourself (by accident or ion purpose in
> the past, and you forgot about it — it happens!), or some software you've
> installed.

This is categorically completely untrue. We are not setting that value. It is being set 

(In reply to Nate Graham from comment #2)
> (In reply to Rik Mills from comment #1)
> > I disabled the effects and can see the change in `./config/kwinrc` - but it
> > does not say `=false` but `[$d]`:
> > 
> > [Plugins]
> > shakecursorEnabled=false
> > translucencyEnabled[$d]
> > wobblywindowsEnabled[$d]
> This is the cause of the behavior; the [$d] values in your config are
> blocking user-set overrides to the system defaults. So it's a feature, not a
> bug. :) 
> 
> The question is what or who set them. It's not coming from upstream KDE, so
> this will be caused by your distro, yourself (by accident or ion purpose in
> the past, and you forgot about it — it happens!), or some software you've
> installed.

I can 100% without any doubt say that is is KDE systemsettings setting those `[$d]' values.

On a clean install when I check ~/config/kwinrc there are no settings for windows or translucency.

HOWEVER, once changed in systemsettings to turn these off, the resultant written ~/config/kwinrc has that

To be extra clear, I attach the output as an image of git diff on a system where the ~/.config/ dir has been made to be an ad hoc git repo to track changes. The sequence here is 1) confirm no changes from git diff. 2) disable wobbly windows/translucency in systemsettings. 3) do git diff again and see the change written. All those done in direct sequence in a matter of seconds.

Apologies for the double copy/paste in the previous comment

I have the same issue that happens in Kubuntu 26.04, upgraded from 25.10.

I do see that translucency and wobbly windows are set to "true" in /usr/share/kubuntu-default-settings/kf5-settings.

My workaround has been to uncheck the "Wobble when moving" and "Wobble when resizing" settings in Wobbly Windows and make all the sliders in the Translucency settings set to "opaque," so when the effects get reenabled they thankfully don't have any visible effect.

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

Maybe we can find out with auditctl who writes wrong things?

I'm seeing the same thing on my system after upgrading Kubuntu 25.10 to 26.04. It seems to happen somewhat randomly; I haven't been able to discern a pattern yet but I don't think it's every login. I'm seeing the same [$d] values in kwinrc. I'm pretty sure I modified these settings at some point while playing around with window manager features, but it was months ago.

My first ever Linux bug report. Kubuntu 26.04, VMWare virtual machine.

I want to add the following observation. If I disable both Translucency and Wobbly Windows then WW is re-enabled at the next boot. If I leave Translucency then WW stays disabled. So it seems I cannot keep both disabled simultaneously. This behavior is consistent, not random.

The bug must be in System Settings. Sometimes I manage to have the wanted configuration, both effects disabled:
[Plugins]
translucencyEnabled[$d]
wobblywindowsEnabled[$d]

If I enable both then the ./config/kwinrc is correct:
[Plugins]
translucencyEnabled=true
wobblywindowsEnabled=true

Then I disable Translucency, still correct:
[Plugins]
translucencyEnabled[$d]
wobblywindowsEnabled=true

Now if I disable Wobbly I got this:
[Plugins]
wobblywindowsEnabled[$d]

It seems setting one deletes the state of the other one. Hope this helps.

A temporary workaround if you have root access:
Create /etc/xdg/kwinrc to have appropriate values based on what you see in /usr/share/kubuntu-default-settings/kf5-settings/kwinrc. Plasma won't be able to change those values. You could also try $HOME/.config/kdedefaults/kwinrc.

I seem to have been able to work around this by editing ~/.config/kwinrc with a text editor and changing those lines to read:

translucencyEnabled=false
wobblywindowsEnabled=false

So far so good; I haven't seen wobbly windows come back despite a number of logouts and reboots. I also haven't made any other changes via that settings page, so YMMV.

It seems System Settings cannot handle existing [$d] (disabled) values. Let's say you have:

translucencyEnabled[$d]
wobblywindowsEnabled[$d]

If you enable or disable any other effect and click Apply, the existing [$d] values are removed (you can verify ./config/kwinrc). As a result, those effects become enabled again, but you only notice this after a reboot.

I sent this to the Kubuntu devs. It looks like it wasn’t the right answer, but here it is:

What I found: wooblywindows/metadata.json has:

"EnabledByDefault": false

but "kwin/src/kcms/common/effectsmodel.cpp" Save function is:

        const bool restoreToDefault = effect.enabledByDefaultFunction
            ? effect.status == Status::EnabledUndeterminded
            : shouldEnable == effect.enabledByDefault;
        if (restoreToDefault) {
            kwinConfig.deleteEntry(key, KConfig::Notify);
        } else {
            kwinConfig.writeEntry(key, shouldEnable, KConfig::Notify);
        }

I believe that because effect.enabledByDefault is false the deleteEntry method is called. EnabledByDefault should be set to "true" in metadata.json. Also "translucency" does not have an EnabledByDefault property, so I assume it is "false" by default.

Settings "EnabledByDefault" to "true" in metadata.json seems to fix this issue.

Second try:

We have this code, and I think the bug might be here:

        const bool restoreToDefault = effect.enabledByDefaultFunction
            ? effect.status == Status::EnabledUndeterminded
            : shouldEnable == effect.enabledByDefault;
        if (restoreToDefault) {
            kwinConfig.deleteEntry(key, KConfig::Notify);
        } else {
            kwinConfig.writeEntry(key, shouldEnable, KConfig::Notify);
        }
 
For plugins, this evaluates to shouldEnable == effect.enabledByDefault, but in loadPluginEffects():
 effect.enabledByDefault = pluginEffect.isEnabledByDefault();
This means that only the metadata setting is checked (for WooblyWindows, it is "false"). The kwinConfig setting (which is "true" in Kubuntu) is not checked here, so its value is lost.

If this is true, then the bug is in KDE, and instead of using effect.enabledByDefault, the whole chain should re-checked: the metadata and kwinConfig(s), exactly like in pluginmanager.cpp.

    auto checkEnabled = [&config](const QString &pluginId, const QJsonObject &metadata) {
        const QString configKey = pluginId + QLatin1StringView("Enabled");
        if (config.hasKey(configKey)) {
            return config.readEntry(configKey, false);
        }
        return readPluginInfo(metadata, QStringLiteral("EnabledByDefault")).toBool(false);
    };

This is hopefully fixed with https://invent.kde.org/frameworks/kconfig/-/merge_requests/451 it sounds very related.

Please reopen if it's still an issue with this kconfig patch.

Are you sure this is fixed? I've checked the latest master sources, and the bug is still present. I have my own (hacky) fix for it.

(In reply to David Edmundson from comment #19)
> This is hopefully fixed with
> https://invent.kde.org/frameworks/kconfig/-/merge_requests/451 it sounds
> very related.

It doesn't; I asked in https://invent.kde.org/frameworks/kconfig/-/merge_requests/451#note_1507061

I believe this bug was caused by this commit to KConfig:

https://invent.kde.org/frameworks/kconfig/-/commit/7a34db5ab0666addabd038269366407645b04647

which adds the following code to kconfigdata.cpp:

bool KEntryMap::setEntry(const QString &group, const QByteArray &key, const QByteArray &value, KEntryMap::EntryOptions options)
{
    ...
    if (newKey) {
        ...
        // if the key is new and we want to delete it that's a no-op
        if (e.bDeleted) {
            return false;
        }
        ...
    }
}

When System Settings saves settings it calls KConfig's KConfigIniBackend::writeConfig(). This function first reparses the file on disk to merge local changes with those made by other applications, so it calls parseConfig() with the merging option enabled. In parseConfig() each entry is passed to KEntryMap::setEntry().

Values marked with the [$d] deletion marker are considered "bDeleted", so they are silently dropped (see the "no-op" comment above). As a result, these entries are ignored and are not written back to the new configuration file.

Example:

translucencyEnabled[$d]
wobblywindowsEnabled[$d]

To fix this you could either revert the change or introduce a new option that forces deleted entries to be preserved whenn merging:

  if (e.bDeleted && !(options & EntryForceAddDeleted)) {
      return false;
  }

and in parseConfig():

  case 'd':
      entryOptions |= KEntryMap::EntryDeleted;
      if (merging) {
          entryOptions |= KEntryMap::EntryForceAddDeleted;
      }
      aKey.truncate(start);
      printableToString(aKey, mDeviceInterface.get(), lineNo);
      entryMap.setEntry(currentGroup, aKey.toByteArray(), QByteArray(), entryOptions);

This code was probably added to prevent the accumulation of obsolete keys, keys that no longer have defaults.

Note: loading the configuration works even though it follows almost the same code path (parseConfig(), setEntry()). I think that the loaded map already contains the key from a higher level configuration file, so the deletion marker entry is not considered a new key ("newKey" is false) and is loaded correctly.

Interestingly the same person who made the initial commit has an open merge request that implements the save logic in effectsmodel.cpp:

https://invent.kde.org/plasma/kwin/-/merge_requests/8112

If I understand correctly, all of this should be handled by KConfig rather than re-implemented in multiple places.

I hope this helps. This is my first KDE Hack Week.

Note: the solution adding KEntryMap::EntryForceAddDeleted to the EntryOption enum would likely break ABI, and since the “merging” operation is not an option on a per-entry basis anyway, we could add a class property to KEntryMap to signal this mode and force the entry to be added.

Update:
Most likely the bug is in the writeConfig/parseConfig/setEntry logic. The first time the config is parsed, the deletion marker enty overwrites the global entry. As a result, the second time the config is parsed the deletion marker entry is treated as a nonexistent key and is silently dropped.

The key dropping behavior was introduced in this commit, but the bug was not actually "caused by" it as I stated earlier. The change fixes a legitimate issue with nonexistent keys:

https://invent.kde.org/frameworks/kconfig/-/commit/7a34db5ab0666addabd038269366407645b04647

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kconfig/-/merge_requests/462

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

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

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kconfig/-/merge_requests/469

Git commit a2504d59422c2846e749c0829df4d500262d63d3 by Nicolas Fella.
Committed on 10/07/2026 at 12:13.
Pushed by nicolasfella into branch 'master'.

Always insert deleted key into internal map

7a34db5ab0666addabd038269366407645b04647 changed the logic so
that deleting a new key would be treated as a no-op, so that
the config isn't marked as dirty afterwards.

However this resulted in entries missing from the map and being
lost on unrelated config writes.

To fix this partially restore the old code and insert the key.
Still return false though so that it's not marked as dirty.

Co-authored-by: David Wild <davidwild@gmx.com>

M  +13   -0    autotests/kconfigtest.cpp
M  +2    -1    src/core/kconfigdata.cpp

https://invent.kde.org/frameworks/kconfig/-/commit/a2504d59422c2846e749c0829df4d500262d63d3

Git commit 940ea62cd9bfb539cc713f93356cd4321a4dc876 by Marco Martin.
Committed on 03/09/2026 at 09:39.
Pushed by mart into branch 'Frameworks/6.24'.

Always insert deleted key into internal map

7a34db5ab0666addabd038269366407645b04647 changed the logic so
that deleting a new key would be treated as a no-op, so that
the config isn't marked as dirty afterwards.

However this resulted in entries missing from the map and being
lost on unrelated config writes.

To fix this partially restore the old code and insert the key.
Still return false though so that it's not marked as dirty.

Co-authored-by: David Wild <davidwild@gmx.com>


(cherry picked from commit a2504d59422c2846e749c0829df4d500262d63d3)

Co-authored-by: Nicolas Fella <nicolas.fella@gmx.de>

M  +13   -0    autotests/kconfigtest.cpp
M  +2    -1    src/core/kconfigdata.cpp

https://invent.kde.org/frameworks/kconfig/-/commit/940ea62cd9bfb539cc713f93356cd4321a4dc876