Define “better” please. Are you planning to spend considerable time with a text editor movig thing around in text directly? If so, why not approach this with python?
Because even if I use Python I have to do significant parsing of non-mnemonic, weakly delimited fields on the schematic format.
One of the huge advantages of the s-expression format is the sheer number of tools available to manipulate it even by hand. But, any format which editors can manipulate or have plugins to manipulate is fine.
While I would love for all the features I want to be in KiCad directly, I’m finding that I have to drop into the file formats at least 2 or 3 times a project. And, you know what … I don’t mind that. Too many “professional” PCB systems have a lot of half-baked features that wouldn’t be necessary if the file format was at least documented (which KiCAD’s sort of is … I’m not finding mentions of AR fields in the Schematic Format description though …)
However, if I have to manipulate with tools, then I’d like to put my vote in for a format that makes that easier.
(EDIT: I read the title of the thread again; at first I though you meant changing the file format for 5.1, before the new really new file format is implemented for v6.)
No. That’s a deliberate decision by the core developers. When thinking about the whole project, the work involved, the needs and no-needs of all users etc. it doesn’t make any sense to change the old file format just before the new one. Wayne (the project leader) hopes to get the new file format into 5.99 this year. We can hope that v6 will be released within a year. In any case the new file format is the main point of the v6 release. Touching the old file format would be wasted work and would just delay v6.
When writing this I assumed you already knew that v6 will have a new s-expression based file format.
Coming S format will be same for schematic and pcb and both use a parser written by Dick Hollenbeck in both directions for read and write. That parser intentionally uses some tricky exceptional cases to drop some single characters although there is no need to save such small amount of disk memory. Also dont like this. Possibly there should be an py interface to that parser to raise the level of abstraction for external py tools. Some time ago I started to draw EBNF what only exists of a very few parts of the file contents. Doing so for all contents, you will find many good ideas for the file format. One of them is to have a S-format property file what is the libraries top level instance to allow external tools to introduce their own contents. If there is nobody doing all the BNF specs there is less than ever anybody who writes the code therefore. This way it will probably last some more incompatible versions to reach a desired level to represent the electronics.
Could you give some examples. I am just curious.
I am designing simple PCBs and (with one exception) I have never need to look into the files.
The exception was in times (around 1987) when Orcad was only schematic editor, and Racal-Redacs schematic editor was worse than Orcad. I have written the simple program to convert Orcad exported netlist to Racal-Redac netlist.
This is not a very nice way to open a post, especially when it turns out to be solely based on your own ignorance. It was part of the reason I ignored this thread. Also because it was not clear of which version of KiCad you were complaining about.
No, won’t happen. Mayor changes in KiCad will be reflected in changes in Mayor version numbers. That is what those numbers are for.
All hail to the wonderful KiCad Developers, who have adopted an ugly and broken duckling and have turned it into what it is now. A wonderful and very usable EDA package which is even starting to get the attention of the big $$$ companies and making them shudder on their foundations.
I have never heared about Racal Cadet.
Those were old times. Here in Poland absolutely different. Typical engineer here earned about $13…$20 per month! those time. We used programs not buying them and most of us didn’t understand that it is illegal. That Racal-Redac I had was at 4 floppy disks 360kB each (really about 3.5 ot them was used). I have managed to run it at PC with 640kB RAM and without HDD. To do that I had to use 80kB of RAM to set up a RAM Disk. Using that Racal-Redac I designed only one PCB about 12x25cm.
Sure, I needed to align about 25 PCB designators on a grid. Easy to do in my editor.
I needed to change the size of all the vias. Simply search and destroy in the PCB format.
Now lets look at what the schematic format makes difficult. Designators, for example.
Let’s take renumbering designators. That feature is coming in 6.0, but is not in 5.X. No big deal.
On the PCB side, no big deal. (fp_text reference U10 … ) is canonical and unique.
Unfortunately, if you have a concrete “U10” in a schematic, it can land in at least 3 places. An L field, an AR field, and the actual canonical F field. If you don’t get all of those updated, the schematic editor gets confused. The format being not S-expressions isn’t the problem, the fact that “U10” isn’t in a SINGLE canonical field and the others aren’t references to the canonical field is the problem.
(Now, you can ask why I didn’t use RenumKiCadPCB. I pulled RenumKiCadPCB, saw that it was 2016, worried and bit but compiled it. Saw that it mangled my paths. Opened it up in an editor: saw file paths being manipulated by strlen() as strings and realized that fixing that problem was going to be longer than writing my own Python script.
If there is a newer RenumKiCadPCB that I somehow missed, please point me to it. My release notes say V0.103. I’m happy to not reinvent the wheel whenever possible.)
There is quite an art to asking questions in a productive way. I
Eric Steven Raymond has written (and maintains) a quite in depth article about it for some 20 years. It’s quite an eye opener in the way “human brains” tend to take shortcuts without you even being aware of it. http://www.catb.org/~esr/faqs/smart-questions.html