why would you want your project-specific libraries relative to your home directory (~ if that worked) and not relative to the project ($KIPRJMOD)?
1 Like
BTW, I have never understood why the name of that variable is KIPRJMOD. Maybe it has started with footprints (which were called modules in prehistoric aeons). It’s also difficult to remember and write. PROJECT_DIR would be better.
2 Likes
Yes, it was originally intended to be a variable to refer to project footprint libraries, and footprints were called modules. You could open a feature request to add a more logically-named alias variable that would do the same thing.
I understand your point very well, but even so: take this as a usability issue, most likely I won’t be the last user trying to use a ~ path and it works for some paths, but not for others, which makes pinpointing the problem harder. The issue could be solved by translating them to absolute paths when entered, but then again, why not just allow ~ paths work everywhere?
I find it a bit disturbing that there is so much energy spend in convincing me that I actually don’t want that (which may be true but not the point). Rather I would like to see the community reaction, like: Wow, that’s a weird thing to ask for but if it saves anyone from a little bit frustration lets just add this to the list of possible improvements and see if someone is willing to take it on. The whole environment variables thing is anyway super complex and in parts broken and convoluted and in the nightly version it’s in a constant flux. So one less thing to be able to do wrong is IMHO a good thing.
We generally try not to add OS-specific features to core functions like path resolving. The tilde-expansion feature of *nix shells isn’t something that works on the filesystem, so we’d have to implement our own mechanism to do it. This would be just one more place for bugs to appear and we’d have to test that our custom tilde expansion system did the same thing as the shell in all cases.
Other users have already described why referencing your project paths to your home directory may not be a good idea. I get why it is frustrating to hear people suggesting that the solution you are trying for may not be the best solution, but I also don’t blame people for trying to suggest things that may end up working better for you in the end.
That said, if you think that putting paths relative to your home directory rather than relative to the project root is best for you, I suggest using the $HOME variable.
2 Likes
I’m not opposed to having ~ support, though I would want it to immediately be replaced by the absolute path. That said it’s quite low on my personal list of priorities – there are many other kicad features that I would personally rather see implemented (given limited developer time).
I do think it’s not the right solution to your problem as described, and I think it’s a strong community that tries to solve each other’s problems in the best way possible.
The whole environment variables thing is anyway super complex and in parts broken and convoluted and in the nightly version it’s in a constant flux. So one less thing to be able to do wrong is IMHO a good thing.
I don’t think this is true? I’m not aware of any parts that are broken, but please report them if they are, otherwise they won’t get fixed. I’m also not aware of constant flux. There were new v6-specific environment variables added at one point, but that’s hardly constant flux.
So one less thing to be able to do wrong is IMHO a good thing.
I see this as an argument against home-directory-relative paths…
Valid question, but totally wrong forum.
You should ask this of the UNIX/POSIX/Linux community. Convince them that every program out there should accept ‘tilde’ as a path element (Good Luck with that).
It has nothing to do with KiCAD. And demanding ‘tilde’ for KiCAD file paths is just asking for trouble concerning portability and functionality. It’s a Shell shortcut for US users. (Most other keyboard layouts don’t even have ‘tilde’ as a separate key).
Different shells implement tilde expansion differently. Even different versions of the same shell often expand the tilde differently.
Which behavior would you want implemented?
Actually, KiCad has built-in tilde expansion functionality: https://gitlab.com/kicad/code/kicad/-/blob/master/common/common.cpp#L270-273.
This was probably added by mistake. I’ve submitted a patch to remove it.
Personally, I like having tilde expansion available. But I’m not advocating for it, because I don’t know if it’s a good idea to add it.
2 Likes
I use tilde often at the command line. I know it works at the open command in kate. I do think doing so would make it easier to use the program, kicad in this case. (this from a guy who only uses linux.)
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.