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

--- Comment #22 from ALIEN426 <[email protected]> ---
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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to