[Scribus] Scripter API

[Craig Ringer]

Petr Van?k wrote:
> hi Joachim,
> 
> On ne 23. prosince 2007, Joachim Neu wrote:
>> I thought it would be nice to have an object-oriented view for the
>> python scriptplugin instead of only a collection of functions.
>>
>> So I yesterday implemented a document-object to see if I can do this
>> (I'm not so good in C++.) and it worked.
> 
> Manual implementation of "scribus object model for python" cannot be done 
> IMHO. It will take years of work and it will be broken everytime there will 
> be a change in the "core". We can see it in the current Scripter. It always 
> contains bugs due changes in underlying methods.

I'd have to agree with this. It's a losing proposition to maintain 
hand-written bindings for an app with internals that change as much as 
Scribus's do. Use of the raw Python API makes more sense for (eg) 
wrapping a C library.

>> So (if possible) I'd like to implement this feature. I also found a
>> folder called "scripter2" within the scriptplugin-directory which looks
>> like a object-oriented rebuild of the scripterplugin but it seems not to
>> be useable.
>>
>> So maybe someone can give me a hint what "scripter2" is and how I can
>> contribute to it, if this is the next generation of the scripter-api. If
>> not I'd be glad to hear what you think about my idea.
> 
> There was a short debate about this one:
> http://nashi.altmuehlnet.de/pipermail/scribus/2007-November/026553.html
> 
> Scripter2 directory was a Craig Ringer's boost:python testing stuff. It has 
> not been ever maintained. And there are no plans to do anything with it.

Yep. While I found that boost::python worked fairly well, and I was able 
to get nice transparent QString <--> Unicode conversion (removing much 
of the ugliness of text in the current engine), the internals of Scribus 
just are not suitable to be exposed directly to Python.

Exposing the internals directly requires the user to know about all 
sorts of rules and requirements for using the internal data structures. 
They can be complex (especially where things are deferred for 
performence reasons), they change release to release, they're not all 
documented, and a few of them don't make much sense - like when GUI code 
is deeply involved in manipulating canvas objects.

To use Boost::python or any other wrapper scheme, it will first be 
necessary to write a more stable C++ front-end API to wrap. That API can 
provide all the things a scripting interface (and most plugins) will 
want, like accessors on object properties that ensure that the 
appropriate parts of the app find out when changes are made. I just 
don't see any other reasonable way to expose the app to scripting 
languages. It'd help plugin authors out a lot, too.

It'd be simpler to write a pure C++ interface API to hide Scribus's 
innards then use a wrapper generator or boost::python to expose that to 
Python than it would be to hand-code a new interface. However, it's 
still a lot of work, and currently there's nobody interested in tackling it.

> We should make some decision about the future of Scribus scripting.
> 
> Maybe we can take one "technology" named in the previous posts: Craig's 
> BOOST::PYTHON or Hennig's "Pure Python" playground and polish it for real 
> usage.

Unfortunately I presently don't have much time to work on open source 
projects as my work is very busy. I'm also not entirely enthused about 
tackling scripter work at present.

> Guys (Craig, Hennig), can you look at it too, please? And discuss some 
> pros/cons of your solutions?

Well, I've outlined above (and other times) what I think is probably the 
best way to tackle the problem in a long-term maintainable way. However, 
as I presently have no interest in building and maintaining that public 
C++ API for script wrapping & for plugins I'm not sure how much my 
opinion really counts for.

To me, though, it just comes down to the fact that we need a more usable 
interface for plugin writers too - and ideally for people to add other 
languages if they want later. Doing the "hide the nasty innards" work 
once with a C++ wrapper API for public consumption just seems like the 
obvious way to reduce duplicate work.

--
Craig Ringer