[saulrh]

The really fun part is when you have a program that has ~/.programX, but also ~/.programXy, ~/.programX_cache, ~/.programxrc, ~/.programx_init, ~/.programx/a_whole_directory, ~/.otherthing, ~/.maybe_a_database_for_good_measure.sqlite, ~/.and_the_kitchen_sink_too. And that's not even getting into questions like "can I nuke ~/.programX_db to clear the program's cache without losing my configurations?". I agree that the XDG spec isn't an improvement for programs that have _precisely_ one config file, but it's a _major_ improvement for programs that need multiple config files, config directories, separate configs and caches, and more, and it's not a _regression_ from single-file configs.

[ajsnigrutin]

That's why that kind of software uses a .programX directory, where everything like that can be put in.

Look at ~/.wine for example... config files, whole C drive, everything in one simple folder. Want to upgrade to an alpha version to test something, but don't want to break anything that's now working? Just backup that one single folder. Restore or migrate configuration to another computer? One single folder. Remove any trace of that app? Again, one simple folder.

Want to do the same with google chrome? .config/google-chrome... oh wait, what if there's something in .local too? Still doesn't work? Oh wait, you forgot the .cache directory, and have been loading an old version of something.

[subsection1h]

> Just backup that one single folder.

Backups are the main reason why I want programs to follow the XDG Base Directory Specification. I don't want my backups to includes gigabytes of files that should be in ~/.cache, which is a directory I never back up. The shell script that I wrote to back up my PC includes dozens of rsync exclusions for files in ~/.mozilla, etc. that should be in ~/.cache.

[interfixus]

> Look at ~/.wine for example... config files, whole C drive, everything in one simple folder

Except it isn't really. Just a few days ago I tried to purge Wine from my system. Uninstalled through pacman, cleaned up orphaned dependencies. Killed the ./wine folder and various other leftovers too, because depite your claim, there they were, though I didn't commit to memory exactly where and what. Removed some autostart shortcuts, cleared a few icons from desktop, and manually edited the Plasma menu to remove some stubborn links.

And yet ... I still get suggestions to open my jpg's and png's with something called Wine Internet Explorer. Which i don't really believe is distro specific, since I've seen the same thing happen in both Debian and RedHat derivatives.

[jchw]

Just FYI, in case it is useful for you: Here's the information that you would want for cleaning that up.

https://wiki.winehq.org/FAQ#How_do_I_clean_the_Open_With_Lis...

If you ever want to prevent this integration from happening in the first place, you can do it by editing the registry in a given wine prefix. You can run regedit with the usual command, `wine regedit`, then locate the key:

HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices\winemenubuilder

Set it to empty to disable the integration entirely. Or, just remove the `-a` switch and you will still get desktop icons, just not file associations.

It is unfortunate that it has to be outside of the WINEPREFIX, but there's no way around it, since those various files need to be in their respective locations to reasonably be picked up. (Maybe it could use symlinks instead, but even if it did, they'd need to get cleaned up by something when the target gets deleted.)

[account42]

> It is unfortunate that it has to be outside of the WINEPREFIX, but there's no way around it

There is a way around unwanted and unexpected associations though: make the integration opt-in instead of opt-out and/or filter associations that the user is unlikely to ever want (like standard file types that will almost certainly already be handled outside Wine). Wine's Internet Explorer is there for compatibilty with Windows programs that expect IE, exposing it outside the Wine environment does not make any sense.

Since I use multiple prefixes, including temporary ones, editing registry in each one of them is not an option so I have my package manager set not to install winemenubuilder at all.

[jchw]

I believe another approach is to edit the default registry settings in /usr/share/wine/wine.inf so that new prefixes have the desired setting. Of course, then when updating the package it has to be reconciled. But it does have the advantage of being able to allow e.g. the settings that would only produce launcher icons and not file associations. There's another method using environment variables too, though I think that one basically works the same as removing the package entirely and can't be used to customize the behavior.

I kind of agree with you that the defaults are not great, or at least if things haven't changed. We could always see if maybe they'll accept patches to filter out more stuff by default.

[YourDadVPN]

This is probably because Wine created a .desktop file in the directory for registering default applications. I don't remember what the directory path is but your package manager is responsible for it, not Wine. They can't put it in .wine because it's a standardised location.

[account42]

IMO, Wine desktop integration should be off by default.

Like with privacy issues, once you realize you want to opt out the mess has already been made.

[kevin_thibedeau]

If you have a mass of cached data that shouldn't be backed up would you rather just exclude .cache or investigate what files/directories every individual app uses.

[iforgotpassword]

> That's why that kind of software uses a .programX directory, where everything like that can be put in.

You mean, this is why that kind of software should use a .programX directory. Evidently many don't. And of you think about doing it, just move it into .config for good measure...

Crap like wget just keeps shoving files directly into my home instead. When they added hsts support they had the chance to finally create a directory, ideally in .config, so if they need to add even more files in the future they wouldn't have to clutter $HOME even more. But no, that would be too forward-thinking. Just put the hsts file in home and be done.