← Back to team overview

kicad-developers team mailing list archive

Re: environment checking in plugins (Re: 5.1.0-rc1)


Hi Carsten
Based on my experience I can only concur, that the code quality of the plugins could be better to say the least. But you have to remember where the plugins start. In general a KiCad user has an itch. That itch can sometimes be taken care of by writing a plugin. And since KiCad is FOSS, it seems like a good idea to make this plugin public (and also to have something to brag about in public). But then you move forward, your itch has been scratched and you don't really have the knowledge nor the motivation to offer support support for the plugin. This could be better, but the published code is a foundation for potential new plugin writer, when he has same/similar itch. And every now and then a plugin writer does offer support and additional python API could make things easier.
As for KICAD_SCRIPTING_WX_PYTHON not being enough, I disagree. By my knowledge, this flags is set to OFF on those systems where KiCad is build against GTK3 but the system has WxPython built against GTK2 (Ubuntu 18) so the required work was done by package managers. If the flag would be set to ON on such a system, then the KiCad would crash even without offending plugin as pcbnew would load python console (which requires wx).

I'll raise a bug report for my wishes, but I'd stop at exposing build information (build flags, ...) to python. Instead of building complex logic for handling plugins I'd rather you guys focus the development time on important issues and let the plugin authors deal with plugin execution. If every now and then a user wanders to developers mailing list, redirect him/her to user support forum. 

      From: Carsten Schoenert <c.schoenert@xxxxxxxxxxx>
 To: kicad-developers@xxxxxxxxxxxxxxxxxxx 
 Sent: Sunday, 10 February 2019, 9:06
 Subject: [Kicad-developers] environment checking in plugins (Re: 5.1.0-rc1)
Hello Mitja,

Am 10.02.19 um 08:13 schrieb Mitja Nemec:
> As a plugin developer I agree that KiCad is not responsible for third
> party plugins, but as a developer I don't have any sane option to
> detect the parameters of the system the plugin is running on.

and what exactly you are missing?
Sorry but I've seen the behavior of the plugins again and again that
there is no checking of a working condition at all. All plugins I've
seen are just don't do any checks if they can work meaningful.
> If build flags (especially KICAD_SCRIPTING_WX_PYTHON) would be 
> accessible to python, I (or any plugin developer) could read it 
> before trying to import wx module and could show a meaningful error 
> message using tkinter instead.
That's the way to go.
But KICAD_SCRIPTING_WX_PYTHON isn't enough. You will also need to know
which version of python-wxgtk3.0 is used if KICAD_SCRIPTING_WX_PYTHON is
set. Build time information for python-wxgtk3.0 can be found e.g. in
On the most of recent Linux distribution versions it will look like
this. OTOH the current stable releases will show here "toolkit=gtk2".

> $ grep WX_CONFIG  /usr/lib/python2.7/dist-packages/wx-3.0-gtk3/wx/build/build_options.py
> WX_CONFIG="/usr/bin/wx-config --toolkit=gtk3 --unicode=yes --version=3.0"

I expect that Kicad Python classes can be expanded easily to provide
some built time information of KiCad if they are missing. What kind of
information is needed is probably to discuss.

If plugins can provide some kind of callback function there KiCad can
detect if the plugin is compatible than the plugin can be displayed
grayed out for example in the UI if they are not compatible. And some
more information like version, author ... if the mouse is hovered over
such an entry.

> Should I raise a bug for this wish?

That would be the best as the noise on the list here is rather high.

Carsten Schoenert

Mailing list: https://launchpad.net/~kicad-developers
Post to    : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help  : https://help.launchpad.net/ListHelp