Scribus Forums

Scribus => General Discussion => Topic started by: eudoxos on June 27, 2017, 04:07:57 PM

Title: python APIs confusion
Post by: eudoxos on June 27, 2017, 04:07:57 PM
Hi everybody,

I would like to get some clarification on Python scripting in scribus. Is it correct that the default build comes with scripter "1" in scribus/plugins/scriptplugins with the clumsy stateful interface and one can build scripter2 with WANT_SCRIPTER2=1 in cmake which is in scribus/plugins/scripter? There are many documents on the wiki but many of them are perhaps obsolete.

Secondly, is the API documentation for scripter 1 available somewhere officially? I go by pprint.pprint(dir(scribus)) and print(scribus.something.__doc__) in the python console for now, which is not the most satisfactory thing I've done till now. For scripter2, I found http://scribus-scripter.readthedocs.io/en/latest/index.html.

Third, marginally related: is it possible (with either API) to take text in linked frames (i.e. the whole text that opens in story editor) and find its paragraph style name with python?

Thanks!

Vaclav
Title: Re: python APIs confusion
Post by: a.l.e on June 27, 2017, 05:13:08 PM
hi vaclav

- yes, scripter 1 is the default
- no, scripter 2 does not work anymore
- yes, there is not much missing to get the scripter 2 to work (again) but i failed and i would be happy if somebody could help!
- the api for the scripter 1 is in the help files you get with F1 in scribus (for developers > scripter API)

i don't know if you can style names through the script (i cannot check right now, but i think it should be possible) but if you know some c++ and python it should be easy to add that function if it's missing.

ciao
a.l.e
Title: Re: python APIs confusion
Post by: eudoxos on June 27, 2017, 07:47:26 PM
Alright, so if I try, should I go the scripter2 way? What made it broken?

I (co)wrote a large particle simulation package with tight c++/python bindings (https://woodem.org), so I will be able to understand what's going on. What I'm concerned is, long-term, that using raw pointers inside scribus is inherently limiting for tight wrapper.

Cheers! v.