Add python bindings

[ubruhin]

So we can script things :)

May be related to #2 and #5.

[ubruhin]

@hephaisto already started with some experiments: https://github.com/hephaisto/LibrePCB/tree/python_bindings

[hephaisto]

Current state

• I implemented a proof of concept using boost::python (https://github.com/hephaisto/LibrePCB/tree/python_bindings)
• It exposes the most vital properties of librepcb::library::Symbol and contained objects
• Standalone scripts can import the module and load/edit symbols
• Scripts can be embedded into the main appliation (currently hardcoded filenames etc.) and do in-place editing of objets in the main application

Data transfer Application->Script

How should data (mostly references to elements already existing in the app) be transported from the application to the scripts? Example: When editing a symbol in the library editor, a pointer to the librepcb::library::Symbol of the current editor window, SymbolEditorWidget::mSymbol.data(), has to be accessed from the python script in order to modify it in-place. I have the following ideas:

A) current data node as global (implemented currently)

Place the root data node of the currently active window in a global variable, e.g. symbol. If the currently active window is not for editing symbols, the corresponding variable is set to None.

Disadvantages:

• Global variables

Advantages:

• easy to implement

B) singleton proxy object

One proxy object (e.g. lpcb) is put in the global namespace of the python script. This object can then be queried for the various possible current editor states, e.g. lpcb.getCurrentSymbol().

Disadvantages:

• hard to implement (mostly because closed windows have to be removed safely)

Advantages:

• easy to use

C) function parameters

Define standard names and signatures for functions in the script, e.g. f_symbol(symbol). This function will get called with the current symbol as a parameter.

Disadvantages:

• restrictions on the user on how to structure code

Advantages:

• clear interface (function names already communicate in which editor state they should be called)
• multiple functions per script possible

D) full fledged plugin architecture

Similar to C, but with added metadata which allows to put multiple functions, documentation etc. in one script, which could then be chosen e.g. per drop-down in the GUI.

Disadvantages.

• overkill for simple use cases
• lot of implementation work, especially on the GUI side, where I can't really help much.
• might need refreshing on script changes, which will be often when developing own scripts

Advantages:

• Very flexible, easy to use

@ubruhin suggested to look into qt plugins. However, as far as I understand, they have to be compiled (please correct me if you know more). This would be deterring for users not familiar with the build system (i.e. end users). I'd want the scripting interface to be usable with as few knowledge about the internals as possible. When using plain python scripts, changing them is a matter of simply editing them with a text editor.

If you have additional suggestions, please label them continuously for easier discussion.

[ubruhin]

Nice comparison, although at this time I can't say which one I would prefer. I need to spend some time to think more about that some day.

@ubruhin suggested to look into qt plugins. However, as far as I understand, they have to be compiled (please correct me if you know more).

Qt plugins need to be compiled, that's correct. But my idea was to create one Qt plugin which provides the python bindings (e.g. a plugin called "Python Bindings"). As soon as this plugin is loaded, the user can write his own, arbitrary python scripts without knowing anything about the C++ codebase.

So, the "Python Bindings" Qt plugin would be just a "proxy" between the LibrePCBs C++ codebase and the Python scripts of the user. If it would really work that way, I think we can get a very clean overall architecture (and still high flexibility) for plugins and for the python bindings.

[ubruhin]

This issue was moved to https://librepcb.discourse.group/t/add-python-bindings/37