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
