[Scribus] Scripter API

[Joachim Neu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I think I got your point. So you think first we should think about a
generell API-model (like this one
http://henning.cco-ev.de/scribus/scribusapi.png) (what plugin developers
might want to have and how it's easy to use), then implement it as C++
API and after that export it to several languages by using existing
binding-generators?

Is this task already started? If so, where can I find information about
it, if not: I'd like to have a try. ;)

Marry Christmas!

Craig Ringer schrieb:
> 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
> _______________________________________________
> Scribus mailing list
> Scribus at nashi.altmuehlnet.de
> http://nashi.altmuehlnet.de/mailman/listinfo/scribus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHbsit7awBpSuN1JIRAvdxAJ0eicl3nq/1FIxGBbnzIZ8zaBF2CgCgn4qC
u2EY2GO9syJ3GbG0NFwzBPs=
=fsjJ
-----END PGP SIGNATURE-----
-------------- n?chster Teil --------------
Ein Dateianhang mit Bin???rdaten wurde abgetrennt...
Dateiname   : joachim_neu.vcf
Dateityp    : text/x-vcard
Dateigr??????e  : 216 bytes
Beschreibung: nicht verf???gbar
URL         : http://nashi.altmuehlnet.de/pipermail/scribus/attachments/20071223/7f4f2195/attachment-0001.vcf