-----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
