Hey guys, There does not seem to be a lot of feedback. I guess I am rather early to the pcbnew Python Plugin Party ;-)
I have dug deeper into the code and found out, that the plugins are actually pulled into python using 'import'. I was under the impression that a python interpreter was instantiated each time a plugin was executed. This changed everything completely, I have found a good way to organize the stuff (and I have done it here as an example: https://github.com/skuep/kicad-plugins/tree/master). I am currently going with the following folder structure + ~/.kicad_plugins/ - action_plugin_a.py # some other plugin - action_plugin_b.py # another one + action_plugin_big/ # a big plugin in a folder - plugin_big_action.py # containing the ActionPlugin class - plugin_big.py # containing some more general stuff - plugin_dialogs.py # containing generated dialogs - __init__.py # containing the instantiation and register() - __main__.py # optional. if available, plugin runs standalone + resources/ - some_other_stuff.png So everything looks good right now. It just has to be documented somewhere. Is there a place where documentation about the python plugins is collected? Again, I hate when these informations are scattered in forums or other peoples githubs... Also this looks unprofessional ;-) Best Regards! Simon Am 09.06.2017 um 13:09 schrieb Simon Küppers: > Hey guys, > With my current work on python plugins for pcbnew, I noticed that you > quickly want to go ahead and divide up your plugin into multiple > subfiles (e.g. test_plugin.py, test_plugin_main_dialog.py, etc..) > > Right now, KiCad loads the python files from the hardcoded folders (one > of them being ~/.kicad_plugins however it does not do it recursively. > Thus it is not possible to organize the files in a subdirectory (e.g. > test_plugin/). > > Another thing that I noticed (but did not confirm yet) is, that action > plugins need actually have "action_" prepended to the .py file in order > for them to load properly so that they are shown in the pcbnew menu. > This is also on purpose right? > > I guess my proposal for a _consistent_ handling of python plugins in the > future might be either > 1) Make test_plugin/ subfolder and place all files into this > subdirectory. KiCad recursively loads all plugins in the hardcoded > directories > > 2) Make test_plugin/ subfolder and place all files into this > subdirectory. When the user wants to use a plugin, he needs to create a > relative link in the hardcoded directory to the corresponding entry-file > in the test_plugin/ sub-directory. > > I am currently leaning towards the 2nd solution. But in order for it to > be user friendly (also to those who arent computer savvy), each plugin > needs some kind of installer to perform the copying and linking. I guess > this solution is also more "linuxy" since I have seen this technique in > a lot of different applications (e.g. munin plugins). > > What are your thoughts on that? > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
