Any sane distro creates the XDG user directories config file to handle the translation issue. Unfortunately since nothing in Linux is a “standard”, there are distros that lack this file and therefore have no way of identifying the proper path to the “Documents directory”
The commit 079203c3 which fixed issue #7543 fixes also #5288.
The implementation uses glib function which in turn uses the value of XDG_DATA_HOME environment variable if it exists, and $HOME/.local/share as a fallback. XDG_DATA_HOME is probably $HOME/.local/share on most Linux plaftorms. It’s pretty safe to assume that KiCad uses $HOME/.local/share, but it’s not 100% certain.
The idea of using environment variables in freedesktop standard is that it’s easy to change it for a system or a user. But it affects dozens of applications. If someone wants to get rid of the hidden folder it’s easy enough to set XDG_DATA_HOME to something different and move the contents of ~/.local/share there – but .local/share may have directories created by apps which don’t use XDG, so they won’t be aware of the change.
KICAD_DOCUMENTS_HOME still works, for users who want to relocate just the KiCad path without relocating XDG_DATA_HOME
1 Like
There has been too much discussion going on so I didn’t read the issue carefully enough to find KICAD_DOCUMENTS_HOME. Unfortuntately handling of env var names isn’t centralized in KiCad (yet?) so it’s difficult to find them in the source code.
The name DOCUMENTS is a bit misleading because XDG_DATA_DIR and g_get_user_data_dir () is meant for customization data for applications (as far as I can interpret it), not for user documents (the documents proper created by the application, i.e. KiCad projects).
The way KiCad uses this folder is for documents, including user-created templates, user-created libraries, and optionally user-created projects. This goes in the Documents folder on other platforms. This is why we didn’t put it in ~/.local/share in the first place: it’s really more user documents than “customization data”.
Have I misunderstood something? The mentioned commit added in KIPLATFORM::ENV::GetDocumentsPath() the platform specific wxString docsPath = g_get_user_data_dir();. The documentation of this glib function says it’s for “application data such as icons that is customized for a particular user” which seems to me clearly to refer to things like scripts and templates, not for application projects (which usually go to Documents by default).
Right, which is why ~/Documents is a better default path. The way we use this path does not really match the XDG description. The only reason we changed to XDG_DATA_DIR is because we can’t rely on ~/Documents as described in this thread, and XDG_DATA_DIR is the “closest” option that is reasonably guaranteed to exist.
“application data” in this case usually means “things the user will never need to manually mess around with outside of the applicaton”. That is not the case for these files: we expect (some) users to manage files in this directory outside of KiCad. That’s the whole reason we were trying to avoid putting it in a hidden folder (~/.local) in the beginning. We consider scripts and templates to be user documents, not “application data”.
My confusion was about calling “documents” something which isn’t a “user document” in its most used or most common meaning.
How KiCad now actually works on Linux is what I would expect: user specific data which is used by the application but not a project and not a configuration/settings file goes to $HOME/.local/share/. Configuration goes to $HOME/.config/. The actual documents (KiCad projects) go now to the home folder by default when starting from scratch, KiCad doesn’t suggest ~/.local/share/, i.e. XDG_DATA_DIR or KICAD_DOCUMENTS_HOME when a new project is created.
Short answer: I’m very happy with the applied changes.
I agree with eelik here:
Scripts and templates for some program should not be in the default directory for personal files.
I think FreeCAD also puts them in ~/.loca/share/freecad. I’ve never bothered to look where Libre Office puts such stuff, but I’ve never seen it creating visible directories in my home directory.
I can also understand the wish for making the location for user scripts & libraries easily accessible.
KiCad’s project manager already has a button (& menu entry) for opening the project location in a file browser. If an entry is added here to open the location to scripts and user libraries in a file browser, then that location is easy discoverable for new users and the forgetful.
Still one point about Windows. The Documents folder may be problematic because it’s possible or even probable that many users have already a folder named “kicad” in Documents which they have created themselves.
There would be another solution. Many applications create their own data folder directly under the user’s home folder. That folder isn’t directly used so often by the users, but it contains Desktop, Documents etc. I have many folders there created by cross-plaform programs, for example .gradle, .android, .atom. There’s even .vscode which isn’t cross-plaform AFAIK. And dot files aren’t hidden on Windows.
The histories of Windows and *nix folder structures are a bit different, I think the Documents folder was for “documents proper” or work documents on Windows from the beginning and those user created documents weren’t saved in application specific folders by default. The users weren’t offered the home folder by default when they saved their documents. On *nix systems the home folder was the default until the idea of Documents folder was copied from Windows (I suppose), and the files which weren’t work documents were saved in app specific dot directories and later in ~/.local/.
It’s easy to see there’s no one global standard solution, especially because the line between work documents and app specific data is blurred (plugins and scripts are like part of the app while KiCad libraries a more like work documents even though not identically).
Files are hidden in Windows by setting an attribute of the file so those cross platform programs could have availed themselves of this filesystem feature if they had wanted to. Anyway there is no need for the structure to be identical on all platforms.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.