KiCad nightly (v5.99): New schematic and symbol library file formats are now the default

Possibly, but doubtful. The are a lot of higher priorities for V6 so most likely this wont happen until V7 development.

2 Likes

@stambaughw Thanks for your answer, it makes sense that inheritance should only by on the library side. Can I actually create a part with this syntax and be able to open it in the Library Editor at this time?

I am sorry for the hostname… I just modified the middle section of the file, making it obvious I did it by hand. I did not know it had so much importance.

Thanks for your answer, Wayne.

@eeintech You can define symbol libraries with the “extends” keyword and open them in the symbol library editor assuming you haven’t broken anything.

The host name is only important if you file a bug report. This way the development team knows that your file wasn’t created by KiCad and we don’t waste time looking at the formatter code for bugs that do not exist.

@stambaughw
Is the sheet template not stored in the schematic file?

What do you mean by “sheet template”?

@eelik
I mean the titleblock, the frame in the schematic, worksheet template.
I hope it is clear what I mean.

That’s what was referred to earlier:

The worksheet template is an independent file now. The default one is somewhere in the KiCad installation, you can make your own.

Not yet. See discussion above :wink:

Oops. Sorry I should have read the whole threat, before posting. :man_facepalming:

but @hildogjr talking about MIRROR - it should not take much work :slight_smile:

Other way you can do about this is hash the whole file with your “none-public” hard code value/key from the kicad source code itself. This will make it harder the people to fake it, instead of just a hard fix value “Eeschema”. You can use any type of hash MD5, SHA1 … it not that importance, but good enough.

What would the benefit of a mirror be?
Having something on gitlab really only benefits users if they can use gitlab to make issues or pull requests. However, these are the features we would need to remove from the mirror (which i doubt is part of gitlabs feature set).

The core git feature set would be all that remains but git really does not care where you have the remote. You don’t even need an account for read access to the github repo. And a mirror would by definition also always be read only so …

I bet you right. Only benefit I see is: get more visibility to more people, and in cast a failure on one side, other should be fine. I mean failure like company shutdown (which rare).

Does this mean that, to properly print a random hierarchical schematic sheet in a project, i would need to find the root file project and “back-annotate” with the data found in it?

For complex hierarchies, yes. For simple hierarchies, no.

Asking from a user perspective, what is the current development state of the new file format? Any pending changes?
I would like to start creating my libraries to use on the future release, how safe is to start doing it with current development branch?

@kammutierspule Not unless a change is required to fix a bug. The file format is frozen until V7 development begins.

1 Like

@mgyger The documentation is going to be the last thing I finish up before V6 release so it’s lagging a bit behind and the moment. It will most likely go in the developer documentation but that still hasn’t been finalized yet.

2 Likes