Reference-counting pointers
eudoxos opened this issue · 3 comments
I am opening this issue to discuss how to use pointers in the Python scripter. The problem I see is that scribus uses raw pointers internally, so the wrapper has to use those as well (of course this involves risky things, such as objects being deleted while the scriper is active). There is no way to use managed pointers (shared_ptr and similar, also including unique_ptr) when some parts of the code don't use them.
So the way is either to start using shared_ptr inside scribus (that would be my idea, but it is a huge change for the whole code), they integrate beautifully with python reference counting. This is high-performance computing code https://woodem.org/ using shared_ptr and is entirely scriptable in python. The advantage is that Python can go as deep into the internal structures as desired.
Another options is that the scripter will use raw pointers (perhaps wrapped in lightweight wrapperss) and assume that the underlying document will never change while the script is running, so that none of the pointers becomes stale, leading to Python crashing.
right now i'm trying to create a fake API that is as clean as possible
https://github.com/aoloe/cpp-pybind11-playground/tree/master/scripter-api
i'm stuck at #3 but i hope to make some progress again soon! : - )
(i probably just got the right hint... i'll try it later this evening...)
once i got the full sample working (https://github.com/aoloe/cpp-pybind11-playground/tree/master/qt5-pyqt5) i'll start thinking about the real data structures in scribus...
as far as i understand it, the situation with the pointers is even a bit more complex, since QObjects (as most if not all scribus objects are managed by the Qt garbage collector...
on the other side, what for now makes everything simpler, is that the scribus document is not supposed to change on the "C++" side during the lifetime of a script.
in the future it would be nice to have "non modal" scripts... as a way to extend the scribus UI... but i'm not sure if PyQt and Qt UI elements play well together...
thanks for your hints and interest and i really hope to have a complete prototype really soon and being able to start creating a scribus plugin!
The UI should be okay. WooDEM's main is in python, there is bunch of (optional) PyQt5-based UI but also a window with OpenGL view which is entirely built in c++. PyQt needs the QApplication (or QApplicationCore) to be initialized, and that is done on the c++ side just fine. Can't comment on signals.
I read a bit about QObjects, the result being that since object lifetime is managed by Qt (deletes child objects when parent object is destroyed), so passing raw pointers is okay.
A nice thing to have (off-topic here) would be a context manager which would defer any display updates of the document - either automatically when the script is running, or by guarding some portion of the script in with scribus.noGuiUpdate: ....
the option not to update the rendering exists in the current scripter. so, yes, that part should be possible!