Doxygen for V6.99 Python API?

External Plugins
#1

Is there any documentation for the V6.99/V7 Python API available somewhere?

Possibly something equivalent to the autogenerated docs for the v6 python api: KiCad Pcbnew Python Scripting: pcbnew Namespace Reference

Also, do you have any recommendation on how to determine if the plugin is loaded in V6 or V6.99/V7? I guess I can do a “try - except” on some random api call that have been changed, but maybe there’s a smarter way?

#2

I don’t believe there are docs for current nightly yet but @marekr did promise them at one point.

Plugin loading errors can be viewed in preferences action plugins panel. If there are errors a warning triangle button will pop up.

#3

Thank you! If @marekr would find the time to generate the docs, that would help a lot. Since V7 isn’t far away, it would be nice if as many plugins as possible were working at the time of the release.

Sorry, bad choice of words from my side. What I was trying to ask for is a way for the plugin to detect which KiCad version that’s currently being used.

I can do this by simply trying an api call that’s not available in V6.99.

try:
    # This call is only available on V6, not V6.99/V7
    plot_options.SetExcludeEdgeLayer(True);
except:
    # Seems like V6.99/V7 is being used.
    pass

But maybe there’s a more elegant way? Something like:

if (VERSION_V7):

#4

I chose to use copious amounts of hasattr calls to detect what API is available.
Easy way to tell v6 from v5 is FOOTPRINT vs MODULE classes. I don’t know an easy way to tell v6 from v6.99 but it’s not that different overall. A lot less changes compared to the jump that was v6.

1 Like
#5

I just found that v6 and later has pcbnew.Version() and pcbnew.FullVersion() so that should help.

#6

That’s perfect! Thank you

#7

If you are releasing your plugin to work on 6.99 I’ve found the pcbnew.GetBuildDate() also useful. You can catch users with old nightly versions trying to run a plugin which depend on a recently added feature.

#8

Great tip! Thanks!

And merry christmas to all, since I must write some characters. :slightly_smiling_face:

#9

Actually V6 API documentation is now removed too from the docs.kicad.org.

https://docs.kicad.org/doxygen-python/ shows 404 Page not found! :frowning:

Can we have a short manual on how to generate the docs itself?

E.g. checkout kicad source at tag v6, install doxygen, run “make only pythondocs without full compilation” or something along these lines?

Update: missing doxygen documentation is referenced at

https://docs.kicad.org/6.0/en/pcbnew/pcbnew.html#scripting

So this page will need update too.
From

 Users wishing to write or modify scripts should also
use the Doxygen documentation located at 
https://docs.kicad.org/doxygen-python/namespaces.html.

To something along the lines of:

 Users wishing to write or modify scripts should also
generate the Doxygen documentation using ......
#10

Probably @marekr restructuring the docs site.

Unfortunately you have to generate the swig interface for the docs and I’m not sure it’s possible without full compilation.

1 Like
#11

What about with full compilation? I’ve compiled KiCad before, but it’s been about a year since the last time. I checked the documentation (Build | Developer Documentation | KiCad), but it doesn’t say much about how to generate the documentation. From what I can see, all it says is that Doxygen is only needed if the documentation shall be generated. How do I generate it? :thinking:

#12

As long as cmake has found doxygen it will have doxygen-docs target you can build.

If there is anything platform specific you will have to do in addition to that you can take a look at packaging scripts here KiCad Packaging · GitLab

#13

You actually don’t. swig generates its nonsense based on headers, it doesn’t need compilation.

Unforunately, the current problem is the cmake target for python doxygen is broken currently (I tried to get nightly python doxygen going). It never should have worked and has some really oddball behavior.

custom target A depends on custom command output
custom target B also depends on the same custom command output
custom target A deletes said output but comments “force removal so its regenerated”.

I have yet to find any documentation that cmake was ever supposed to do just magically rerun the custom command for target B after already doing so for A. The only change recently was switching to DEPFILE instead of DEPENDS for the custom command so maybe there’s some undocumented cmake behavior that changed