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?

  • zeus ⁧ ⁧ ∽↯∼@lemm.ee
    2·
    1 year ago

    i agree with all of this, and in fact would go a step further to say: nicer names in general. what in the nine is plasma-org.kde.plasma.desktop-appletsrc‽ why not just plasma-appletsrc?

    i think the real problem is the manpower to do it all though

  • stevecrox@mastodonapp.uk
    0·
    1 year ago

    @MartinR the Maven convention for packaging is a group identifer/package is the inverse domain order.

    Taking plasma-org.kde.desktop-appletsrc you would create a group identifer of: org.plasma.kde.desktop With the artefact identifier being: appletsrc.

    The folder structure would then look like:

    .config  
\-\>org  
\-\>-\>plasma  
\-\>-\>-\>kde  
\-\>-\>-\>-\>desktop  
\-\>-\>-\>-\>-\>appletsrc

    Its simple

    • happyhippo@feddit.it
      1·
      1 year ago

      I always considered plasma to be a part/sub project of kde, therefore org.kde.plasma would seem correct-er.

    • MartinR@feddit.deOP
      1·
      1 year ago

      The proposal isn’t mine, I just read and shared it :-) The blog post has a paragraph or two about multpile subfolders, as I read it, the specification is not clear on whether thats supported? But actually: at first glance I think this would be better to have, because it would possibly make synchronizing to a new PC/Laptop even easier. However, this only works if any machine-specific settings (e.g. “offset /size of window”) are not stored in config, as that might break if you sync config between a multi-monitor setup and a single-monitor setup. This requires a lot of thought…

    • Molecular0079@lemmy.world
      1·
      1 year ago

      That feels way too nested to be useful IMHO. It’s great for packaging dev tools, but not really for handling config directories for user space apps. I just want ~/.config/KDE/<app>

  • Thwompthwomp@lemmy.world
    0·
    1 year ago

    Would this mean a copy and a paste of the config folder would bring up a new KDE system to my personalizing without going through konsave juggling?

    I think that’s my biggest complaint that I don’t know how to import my desktop config (window decorations, panel layout, desktops, activities, fonts, application themes) into a new install easily or the “proper” way

    • MartinR@feddit.deOP
      2·
      1 year ago

      I’m not sure (not the author) and I think syncing config is a lot more difficult than it would seem at first glance. Eg Panel Layout: Imagine syncing between a multi-monitor-setup (work PC) and a single-monitor-setup (Laptop) - how’s that supposed to work? The panel might be on the second screen on the PC, but once synchronized to the Laptop, that would mean either

      • missing panel (off screen)
      • double panel (stacked on top of each other)
      • hidden second panel (one below the other)
      • …

      Syncing .config would (at first glance) work best for device independent settings (e.g.: Indentation in Kate with Tabs vs. Spaces) - but even “fonts” in Kate might already not be a good idea, as a font might not be installed in both systems (and it might get worse with font-sizes, scale-factors…)