There’s no point being dogmatic about XDG “standards” or trying to reform the world. Just listing your home directory will show that dotdirectories are the real world standard used by many software packages far more widespread and successful than kicad.
Yeah sure, people also used to drive to their work on a horse.
1 Like
you’re wasting everyone’s time with this dumb topic. and your “solution” is like insisting everyone must find a zebra to ride to work instead.
pretty sure it is our time to waste and our decision to reply, if we want to.
The point of standards are consistency… The developers have already expressed a perspective that they don’t want to deal with platform exception cases and this is an EXTREMELY valid concern as it keeps the codebase manageable insteads of case/if-else tree’s …
There is then the perspective of users that jump between platforms and having a common location helps.
Then there is the perspective of new users coming to linux and using it for the 1st time. dot-files can be annoying if you are not aware of them and there are plenty of threads here where people could not find where to put plugins
Then there is the perspective of consistency… some over-arching “standard” to ensure that something running on one distro is consistent to another. THIS is what the FSF is trying todo and the XDG is the best we have
I have no preference for any particular directory, but I would like KiCad and other programs to take a command line option to print information about where it stores its key files, among other information. Too many programs don’t give such information, not even mentioning them in the man page, as was the Unix custom. Then I have to check the usual suspect directories, or look at the list of files installed by the package or use some other roundabout method.
For example, when a newcomer posts that KiCad cannot find their Python script, wouldn’t it be nice to tell them to run kicad --print-config and then they can see which directories it’s expecting to find the script in? And so forth.
In fact KiCad 5 does very little with command line input. This may be due to it being a GUI program on multipe platforms. I hope 6 makes better use of command line options.
That’s pretty contradictory to cross-platform consistency.
Picking some DOA FSF initiative against real world practice is choosing philosophy over practicality.
No it is not especially as the XDG is Linux specific to recommend consistency across applications and distros
Windows has a platform specific guideline (https://docs.microsoft.com/en-us/dotnet/api/system.environment.specialfolder?view=net-5.0)
Please don’t be so obtuse, it’s obvious Linux couldn’t store it in C:\Users%USERNAME% as that isn’t valid. Same with Mac. But you can be consistent for the platform you are on. Likewise certain distros (eg fedora) are specific about apps doing the consistent thing
Windows, Mac, and Ubuntu all have ~/Desktop and ~/Documents…
If you don’t try to cater to every ridiculous linux variant, things get a lot easier.
As an aside, nobody should care about distro policies, distribute KiCAD as an appimage or just a download.
and now you are being even more obtuse… any application that started spamming a users DESKTOP would be very quickly uninstalled
OSX,Windows,Linux also has ~\Documents which shock horror is the recommended location and equally exactly what the devs are doing…
1 Like
So why does it create ~/kicad/5.99/ instead of ~/Documents/kicad/5.99/?
This whole thread could have been avoided.
It does create ~/Documents/kicad/5.99 … It falls back to ~/ as a backup AS has already been pointed out
file ~/Documents/kicad/5.99/
/home/naib/Documents/kicad/5.99/: directory
naib@desktop ~/ $ rm ~/Documents/kicad/5.99 -rf
naib@desktop ~/ $ file ~/Documents/kicad/5.99/
/home/naib/Documents/kicad/5.99/: cannot open `/home/naib/Documents/kicad/5.99/' (No such file or directory)
naib@desktop ~/ $ kicad &
[1] 8361
naib@desktop ~/ $ file ~/Documents/kicad/5.99/
/home/naib/Documents/kicad/5.99/: directory
naib@desktop ~/ $ file ~/kicad
/home/naib/kicad: cannot open `/home/naib/kicad' (No such file or directory)
A spec/convention is only as good as that which is followed. OSX is dogmatic, windows less so while linux is more like a gentlemans agreement and implementation inertia becomes the defacto standard. so what should kicad or applications do? blindly assume XDG is set? this causes obscure bugs like a recent one I ran into with Pipewire (as it was assuming a systemd setup not a openRC+AwesomeWM) or should KiCad have a failsafe fallback… personally a failsafe fallback is advisable because EVEN on a Fedora/Ubuntu/### where ~/Documents are created as part of skel, the user could delete them
First: I don’t have a “Documents”.
Second: my KiCad stuff is listed under “projects”.
Third: I’ve seen several screenshots on this forum of various locations where users put their KiCad projects. (I know, this is not supposed to be for “projects”).
Fourth: People are just too different. Some put their KiCad stuff in git, others use other systems to collaborate within a group and share scripts, libraries, and other metadata.
Fifth: Hard coded paths for things like this are just a bad idea. Yet another reason to make this configurable in a decent way.
Those appimages, flatpack and other containers are *&^%$#@! Far too often developers using them get lazy and ship their software with old versions of libraries which are a security hazard.
Then there is the mess with updating them.
If you install a program properly under Linux. It gets updated automatically with the OS itself and all other programs.
Or it rots unupdated for years since distro packaging process is such a nightmare.
This model depends on the distro caring about the dependencies you need and everyone in that chain executing their jobs correctly and promptly. The fact that people don’t even use this approach on windows with their huge amount of paid developers and incessant OS updates should demonstrate why it’s a silly path for FOSS. Even Apple hasn’t been able to completely force all distribution/updates to flow through their walled garden.
This is funny, because one of the main benefits to using FlatPak with KiCad is that you get updated libraries, which are impossible to get on Linux otherwise because no distro is providing wxWidgets 3.1 builds that I am aware of.
~/.local is intended as a user-specific extension of /usr/local, that is, a place to stick application resources. In this case, we are not talking about application resources, we are talking about user data such as custom templates, python scripts, etc. As far as I can tell, using ~/.kicad would better follow the convention of applications that deal with custom user data than ~/.local
2 Likes
Part of the complication is wxWidgets-3.1 is technically a development version so no distro will mainline this. However… wxWidgets-3.2 is just around the corner
https://trac.wxwidgets.org/wiki/Roadmap
New development happens on 3.1 branch. The latest version is 3.1.4, released on July 22, 2020 and we plan to release one last 3.1.5 release in 3.1.x series in the beginning of 2021 with 3.2.0 hopefully following soon after.
One of the big planned changes for this 3.2 is better support for high DPI displays, but there are, of course, many, many other fixes and improvements in it as well.
3.2 will also finally drop support for very old legacy systems (such as Win9x platform) and compilers (MSVC6, maybe MSVC7 as well).
Problem is distros like Debian will be stuck on wx 3.0 for even longer with all the fun bugs inside <.<
Well since kicad is now targeting py39 it means the only version of debian that kicad will work on is the yet to be released Bullseye (or sid if that’s your poison 
) , so there are other problems
Kicad does no such thing, py39 just happens to be shipped with recent windows builds. AFAIK all of kicad’s python stuff works on both py2 and 3.
It’s technically a development verision, but it has release cycles just like the stable version, and in our experience has no meaningful regressions or instability. I’m sure there are things out there that I have missed, but in general wx 3.1 provides hundreds of bug fixes over 3.0 that cannot be addressed through KiCad workarounds. So, I for one am happy that we now have a fully-maintained FlatPak build so that Linux users can choose to use the latest wx libraries just like we use on Windows and Mac.