Project Rename and Save As

Bug #594051 reported by cfdev
This bug affects 35 people
Affects Status Importance Assigned to Milestone
Fix Committed
Jeff Young

Bug Description


it's possible to have in Kicad "Save the project and files as".

this fonction will create an copy of the actual project and files, to an other name.




Stephen Eaton (seaton)
Changed in kicad:
status: New → Triaged
Revision history for this message
eelik (eelik) wrote :
reveals quite many questions about renaming a project (which "Save As..." would effectively do) and other related problems. IMO it should be a standard feature.

Revision history for this message
Jeff Young (jeyjey) wrote :

From a comment (courtesy of Thomas Pointhuber) in the duplicate:


summary: - Save the project as
+ Project Rename and Save As
Revision history for this message
Franck78 (fbourdonnec) wrote :


V?, 2010 : Triaged

V5, 2018 : Nothing

When Kicad was an advanced toy, it was acceptable.

If it is not a real "Save as" function, pretty sure half the code is done inside "New Project->From Template".

So, coding "New Project->From Project" cannot be an overwhelming task isn't ....?

Revision history for this message
Seth Hillbrand (sethh) wrote :

Hi Franck- Please feel free to hit the "This affects me too" button up top. Features generally don't get higher attention due to comments such as these.

Revision history for this message
Franck78 (fbourdonnec) wrote :

Teardrop, #593972 , opened 10 years ago. 44 affected peoples, hottest score.
Not even assigned.
As this one.

Surely the best way to report something indefinitely, every dev thinking "oh, x will take care of it".
It is not a level of difficulty either. Teardrop might be tricky. "Save as" is just boring user interface to code.

#1498017, Wayne says "hold on, I'm refactoring (2015) blah blah". Sure the refactoring is done (2018), no ?

Lack of management, sorry.

Revision history for this message
Maciej Suminski (orsonmmz) wrote :


There is a matter of priorities and our man power. I realize that project renaming might be the biggest issue to you, but someone else cannot use the accelerated canvas and this is his most significant problem. Now we need to decide what to fix: either solve a problem that cannot be workarounded by a user (problems with accelerated canvas) or develop code to rename files, that everyone can easily do without KiCad help. Which one should we pick and fix?

There are just a few developers regularly contributing to KiCad, and hundreds of problems to solve. Every day we receive at least a few bug reports, many of them feature requests. Please be patient, we do our best to support and develop KiCad, but we are unable to solve all problems at once. We will happily accept a patch that fixes this issue.

Revision history for this message
Franck78 (fbourdonnec) wrote :

I know all of that ;-)
And you can't get a patch for this from any dev.
It's a small thing to do, but

-need to install/learn/discover wxwidgets
-need to understand inside Kicad, where do I hook my code, link this as you do
-then the real work, what is to rename, I will probably miss things
-then the integration. You came 6 months after, "oh this is not the way to do, please retry"

For a Kicad dev, it's matter of one hour. Modify the menu, tweak a dialog box, write the function at the correct place, thinking to filenames but also inside them, testing, done.

So, forget all patches involving UI modifications. It's boring, not Kicad specific. Need translations, need documentation. You don't want more than two of three devs for that.
But it is important to do because it is the first thing a new user sees (and keep/throw away Kicad).

You want a patch Maciej ? I can try #1787499. Just point me to the code that draws the footprint.

Revision history for this message
Seth Hillbrand (sethh) wrote :


Please try to keep your interactions civil. Remember that we're all here donating our time to help give you this free thing that you use and make it better.

On the heat, you can certainly find a number of high-heat wishlist items that have not yet been implemented. This is because the selection is binomial. The longer a wishlist item stays open, the higher its heat tends, so be definition, if you look at the highest heat item, it will usually be a really old, difficult item.

However, the point was that jumping into the comment to complain that the feature hasn't been implemented doesn't help. The reason is that when I'm looking for wishlist items to address, I (and possibly other devs) will sort the very long list by heat to see what affects the most number of people and see if I can dedicate the time to address the issue. I don't see the complaint at the bottom about how we have poor management.

Revision history for this message
Nick Østergaard (nickoe) wrote :

@Franck78, please avoid being hostile. It is not productive. Who is going to pay for that hour? No one is going to make it if they don't _feel_ they need to do it, as this is a project driven by volunteers.

Revision history for this message
Michael Kavanagh (michaelkavanagh) wrote :

I know we're in the feature/string freeze, but for future reference...
Tested ok on macOS:

Application: kicad
Version: (5.1.0-rc2-38-g4612175da-dirty), release build
    wxWidgets 3.0.4
    libcurl/7.54.0 LibreSSL/2.6.4 zlib/1.2.11 nghttp2/1.24.1
Platform: Mac OS X (Darwin 18.2.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
    wxWidgets: 3.0.4 (UTF-8,STL containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.54.0
    Compiler: Clang 10.0.0 with C++ ABI 1002

Build settings:

Revision history for this message
Rene Poeschl (poeschlr) wrote :

Does your patch take proper care of handling the cache and rescue libs? (I suspect template projects on which you seem to base your patch might not really be expected to have these files.)

Revision history for this message
Michael Kavanagh (michaelkavanagh) wrote :

@Rene, no because I think that is a separate bug, see lp:1785882 [1]. This is actually already broken in the template system, see the "raspberrypi_hat" template. It contains a symbol library named after the project. When the template is created the .lib/.dcm names are changed but the corresponding entry in the sym-lib-table file is not updated.

This patch is for a starting point/feedback when the v6 merge window opens. I just noticed I made some boneheaded style guide errors with regards to my variable/argument naming.


Revision history for this message
Rene Poeschl (poeschlr) wrote :

For templates it might be a separate bug. A new feature should really not introduce one from the beginning to be honest.

And the cache and rescue libs are not just some libs. They really have to be considered part of the schematic file. (Without these two files a project is unusable as it then depends on the global libraries installed not being changed.)

Revision history for this message
Rene Poeschl (poeschlr) wrote :

Maybe a clarification: Your patch would need to ensure that these two files are copied and renamed accordingly. It would also need to update the new symbol lib table to include the new rescue lib under the correct name.

And you would need to go through the schematic file to update all references to the rescue lib. (A hacky fix would be to simply add the rescue lib under its original name to the project local symbol library table. I would however doubt that something like that would be acceptable.)

And a disclaimer: I am not one of the devs but only part of the library team. (And therefore a bit of a heavy user of kicad.)

Revision history for this message
jean-pierre charras (jp-charras) wrote :

Rene is right: if you want to rename the project file, many other files need renaming.
Not only libraries, but also gerber and drill files (including references in .gbrjob file)
and perhaps some other files (report files, bom files, position files ...).

Renaming project files is really tricky.

My opinion is trying to renaming files is useless.
Why to rename them? what is the actual purpose?
Copying these files to a new folder is enough to duplicate a project.
No need to rename files inside the new folder.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

@Rene, you are correct. What you listed is exactly would would have to happen in order to ensure the schematic is not broken. I could live with the hacky fix but I would prefer that the rescue library be renamed to the project name and all internal references in the schematic to the rescue library be updated accordingly.

Revision history for this message
Rene Poeschl (poeschlr) wrote :


Renaming is useful as part of reusing a project.

And to be honest a save as option is simply expected by users at this point in time. I do not know of any other program that does not offer this. (I am aware that it is hard to implement and you could argue it has low priority. I however object to the notion that this is not useful and should therefore not be implemented.)

Revision history for this message
eelik (eelik) wrote :

I understand that it's extremely difficult, if not impossible, to rename everything, especially inside the files, because there may be any kind of random files added to the project folder. Even generated gerbers can be in any subdirectory and have different file endings etc. and the files exported by KiCad may have been renamed by the user - and the output files may be pdf which then have the old project name inside them.

I suggest some kind of compromise. By default copy and rename all required files: schematic, layout, libraries. The project name inside these files should be changed, too, where necessary. That wouldn't be overly complicated especially when there's no more symbol cache in v6.

Add checkbox "Copy unknown and generated files" and under that, if it's selected, "Rename files". The user would be responsible for anything else. Maybe add a warning that the files may include the wrong project name. (They certainly do if e.g. generated gerbers or schematic pdf have the name in the page settings, and often even the layout itself has the project name in silk screen.)

Case sensitiveness is probably problematic - it's not unusual to have project name in CamelCase but still have some fully lowercase file names or vice versa.

Revision history for this message
Paul van der hoeven (paulvdh) wrote :

So I've got a demo project, called "LoPower2".
A grep in the project folder gives me the pasted text below the cut line.

The project name appears inside the files:

I just happen to have a fancy IDE that can search for and replace text strings in a directory (sub) tree. How far would doing such a replace together with renaming the project files get me?

Unlike Eelik, I'm not concerned with Gerbers and other auto generated files. I save Gerbers only for projects for which PCB's have been ordered, and thus they are of no concern in the copy to a new project.

A little search seems to give some interesting results:"rename+a+KiCad+project"
(I have not tried any of them).

This subject seems to popup a lot on the user forum lately.
Another user posted it seemed to popup "every few weeks" recently.

----- 8<-------- 8<-------- 8<-------- 8<-------- 8<-------- 8<-------- 8<---
paul@dualcore:~/projects/kicad/zzz_prut/LoPower2$ grep -in "LoPower2" *
fp-lib-table:2: (lib (name LoPower2)(type KiCad)(uri ${KIPRJMOD}/LoPower2.pretty)(options "")(descr ""))
grep: gerbers: Is a directory
LoPower2-cache.lib:238:# LoPower2-rescue_ATmega328P-PU-atmega48pv-10pu
LoPower2-cache.lib:240:DEF LoPower2-rescue_ATmega328P-PU-atmega48pv-10pu U1 0 20 Y Y 1 F N
LoPower2-cache.lib:242:F1 "LoPower2-rescue_ATmega328P-PU-atmega48pv-10pu" 100 -1450 50 H V L TNN
LoPower2.kicad_pcb:384: (module LoPower2:nRF24L01 (layer F.Cu) (tedit 5C693BA3) (tstamp 5C8F3797)
LoPower2.kicad_pcb:763: (module LoPower2:SW_PUSH_L6mm_W3.5mm_H5mm (layer F.Cu) (tedit 5C6948FA) (tstamp 5C7BC447)
grep: LoPower2.pretty: Is a directory
LoPower2.sch:18:L LoPower2-rescue:ATmega328P-PU-atmega48pv-10pu U1
LoPower2.sch:34:F 2 "LoPower2:nRF24L01" H 9150 4200 50 0001 L CIN
LoPower2.sch:69:F 2 "LoPower2:SW_PUSH_L6mm_W3.5mm_H5mm" H 3500 4100 50 0001 C CNN
sym-lib-table:2: (lib (name LoPower2-rescue)(type Legacy)(uri ${KIPRJMOD}/LoPower2-rescue.lib)(options "")(descr ""))

Revision history for this message
Paul van der hoeven (paulvdh) wrote :

Follow up:
So I had a look through BobC's and it seemed to only handle the filename stuff, without modifying anything in the files themself.

After that I did a test run and copied the project with the python script.
It indeed only copies & renames the project, and a diff of the .sch and .kicad_pcb confirms that the strings in the files have not been touched / updated.
When opening the project in KiCad / Eeschema the first thing that pops up is the rescue helper.

--- 8<------ 8<------ 8<------ 8<------ 8<------ 8<---
paul@dualcore:~/projects/kicad/zzz_prut/LoPower2_copy$ python ~/bin/ -d ../LoPower3 -n LoPower4
project name: LoPower2
new project name: LoPower4

Revision history for this message
Kent Noonan (kentn) wrote :

I have investigated this issue several times in the past 2 years, and find it to be a show stopper.
It should not be difficult, it should be amazingly easy, to create a new revision from an existing design. It needs to be a flawless copy made effortlessly, and include all of the information I have worked so hard to get in there, like the BOM and 3d files.
This bug is the reason I don't use Kicad every day. I have other old software that I can't wait to jettison for Kicad, but still use because it is easy to make new designs from old designs, and I know how to use it.
I'm not just ranting here. I do most of my work on production designs. Much of my work is making new revisions from old stuff. Much depends on getting the changes right, big dollars depend on it.
So if I need to simply move a trace or add a new part, the last thing I want is to introduce errors from some silly file translation.
Revision control in a production environment requires that you are certain you know what changed.
If I can't "Save as" prior revision plus 1, then add the simple change, then I can't be certain that I know everything that changes.
I don't want a workaround that sometimes works. I don't want an add-on utility. I don't want to copy a directory and change filenames and 3d file locations. I don't care how hard it is to fix the problem in Kicad or how we got here.
I just want to move that trace with no surprises.

Jeff Young (jeyjey)
Changed in kicad:
milestone: none → 6.0.0-rc1
assignee: nobody → Jeff Young (jeyjey)
status: Triaged → In Progress
Revision history for this message
KiCad Janitor (kicad-janitor) wrote :

Fixed in revision b5904b040119f237b3e5d1a630ae4aff36824867

Changed in kicad:
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.