Empty projects have empty extensions, so we shouldn't show anything in
this case and even if we get a bad extension, we should just log the
debug not a warning
Several entry points (macOS file open, file history, project tree) can pass
paths with extensions other than .kicad_pro to the project loading pipeline.
SETTINGS_MANAGER::LoadProject only normalized .pro to .kicad_pro, leaving
other extensions like .kicad_sch or .kicad_pcb to trigger the assertion in
PROJECT::setProjectFullName.
Broaden the extension normalization in SETTINGS_MANAGER::LoadProject to
handle any non-.kicad_pro extension, and replace the assertion in
PROJECT::setProjectFullName with a warning log and forced correction as
defense-in-depth.
Fixes KICAD-NZT
When pcbnew is started standalone (not via the project manager), the
PROJECT object exists but has no PROJECT_FILE (m_projectFile is null).
During background library enumeration, FOOTPRINT_LIBRARY_ADAPTER calls
getUri() which expands environment variables through TextVarResolver().
TextVarResolver() then calls GetTextVars() which dereferences the null
m_projectFile, causing a crash.
Guard TextVarResolver() against null m_projectFile by returning false
early, since there are no project text variables to resolve without a
project file.
Fixes https://gitlab.com/kicad/code/kicad/-/issues/22930
Previously, clicking Cancel on the "File is already open" dialog did
not prevent the project from opening because the lock check happened
in ProjectChanged() after the project was already loaded.
This change moves the lock check to LoadProject() before any loading
occurs, so Cancel actually aborts the operation.
Additionally, when user clicks "Open Anyway" at the project level, the
decision is now propagated to child editors (eeschema, pcbnew) via a
new IsLockOverrideGranted() flag on the PROJECT class. This prevents
showing redundant lock dialogs for individual schematic and PCB files
when the user has already made their decision at the project level.
Turns out project locks would get created and only stick around for a short duration as the default move constructor was letting the og object free the lock.
But if you crashed kicad or managed something weird, you can get a lock file with no override prompt which also creates confusion as some stuff gets set read only.
So lets just fix this up.
- Implement move constructor on lockfile so that the old object will no longer free the lockfile
- Move lock ownership to the project itself, just slightly less weird to handle for the lock override
- Implement the override lock prompt
Recommendation is to avoid using the year nomenclature as this
information is already encoded in the git repo. Avoids needing to
repeatly update.
Also updates AUTHORS.txt from current repo with contributor names
Also removes a bunch of std::string stuff from the file handling in the
simulator. All our file handling, env variable expansion, project path,
etc. stuff is wxString based, and jumping through std::string in between
just makes it more complex and increases the potential bug surface.
Also fixes a bug where you'd get two error messages when a spice model
library wasn't found.
Also fixes a bug where you'd get a spice model library not found error
when the text field was empty.
Also fixes a bug where we'd try to absolutize a path starting with an
unresolved text or environment variable. If the path starts with a
variable it's probably absolute, and tacking on the project path in the
error message just obfuscates things.
Fixes https://gitlab.com/kicad/code/kicad/issues/13082
wxWidgets 3.1 has deprecated wxPATH_NORM_ALL when normalizing file
paths when calling wxFileName::Normalize(). This change keeps the
existing behavior except in places where our own internal
ExpandEnvVarSubstitutions() to expand environment variables.
They don't define a KiCad string class, so the header file name was
somewhat misleading. But the fact that they didn't match definitely
made coding more difficult.
This was leaking windows headers and partial wx headers to 1084 compilation units......
This also means math/util.h is leaking to 1084 compilation units which seems a bit high too.
The use of printf, wxLogDebug, and std::err/std::out causes excessive
debugging output which makes finding specific debugging messages more
difficult than it needs to be.
There is still some debugging output in test code that really needs to
be moved into a unit test.
Add debugging output section to the coding policy regarding debugging
output.
Seth Hillbrand