I want a clean config directory! :: rabbiticTranslator
rabbitictranslator.com
And it can be done easily, ackshually. But what is that all about? The problem It has been a longstanding complaint that the ~/.config/ directory on Linux systems can get riddled with configuration files. This is the case with KDE software as well. My idea is that we should be putting those into subdirectories inside ~/.config/. The Freedesktop XDG Base Directory specification generally only states that standard configuration files should go under XDG_CONFIG_DIRS.

There’s a proposal at the linked blog post for how to clean up the config directory.

The post goes into detail which changes would be required in KDE software using Qt.

After reading, I just have one question (the blog does not seem to have a comment section): how does this handle transitioning from the old location to the new location? Imagine having a katerc config file under ~/.config and one under ~/.config/kate (which is the suggestion from the post) - should those be merged once and then the old one gets deleted?

  • HerzenscheinM
    2•1 year ago

    I answered something similar elsewhere:

    If you mean migrating the files yourself, it’s just a matter of copying the file from the old place ~/.config/yourconfigrc to ~/.config/yourapp/yourconfigrc.

    If you mean you want the application to manage the migration itself, that’s an implementation detail I hadn’t thought about yet, but which I assume wouldn’t be difficult to do with KConfig.

    You can see this bit of code from Konsole showing how to migrate from old entries to new entries in the same config file for example: >https://invent.kde.org/utilities/konsole/-/blob/master/src/main.cpp#L99

    The implementation could probably be something similar, with two KConfig/KSharedConfigPtr instances I assume 👀 so:

    • if oldConfig exists, create an object for it
    • read all oldConfig entries
    • if it differs from newConfig, store which ones differ
    • write all different oldConfig entries in newConfig object
    • sync()

    Something like that.

    • @[email protected]OP
      1•1 year ago

      Just for clarification: this would be a one-time process per application, right? I’m sure this will work for 99% of users, but there’ll always be the one (or a couple of users) that synchronizes their .config directory, then doesn’t update all machines at the same time and all hell breaks loose - a.k.a https://xkcd.com/1172/ :-) But I’d say that’s probably not worth losing the advantages of a cleaner .config-directory, so this might be one of those “tough-luck” situations… 🤷

      • HerzenscheinM
        1•1 year ago

        I think so. I mean, the migration code would still be there afterwards, maybe removed after several versions later.

        If the user syncs machines with different application versions I’m not sure there’s anything that can be done at the code level though. 👀