berteh
On creating a new Scripter engine for Scribus
hi berteh
i think that you're the one maintaining the biggest scribus script around, so i dare to ask you:
would you be interested in working on the concept for a new scripter that uses python 3?
the first bits are here:
https://github.com/aoloe/scribus-plugin-scripter-pybind11/
personally, i'd really like to create a complete new API, in the same way as it was planned for the now defunct (i guess) "scripter 2". (https://scribus-scripter.readthedocs.io/en/latest/). an API that is "object oriented", where one can get items from scribus, and does not have to pass around strings to reference them. where you have iteratable lists...
of course, old scripts will have to be completely reworked (most of the logic will stay the same, but the exact commands will all change)
what do you think about it?
Sorry Ale: no. I don't have enough time now to tackle a new project, as interesting as it may seem... and my lack of CPP knowledge would probably make the result of bad quality.
I was asking on help in the "concept" phase : - )
like:
- it's ok to have a new API?
- what are good ideas for the API (from the Python side).
of course help on the cpp side is also welcome, but, currently, it's not there where i need most of the help.
if my proposal is accepted, you will have work to do anyway : - ) (ok, at some undefined time in the future... and scribus times can be veryyyyy long...)
Some first thoughts:
- I don' see a new (better) API as a problem. Even more if the support for the old one(s) is not removed so that old scripts keep working.
- the API should, I think, allow to navigate, query and interact with an OO model of the document using the same constructs and object hierarchy as that which is visible in the Scribus GUI.
- a much needed related feature (even more useful than full API) would be the ability to find, install, update(automatically?) and remove scripts and plugins from within Scribus. That would provide good visibility to the existing scripts/plugins, and motivate people to maintain them, while building a community around them. Maybe look at the way Notepad++, Wordpress and other softs handle distributed scripts repositories / registration.
- advanced query mechanism would be a huge plus, based on text content, filters, properties, values, types.. in fast and homogeneous way. An XPATH like query language would be super, even if that contradicts my wish for the API to be closer to the object model visible in the Scribus GUI than to that of the SLA's XML. Other options to consider for powerful (enough) query languages could be https://ponyorm.org/, http://objectpath.org/ or https://github.com/pythonql/. But it should be fast. That's what scripting is about: quick hack without having to dive too deeply in the core code stack / compiling environment...
From a technical perspective would it not be feasible to "only" code a mechanism that would refactor the existing cpp code, to put an extra (Python Objects) layer on top of it? Something like instrospect or inspect, not coding the API manually, but letting it be generated as the object model underlying Scribus evolves ?
Something in the mood of https://stackoverflow.com/questions/29119086/how-to-convert-c-objects-to-boostpythonobject or https://clang.llvm.org/ -
An option could be to tag the interesting objects in the cpp source code, adapt the visibility of the methods to make sure all interesting ones are public, maybe set a few others to protected/package to hide them from the API but let the internals of Scribus work fine... and generate the API + python code automagically ;) That would simultaneously make the cpp code cleaner.
And maybe some self completion in an integrated editor, to traverse the properties / children / ancestors of an element in the document with ease. Maybe some introspect framework can provide such facility as well.
FYI the reason ScribusGenerator does work at the XML level and not via API was the inability to traverse / query the document text content and elements properties values simultaneously... whereas regexp on the source material could do it fast (but in a less safe way).
Sorry if this is all too messy. I could try to organise this in some document or mind map if it helps, or let you rephrase it in anyway you understand.
hope it helps, Berteh.
thanks berteh for your comments!
i've opened a ticket for each of your points:
- multiple scripters
- GUI-like API
- scripts in the resources manager
- advanced query mechanism
- code completion
on top of it:
automatically generate the Python API from the C++ code: this is the way Krita has gone. personally, i have the feeling that explicitly creating the bindings with pybind11 leads to a solution that is easier to maintain. the write-ups i've read seem to confirm that.
since scribus does not have an internal API, i would never dare to directly bind the scribus code to a scripter API, it's really not made for that. but in a parallel project i'm creating a plugin API... which could be used for creating the bindings (i guess that at the end both API will be very similar...). but, even then, from what i've seen, writing the pybind11 glue code seems to be as easy as writing xml...
an internal editor: personally, i'm against having an internal editor. there are already many good editors for python, we should make it easy to use them with scribus, as an example by providing syntax files that enables the code completion in there. it's already hard to find the man power for maintaining and improving scribus, i think that building a code editor should not be a priority. a REPL might be useful...
voilà, i thought i could summarize correctly your proposals!