Is there any easy to follow documentation for creating a new plugin, specifically for the symbol editor? (I am a noob)
When doing a simple search for: “kicad plugin tutorial”
The first two links that popped up were:
And another approach is of course to look closely at an existing plugin and look what’s in it. Starting with a plugin that is somewhat similar to what you want to do is a plus, but looking at a plugin that has a high code quality and is written properly is probably a much bigger plus. Ideally you have both…
KiCad doesn’t have a plugin API for the schematic part or symbols, only for the PCB part (which works only in the PCB editor proper, not in the footprint editor, if used from inside KiCad).
thank you. that settles it
Regarding to publish a plugin to the Plugin Manager, looking at the official documentation and comparing it to some existing plugins it’s not entirely clear to me how many metadata files have to be provided and what are the mandatory parameters in them… my guess is:
1 metadata.json in the package itself, without download_* parameters specified
1 metadata.json published to the official plugins gitlab repo, this one including all the downloads_* parameters
as a side note, I’m not finding the whole publishing process that straight forward… think I might be getting something wrong in the whole workflow
You are exactly right.
The docs for publishing plugin in plugin manager are split in 2 places because they cover somewhat different topics. Dev-docs explain how to create packages in general, while readme in metadata repo explains how to publish to the official repo specifically. Official repo rules are more strict than general repository and package requirements. It also has a step by step recommended workflow.
Let me know if something is still not clear if you read both docs. I wrote most of them.
Hey @qu1ck,
thank you for the heads up and the docs. I took the time to read the guidelines more carefully and iron out all the errors. The major show stopper was to have more files in the resources folder than just the icon.
Now, to clarify a bit my original statement about the development (and deployment) workflow, I’m currently checking out my plugin development repo in one of the plugin locations known to Kicad. This way while developing I can quickly test new version of the plugin simply Reloading from pcbnew GUI.
The folder structure for development is not compatible with the one for the published plugin (one level deeper and split in plugins + resources) as far as I’m aware.
So, In the spirit of automating things, once I grasped the general ideas above (but feel free to suggest other ways if available), I went on writing a GitHub workflow to pack the plugin and also generate the metadata info needed.
Upon pushing a tag to the plugin development repo, a release is created containing the packaged plugin and the metadata file to use in the kicad metadata repo.
I’m thinking of writing a proper github actions that would, on top of the tasks above, also push the metadata to the (forked) metadata repo, so that the only thing left for the developer is to create the merge request.
Let me know if the above makes sense and the proposed GitHub Actions might be helpful.
cheers,
Stef
The github workflow and action are definitely useful, at least for github users but others will spy some ideas too.
The way I solved your problem of development layout vs pcm layout is a simple shell script that I run locally whenever I want to package the plugin.
This was is also my approach (ReplicateLayout/make_a_package.sh at master · MitjaNemec/ReplicateLayout · GitHub)
thank you guys for the feedback.
I published a first draft of the GitHub action on the market place. It’s lacking a bit of documentation at the moment, but here are the links if you want to take a peek:
- action code and issues: GitHub - cooked/actions-kicad-addon: GitHub action to release a KiCad addon to the metadata repository
- example of workflow with manual and push triggers: kimotor/release.yml at master · cooked/kimotor · GitHub
requirements:
- the plugin development repo shall contain a blank metadata.json like this: kimotor/metadata.json at master · cooked/kimotor · GitHub
- the plugin development repo shall have a GitLab token setup in the Settings > Secrets
cheers,
stef
1 Like
In the interest of completeness, Greg Davill also wrote a Python script to package it up:
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.