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
