Le 2018-05-02 16:53, Paul Wouters a écrit :
So I don't think your "User explicitly installed SW into his home directory" is true, and it is especially not true if software can make use of knowing ~/.bin will be there for it to quietly drop some things in.
The XDG spec and its insistence on mediating all accesses via env variables that themselves (by default) point to hidden directories has always been a trainwreck. All the more so since the main justification for this choice was to allow localized directory names in desktop icons that were supposed to be sourced from ~/ except it was quickly superseded by ~/Desktop (in English!), many apps could never have dealt with the codepoints required by some human languages, and the whole thing was finally dumped overboard by GNOME anyway. After many years many apps have still not learned to read those env vars, or hardcode their default value, or whatever. It's massively over-engineered, under-used, opaque to users and so on.
It badly needs to be rewritten without hidden dotdirs, without positing apps that by and large rely on hardcoded default values or config files find suddenly convenient to read env vars all the times just in case someone deemed smart to rename default dir names to something else (the legacy XDG envs vars could then point to the new dir hierarchy for the apps that bother reading them), in fact, without positing that part of the *nix directory hierarchy has a specific renaming behavior when the rest is fixed in stone (that's too much schizophrenia for the average *nix app writer).
But, at the same time, the dotfiles mess that existed before the XDG spec (and continues to exist since lots of apps have not migrated yet) was much worse. And writing a spec, and getting consensus on it, requires a lot of time, work, and persistence.
So in that thence, the XDG spec is wonderful and we should all be glad it exists.
There is little point in complaining the spec is misdesigned. It has been known to be misdesigned for years, in fact since it was first discussed and before it was ever finalized. But, existing alternatives are worse. Unless someone intends to work on a better XDG v2 today, the only constructive choice is to apply it as is.
Because alternatives are worse. Regards, -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
