But it would certainly be a kindness in the software to be able to “Save Project As…” and have a complete copy saved in another location. This is a common function, so the argument that it should be an OS based operation feels a little thin.
You can vote here: https://bugs.launchpad.net/kicad/+bug/594051.
Maybe next year, after all, it’s 10 years old…
3 Likes
@eelik On the link page, there is no word like “vote”. Does adding a comment there mean a sort of voting? For instance, do I need to re-register to add a comment on that page or I can just re-log in as I do here (same username and password)?
Thank you.
There’s “This bug affects you” green text near top.
Unfortunately the forum and Launchpad are completely separate. The bug database (and the source code git server for development) are on Launchpad. You need Launchpad login.
3 Likes
So perhaps the best bet is to just copy the files to a new folder. I can see that working.
1 Like
I copy everything even my own symbols and footprints. I compress the entire folder and date it each level up as well
What would be nice is to be able to have a feature that copies the 3d print along with the PCB print into a folder.
Voted, I do this very frequently. I copy the project to a new folder, then rename the files appropriately. I’ve done it so often, I have gotten fairly quick at it.
there is a script to do it, but hierarchical projects may not work:
Save As has got to work reliably, so should be built in, not an add-on script
4 Likes
+1, but I was just suggesting an optional workaround…
As a third party function, there is always a risk that a KiCad update might break it and lead to corrupted projects. Archiving or forking a project really has to be formally tested as part of the release process to minimise expensive accidents.
v5 will not get new features. This means that a script will continue to work for all v5 releases and that the save as feature will not come for it.
Obviously I can only agree with you. That is why I have a test project packaged along with a plugin and when the plugin is ran as script it archives a project. This project can then be compared with the reference archived projects which have been manualy verified and also come with the plugin. Obviously I will have to automate also the compare procedure like I did with Replicate layout plugin and make it run independently of the library setup so that every user could run it.
Now this is years behind the formal verification but is the best that I can do. And even if somebody would want to do the formal verification I think it would be imposible since the tool needed for this (KiCad) hasn’t been formaly verified to my knowledge. But we might use different definitions of “formal verification”
As for the trust, with 5.1, archive 3D model functionality uses KiCad internal features to modify the .kicad_pcb file so I have high trust in this part. Archive schematis on the other hand is parsing the .sch and -cache.lib file by itslef so it is more likely to contain a bug or two.
2 Likes
There’s no guarantee that any internal part of KiCad is tested or verified after something else is changed. Sometimes there are surprisingly simple bugs somewhere which make me think that if even one developer had used that feature it would have been caught and fixed. Sometimes 3rd party plugin developers may do better.
There’s no formal testing plan or procedure for KiCad. They try to add automated testing but it works only up to some point. Ideally each feature which can be reached by the GUI would have a test plan and someone would test according to the plan every now and then, especially after major changes and before releases. That wouldn’t need developers, only a group of dedicated volunteers without any technical or programming experience. We can only dream about such a group.
Technically it would be possible to integrate script plugins into KiCad release. Someone should of course then be responsible about keeping it up to date, but it goes for other features, too. IMO this is one of the few upsides of compiled language - it forces at least some amount of keeping other parts up to date when something else is changed. But even that is very limited.
This kind of feature is isolated from the rest of the application. There should be no reason to reach internals of KiCad. There are no efficiency requirements. This is one of the many cases where it just makes no sense to use C++ and waste precious core developer resources. The only thing a KiCad plugin script can’t right now do is to integrate well to the rest of the UI.
Sadly in practice scripting is still a second class citizen in KiCad in many ways. If it wasn’t, the existing plugin could be integrated to KiCad releases as part of KiCad proper.
1 Like
I wouldn’t say that. Plugins can prevent bloat. In this case though I think Kicad needs to do more about making design segments portable across projects.
1 Like
I had exactly the same issue and started a thread on this very subject a couple iof years back.
I have come to the conclusion that version control is the best way round this.
Either an incredibly simply method where you zip up the info and store it with a version number at every PCB release, or, probably better, Mercurial/Git/svn/whatever is your preferred method of version control. They all work fine.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.