Writing and publishing a plugin

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.


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:



1 Like

In the interest of completeness, Greg Davill also wrote a Python script to package it up: