Python scripting support (work in progress)
Hello,
I've been playing around with adding Python support to Inkscape for some time. In contrast to the current extension system that runs the interpreter externally, this allows to use Inkscape functionality via Python code.
Progress has been slow, since I am new to mostly anything necessary to implement it (C++, CMake, GTK, git, even Python). I decided to do the implementation manually (without SWIG, Boost.Python, etc.) since there's already enough new stuff for me to deal with.
At the current state, there is not much to show, but some of the infrastructure is in place: * Inkscape-integrated Python console with basic command history and limited coloring (different colors for log messages, input, output and errors) * A pane to select Python files and run them * A rudimentary set of bindings: * Arbitrary Inkscape verbs can be run * Files can be opened * Files can be saved. Selecting the output file type on basis of a MIME type, i.e., export to other file types than .svg is supported, but the user interaction dialog for the export settings pops up. * PNG export * Listing and activating desktops (open files) * Running Python scripts from the command line is possible, although only in non-GUI mode for now.
Since the basics are working I decided it would be a good point to share the code and check if you think this is a direction worth pursuing. Especially, since some design decisions that should be discussed beforehand are ahead.
Please let me know how to submit the code. Would you like a patch against current master or should I create a Gitlab account?
wiesi
Hi wiesi,
this is so cool, can't wait to test it!
The best way to submit it is as a merge request in gitlab (if you don't know how to, a short tutorial can be found here: https://docs.gitlab.com/ee/gitlab-basics/add-merge-request.html Basically, fork the project in gitlab to create a personal clone, then create a branch with your proposed changes, and create a merge request to have it reviewed and merged into master.)
Regards,
Max
Hi Max,
I've finally had some time to clean everything up, create a GitLab account and so on. It is available in the "phyton-internal" branch, see https://gitlab.com/wiesi/inkscape/tree/python-internal (Haven't dared to create a merge request, yet, since there are several rough edges.)
I've also created issues for the known bugs I could not resolve up to now or things that should be improved.
If anyone wants to try it, please note the following: 1. Everything was only tested on Debian 9, which is my test/build system. For any other distributions or operating systems, you mileage may vary. 2. The cmake script searches only for Python 3.5. If found, you should get a line with "WITH_EMBPYTHON: ON" when running cmake. 3. The Python console is located in Edit => Python console in the main menu. 4. Some Python scripting tests and examples can be found in share/python/tests of the source tree.
If the branch is deemed useful, the following steps come to my mind: 1. Make more useful functions callable from Python. 2. Give Python access to the SVG document. I'm not sure if it is better to work on the object tree or the XML tree: * It seems to me that the first option may require (or trigger) some (or lots or) re-implementaton or (heavy) refactoring of code since, for example, creating objects appears to be rather tied to the GUI tools and is not easily callable from outside. * The second option may need less C++ coding, but would (re-)implement more stuff on the Python side. Allowing Python to traverse the XML tree, modify, add and remove nodes may already be sufficient on the C++ side. This is my favourite at the moment. 4. Python scripts should be able to create user interfaces. Maybe the infrastructure already in place for extensions can be re-used. Other alternatives would be something like PyGTK and may be more flexible. I don't know how such toolkits play together with the main application and have yet to investigate that. 5. Callbacks from user interactions to Python scripts would be nice: Mouse, Click, Keyboard listeners. This could enable Python to implement new drawing tools. It may depend on the decisions taken in point #4.
Feedback on everything is welcome. I think the next important design decision is item #2 and I hope to get some hints from more experienced developers.
Regards, wiesi
Maximilian Gaukler <development@...3069...> hat am 7. Oktober 2018 um 20:02 geschrieben:
Hi wiesi,
this is so cool, can't wait to test it!
The best way to submit it is as a merge request in gitlab (if you don't know how to, a short tutorial can be found here: https://docs.gitlab.com/ee/gitlab-basics/add-merge-request.html Basically, fork the project in gitlab to create a personal clone, then create a branch with your proposed changes, and create a merge request to have it reviewed and merged into master.)
Regards,
Max
participants (2)
-
unknown＠example.com -
Maximilian Gaukler