[Scribus] Scripter API

[Henning Schröder]

On Jan 2, 2008 7:07 AM, avox <avox at arcor.de> wrote:
> > To give all a small update. I worked little bit on ScripterNG:
> >  * building is easier now because I split up the plugin
> >  * before building the plugin you now have to build a generic Python
> > extension for PyQt embedding called epyqt
> Any details on that?
It does not depend on Scribus libraries but currently is only used for
ScripterNG. So epyqt could also re-integrated into the plugin but it
was easier for me this way. The C++ part contains mainly of two
functions, one to call slots and one to cast variants to objects. The
Python part is a object proxy with property support and the ability to
call every slot which look like normal object methods to the user.

> >  * Javascript (QtScript) is now supported and can also call the C++ API
> >  * as an interim solution the Javascript code can also call the
> > functions of the old scriptplugin (at least some of them - the rest
> > will follow soon)
> I'm not sure that's worth the effford. While we will probably need a legacy
> mode for Python scripts, I'd hate to see new Javascripts using the old API.
This was mainly a spin-off product while playing with QtScript to see
what is possible.
I agree it is problematic to provide support for a depreciated API.
On the other hand there are a lot of useful scripts which I want to
support via a compatibily layer (stubs are already available in
compat.py).


> So ScripterNG only exports public slots and hides protected and private
> ones?
> That's good. Qt properties are always public IIRC?
I have not tested it in detail. I can do everything the Qt metasystem
allows me to do and I supposed that Qt will handle access rights
correctly.



Henning