Normalize the KiCad files extensions

[Laurent Haas]

Relates to https://forum.kicad.info/t/project-file-extensions/11450/4

Normalize files extensions as kicad-* to prevent conflicts with other apps using the same extension (including the very common .pro, or .sch used by so many EDA programs but totally incompatible between them). Any file generated by KiCad with its own format should have a kicad-* extension.

It also reinforces the consistency of the software suite.

[Nick Østergaard (nickoe)]

Related to, but not exaclt duplicates of:
https://bugs.launchpad.net/kicad/+bug/1550518
https://bugs.launchpad.net/kicad/+bug/1500570

[Wayne Stambaugh (stambaughw)]

kicad_sch and kicad_sym file extensions will be introduced as part of the new schematic and symbol library file format work during the v6 development. However, legacy file formats will keep their original file extension. Changing them doesn't make sense. That leaves the project file extension (.prj) as the only remaining legacy file extension. I'm not sure if it make sense to change it if we are not going to change the file format itself.

[Laurent Haas (efcis)]

I just wanted to point out that .pro being a very common extension for any kind of development project file (software or hardware) in most users computers, the uniqueness of the extension makes the file association much easier to manage for the user. Today, if you double-click a .pro file, it will not necessarily start KiCad. It could also start an IDE or whatever. This is what this wish is mostly about.

[eelik (eelik)]

I agree with Laurent. It's very annoying when I have e.g. Qt SDK installed and I can open automatically only Qt or KiCad projects. If I erroneously try to open wrong one it's painful to wait the program to open and give some message about unrecognized file, then I have to close it manually.

There would be no problem if in KiCad 6 the default project file extension would be .kicad_pro when a new project is created. The then old v5 won't be able to use v6 projects anyways. V6 would still recognize the old .pro extension. I believe the code to achieve this would be simple, just recognize both .pro and .kicad_pro when opening but write .kicad_pro when creating new project. The user could even change the extension manually to .pro and the file would still be recognized.

[Ludwig (xennonflash)]

"kicad_sch and kicad_sym file extensions will be introduced as part of the new schematic and symbol library file format work during the v6 development. "
So why not just changing the pattern in the file chooser or make it configurable or at least as a #DEFINE in a header file (did not look at the code, but I will, as want to change it if you dont change the extensions ;-) ?
It is no rocket science at all to change a string constant in c code.

So why wait for the next release just do it, or have a nice define, or config option at compile time to change the endings.
So anyone who is anoyed by the extension .sch can just read a recipe and build the code with kicad_sch kicad_sym, kicad_pcb extensions and at least windows is pleased with it.

I know there is the file utilly that looks for file signatures, but only linux and un*x people use it :-)

Cheers,

xennonflash

[Wayne Stambaugh (stambaughw)]

@Ludwig, this would break the ability for KiCad to distinguish between opening the current schematic file format and new file format. We will forever have to load legacy KiCad .sch files so the short answer is no we are not going to change the file extension until the new file format is implemented. Is KiCad only other EDA besides Eagle to use .sch as the schematic file extension?

[Seth Hillbrand (sethh)]

Short answer: no.

https://en.wikipedia.org/wiki/.sch_(file_extension)

[Ludwig (xennonflash)]

@Wayne,

look you can use both endings.
Register kicad_sch with the windows explorer,
to fire up the program if one clicks on the file
with the ending.
Optionally register also sch with kicad, or eagle
as the user wants to.

And if you work with the schematics editor, just have a
save as dialog that asks for the ending desired. While when
saving the ending and file name is the same it was when the
file was opened.
The behaviour would be similar to libreoffice writer
working with a docx file.

I would need to have kicad_sch as ending for the schematics
and if nobody wants to make a dialog and proper handling for
the kicad_sch vs sch issue,
I will just change it by search and relace in the code
and publish a patch, when it works for me.
As I would not work with "sch" kicad-files, I would not need
the dialogs and just patch the tool for the future to suit my
needs.
And foreign designs I download from the internet would just get
their endings renamed beforehand, and I will be happy with my patched
kicad

Cheers,

Ludwig

[eelik (eelik)]

About the project file extension.

KiCad 5.1 won't be able to use 6.0 projects in any meaningful way. If the project file extension is kept it will be still possible to try to open (automatically by double clicking a .pro file) a 6.0 project with 5.1. That will only lead to confusion. So, is there any real logical reason why the .pro file extension should be kept instead of changing it consistently with other extensions to .kicad_pro? I don't think "no file format change" is a good enough reason, it's only formal, not practical.

[Jeff Young (jeyjey)]

@eelik, project files are just key/value dictionaries, so 5.1 will be able to use 6.0 project files (it just won't know about the 6.0 keys).

[Ludwig (xennonflash)]

As I said, it is the parser do decide and not a file ending.
Also having a version information of the file format in that file
significantly accelerates parsing as newer versions of a program can just
jump to the old browser or bend the funtion pointer of a stage2 parser that parses
the format for the version detected.
Renaming the file extension is only needed to have peace with windows and maybe
also MacOS (I dont have a mac as Apple denied warranty for my core2duo mac book pro
 where the display failed after only 16 Months - Apple sucks, so I never ever buy anything
from them).
Even some gnome based filemanagers in linux look at the ending, while there is the file tool
which tells you the file type based on magic numbers in the file (so file is a meta parser),
q.e.d. the parser is to decice

[Wayne Stambaugh (stambaughw)]

@Ludwig, we used to have a parser that attempted to determine the footprint library type and it was an unmitigated disaster. I have no intention of resurrecting this idea from the dead for schematic file formats. To reiterate Seth's comment, no. The new file format will get the new extension.
 The old file format will keep the current extension.

[Ludwig (xennonflash)]

So having no version info in a file is an antipattern.
If you have a version information you can just invoke the right parser, e.g. by calling or overloading as posted before.

" To reiterate Seth's comment, no. The new file format will get the new extension.
 The old file format will keep the current extension."

This is the advantage of open source, I can roll my own and fork it,
so people who think like me, could just use my patches and binaries I will provide, as I
can not work with eagle and kicad on the same windows machine, as explained above.
So I guess other windows users of small enterprises feel like me, and would prefer my patched
file extensions and the binaries generated, so they can have eagle and kicad in co-existance,
can bulk convert eagle designs into kicad designs and have a kicad that hopefully does not crash
all the time one tries to work with it.
BTW: I saw 5.1.1 tags in the code, when will there be a stable 5.1.1 release so I can build my changes against it?

Cheers,
Ludwig

[zahav (zahav)]

Hi all, its quite easy,

just change common/wildcards_and_files_ext.cpp
and change
const std::string ProjectFileExtension( "pro" );
const std::string SchematicFileExtension( "sch" );
to
const std::string ProjectFileExtension( "kicad_pro" );
const std::string SchematicFileExtension( "kicad_sch" );

you can change all your endings as you like but you should
keep in mind to rename the files properly.

have fun with it.

[eelik (eelik)]

@Jeff, I don't mean project file (currently .pro file) but the whole project. 5.1 can't use a *project* made with 6.0 (at least if it has a schematic). Therefore it's not very useful to open a 6.0 project file with 5.1. It would still be possible by manually renaming the file if someone wants to do that, provided that 6.0 recognizes both extensions.

What would be the reasons to try to open a 6.0 project file with 5.1? The only one which comes to my mind is importing board settings. It would still be possible by renaming or by simply adding to a 5.1 bugfix release the .kicad_pro file extention to the list of file extensions which can be opened by the import dialog.

Actually the file extension could be added even to KiCad main application which opens the project, but I don't see a reason to do that because, like I said, the project couldn't probably be used meaningfully.

BTW, what would happen if a 6.0 project would be opened with 5.1? Crash? Assert? Note about incompatible project?

[Jeff Young (jeyjey)]

@eelik, the new schematic files will have a kicad_sch extension, so 5.1 won't realize they're schematics and will think your project has no schematic. So yes, the project won't be terribly useful -- but the board could still be edited.

[eelik (eelik)]

The board file can be opened standalone anyways. Opening the project but not being able to recognize the schematic file would be confusing to users. And, to repeat what is already clear, users can rename the project file if they want to open the project. Or a bug fix release of 5.1 could recognize the new file extension if complete backward-compatibility is wanted.

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/2169