KiCad-Nightly over zealous folder creation

I discovered that recent versions of Kicad-nightly started to make a lot of sub directories on my system every time it is started:

I created an issue for this, and apparently it’s “normal” for windows & mac.

So I’m curious. What do you think about KiCad deciding where to put your projects. Do you want them in “…/kicad/5.99”, and then who knows where they end up when V6.0 is released?

Not too long ago I experimented a bit with custom templates, and I had to think of a location for these myself (and modify an environment variable). I can see some sense into having default locations for user “stuff”, but it should at least be configurable where that location is.

I can also live with (but do not prefer) KiCad making such directories upon install, but re-creating them each time KiCad-nigtly starts is tending towards madness for me.

So I’m just curious: What do you think about the best way to handle this?

It’s not for your projects, or for your settings. It’s for:

  • Libraries
  • Python scripts
  • Templates

(I am not sure why there is a projects dir created right now)

The reason it is versioned is that we want to be able to have people run multiple KiCad versions side-by-side without conflicts (for example, due to Python API changes, file format changes in the templates, and so on).

These kinds of things used to be installed in a location that was read-only to Linux users without using sudo. We want to fix that as it’s not very user-friendly.

The directory needs to exist, which is why it’s created if missing. But, we can make it configurable via an env variable as I mentioned in the issue.

An environment variable would be just fine for me.
Putting it ~/.config/kicad/… would also be just fine with me.
[Edit] I find the border between configuration stuff and user provided general stuff (libraries / scripts) always a bit vague.

Almost anything except my own home folder.
I made the topic here because somebody may come up with a better idea to do this.

KiCadnightly also made a similar sub folders (“3d”, “scripting”, “plugins” in the config folder:

We don’t want to put it there because it’s not configuration.

Other opinions welcome

Putting this kind of stuff in ~/.{PROGRAMNAME}/ is pretty common…


Just had a look and I have 23 such:


FWIW, Long ago I setup my Kicad (Windows) to have the Kicad libraries elsewhere and my projects and “personal” libraries in a folder under “my documents”

Now I only download the Lite version, keeping my libraries from changing with each installation.


~/.kicad/<version> would be the other obvious choice. We didn’t do this at the start because this directory will need to be accessed by any user who wants to do things like install Python scripts, modify templates, libraries, etc. So, since dotfiles/folders are hidden by default in most Linux file managers, it’s a bit of extra work.

Ultimately, even if we add an env variable to allow users to customize this, the default behavior will come down to this decision between user-friendlyness (a visible folder) and “hardcore Linux user respect” (a dot folder)

Why not put it in the ‘proper’ place and do a symbolic link?

What, in your opinion, is the ‘proper’ place, and what symbolic link do you suggest specifically?

Just from your post.

The visible folder would be a sym link to the ~/.kicad
I could argue this both ways. I go back far enough with computers that I remember when you had at least some vague idea what every damned file on your computer was. Keeping stuff together in one directory sure is easy on the user. Keeping certain stuff separated sure is easy on the system admin.

Another possibility for user friendliness might be a menu item to spawn a file explorer window on the directory. I know I’ve done a number of google searches to discover where I need to put plugins.

This is already in nightly (specifically for plugins).

dotfiles and dotdirectories are actually due to a bug in ls back in the day

in wanting to hide ./ and …/ from ls the result was any file begining with a dot was hidden. this became a “feature” that has been exploited

The FHS does not cover specifics of what is in /home, just that /home is needed.
The FSF specification, especially that pertaining to XDG does.

So settings should go into ~/.config/ package / and runtime data into $XDG_RUNTIME_DIR / package but other things? plugins, libraries etc…

it should either go into ~/.config/ package / or into ~/Documents/package

And we do ~/Documents/*package* according to the spec. The problem is that not all Linux distros follow this convention (some don’t set the XDG configuration indicating where the Documents directory is, some don’t even create a Documents directory like in Paul’s case). So, we need some kind of fallback, which is currently just using the home directory.

I would prefer not having lots of options, fallbacks, etc. It would be much better if we just pick one option that is the best mixture of not annoying people and being useful to people.

Right now I’m inclined to think this would be to go with ~/.kicad/ since we cannot rely on ~/Documents existing, and adding a button in the UI somewhere to launch this folder would be easy and helpful.


You that seems a sensible and also justifiable approach

Interesting that blog is of a *nix hater. Also the first time I’ve seen dotdirectory although its meaning is clear. It’s not usually needed because directories are also files in the *nix sense, that is, a file is an object in the *nix filesystem and has a path. Otherwise we might have to also create the terms dotnamedpipe, dotdevice, etc, etc. :wink:

But it’s too late to avoid dotfiles now and there is enough precedent in lots of other programs to support ~/.kicad

I do not like ~/.kicad much.
It is a common (and old) convention but it has grown into far to many files in the main user directory.

Electro707 posted a much better location on gitlab:


It is also an existing location. I have “stuff” there for around 25 different programs, including greecad, meld, jupyter, codeblocks, vlc.

The preferable folders for such things are defined the XDG Base Directory Specification as Naib has already posted.
The usage of some dot folder within $(HOME)/ is discouraged.

That’s not a bad idea. Make sure that $XDG_DATA_HOME overrides it.