Will the .sweet symbol library system be ready for v7 or this idea has been discarded?
I mean the idea of 1 symbol 1 file, 1 folder 1 library; parallel to .pretty footprints.
Just curious, the current symbol library manager works fine.
While I agree that installing plugins is not really straightforward, we’ve (on this forum) frequently advised users to install them in %APPDATA% folder. On Win platform there were only two locations supported (%APPDATA% and KiCad install folder most commonly found in %PROGRAMFILES%) where the other location was typically writable only for users with admin privileges. Therefore %APPDATA% folder is by my estimate used more commonly.
I obviously don’t have any insights into KiCad internals but I don’t see a reason why both paths (%APPDATA% and %USERPROFILE%) could not be supported concurrently.
Does that mean that the KiCad configuration files will also move location? If not, why the need for two folders with completely different root folder (%APPDATA% for config, %USERPROFILE% for plugins)? Doesn’t it make more sense to have everything in one place?
1 Like
%APPDATA% is accessible already regardless of “AppData” directory being hidden or not as it will open Roaming directory any way, it is also better to keep things in one place. Most programs use the Roaming directory as well.
“Documents” directory is the worst location a software could use for any files to be honest.
I really dislike this change.
1 Like
Please create a new topic for plugin path.
At the moment it accidentally supports both and I’m having a staring contest with the dragon sitting on top of that code there. So I’ll probably leave it.
Does that mean that the KiCad configuration files will also move location? If not, why the need for two folders with completely different root folder (%APPDATA% for config, %USERPROFILE% for plugins)? Doesn’t it make more sense to have everything in one place?
Config files should never need to be user accessible. %APPDATA% in corporate environments is replicated across workstations. It is often undesirable to store anything other than purely configuration in those folders as the profile storage can be highly space limited.
Most programs use the Roaming directory as well.
For configuration yes. Python scripts are not configuration. In fact, most programs per my above statement will use %LOCALAPPDATA% if they are trying to bypass IT admin restrictions and store programs and more as %LOCALAPPDATA% does not replicate.
We also do use %LOCALAPPDATA% already for this exact reason to store the 3d model cache which you definitely do not want replicating across workstations.
“Documents” directory is the worst location a software could use for any files to be honest.
Most programs use it. Even other CAD tools do like Altium.
Thanks for the time taken to enlighten me (or meybe us) what is behind the scenes. I really appreciate it.
While I understand elekgeek and I am of similar opinion, this is what the OS producer is pushing app suppliers to. So this is not really up to KiCad.
I’d just like to clear up something. Is the new search path
%LOCALAPPDATA% path (C:\Users{username}\AppData\Local\KiCad…
or
%USERPROFILE% path (C:Users{username}\KiCad…
or
%CSIDL_MYDOCUMENTS% path (C:Users{username}\Documents\KiCad…
as noted in your first post?
Kindly think of a solution that avoids “Documents” directory, you have already mentioned %LOCALAPPDATA%. The only valid “Documents” usage is for sample projects 
Since you brought Altium here, I use Altium at work, and I have no “Altium” directory in my “Documents” directory, I don’t see any Altium in your snapshot either. On the other hand, Altium uses “C:\ProgramData” for extensions, let’s say that KiCAD plugins (Python scripts) are extensions for Altium.
I agree with you that configuration files should not be touched, you are right about that.
Concerning replication across machines:
The admin can configure group policy to exclude" APPDATA" in the group policy: User Configuration -> Administrative Templates -> System -> User Profiles -> Exclude directories in roaming profile.
I have been there and I did it that way, what I am trying to say is that this is not a real argument on which a developer depends while taking a major action like this for KiCAD. Also, if Python scripts were to be replicated, this would be a good thing
1 Like
Current search paths are both
%APPDATA%\KiCad\<version>\scripting
%USERPROFILE%\Documents\KiCad\<version>
Depends on your install mode for altium. But on Windows C:\Users\All Users is a ntfs junction to C:\ProgramData. Altium is correctly using the folder for sharing things locally (non replicated) across other users of the same workstation.
Using group policy to disable roaming is the absolutely wrong thing to advocate for here.
I actually do have a desire to maybe use the “All Users” junction some but I have more fiddling to do. Reorganizing the path definitions to one file was step 1 instead of paths being created all over the codebase.
My stance is if the average user has to enable extra functions like “Show hidden files” or know the path from an external source to navigate to it via address bar, then it’s not the proper placement for a folder.
The average user is not a programmer, nor knows what %APPDATA% even means. Heck, the average user tends not to enable file extension display in Windows 10.
They just want to use buttons. v7 will hopefully introduce even better management options.
in most cases, reorganizing code takes more time and effort than adding new codes
I think we are on the same page, %LOCALAPPDATA%
Thank you for your efforts.
I wish a moderator moves this path discussion to a new thread.
IMO the current system is a bit complicated and not user friendly. It may be good to have some default locations, but an ordinary user doesn’t find information about them easily and may be confused if there are several of them, and the differences between platforms doesn’t make the situation easier – how many of us actually know what the paths are for each platform? And the user may want to put them somewhere else. IMO it should be configurable: the user should be able to give the search path (in addition to the hard coded ones).
Is there a logical break point? Which post?
I didn’t post about it but there are path changes to macOS and Linux as well. Each platform got a little more native. macOS will now use the “official” location for user app caches for the 3d model cache, it previously did not. Linux should more reliably pick the correct user cache as well as its being beaten out of gdk rather than us hoping the env variable is set. macOS and Linux will also use their Documents folder equivalents as well for a few things like Windows.
At the moment (compiled from master just now) new path does not work, only old path works.
In pcbnew Tools->External Plugins->Open Plugin Directory opens new path but plugins there are not scanned:
print(pcbnew.PLUGIN_DIRECTORIES_SEARCH)
D:\Microcontrollers\Kicad-dev-msvc\share\kicad\scripting
D:\Microcontrollers\Kicad-dev-msvc\share\kicad\scripting\plugins
C:\Users\user\AppData\Roaming\kicad\5.99\scripting
C:\Users\user\AppData\Roaming\kicad\5.99\scripting\plugins
In nightlies it’s a lot easier to find the right path. The menu item I mentioned above and also equivalent button in preferences->action plugins will lead you there. Once it’s fixed, that is.
That’s a great addition but opens only one directory.
What happens if one plugin (several versions) is in several directories? Which one is the authoritative one?
Suggestion: add all folders to the menu/button so that it opens a submenu, a menu item for each folder.
You should only ever use one directory, the one that is opened via that menu and not even care about existence of the rest. The rest are there for backwards compatibility.
There isn’t one authoritative directory, if you have plugin conflicts in different directories you will see errors in action plugin preferences and some plugins will not load.
Kind of proves my point:
Aye and we’ll fix it but not in v6.
2 Likes
Another change with paths is Documents\KiCad\<version>\<footprints> and Documents\Kicad\<version>\<symbols>\ are now default nudge paths to store “global libraries”. The library creation process was reordered so it asks Global or Project first and then defaults to said nudge path or the project (formerly always opened the project folder). You may still put libraries wherever you want of course. The intention is further smoothing the experience for new and average users.
Though I think I still need to MRU the path to make the power users happy. (which it didn’t do previously anyway)
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.