Re: Plugins Interoperability via JS?

[Matevž J. <mat...@gm...>]

Hi Reinhard. You should forward this to ML as well.

I was thinking a lot about this a year ago when QtScript was introduced.
There is also PythonQt (not PyQt!) which can be used through QtScript. See
Qt quarterly paper http://doc.trolltech.com/qq/qq23-pythonqt.html .

The problem I had looking at javascript was that you couldn't get any useful
libraries for the javascript engine in real life. For example Python has a
large userbase and has support for sound, images, web stuff, Qt, statistics
etc. It has Eclipse IDE plugin, a command-line interpreter and a portable
library. If you're looking for an arbitrary library, it's very possible
there will exist bindings for Python beside the C/C++. This makes it a very
useful scripting alternative to the native C/C++ interface.

I asked myself then why do we need two scripting languages. If we replaced
Swig with QtScript backend and still using Python that would be great. But I
don't see this possible yet. And introducing just another scripting language
and keeping Swig is loss of resources IMO. Having one scripting language
which works as it should is much better. I can't say anything against Python
becuase it works very well for Harmonia.


Regards.
-Matevž

2009/3/19 Reinhard Katzmann <su...@we...>

> Hi,
>
> For being able to interoperate with other Qt apps using QtScript
> we might want to add at least JavaScript support somewhen in the
> future.
>
> I found that Swig was once supported externally via SwigJS but
> that project was abandoned (corresponding page is only available
> on internet archive) and replaced by SpiderMonkey (new Mozilla JS
> engine). So we would have to either use Qt or SpiderMonkey if we
> want to offer JS support. I personally dislike Javascript generally
> but seeing more and more application with QtScript Only plugin
> support I'm beginning to think about it.
>
> Theoretically Swig -> Java -> Rhino would be possible too but
> this is certainly no good way for defining the plugin interface...
>
> Though we could use QtScript I currently prefer SpiderMonkey (1.8) as
> engine being probably more mature and probably faster as it is
> implemented in C (I didn't find any current benchmarks for that
> so we'd have to test this for ourself) or more feature-rich/compatible.
> Also we don't have use for the Qt interface offered via QtBindings
> with our current plugin concept.
>
> I didn't look at other implementations like KJS / JavascriptCore
> (certainly also implemented in C++), just too new at the moment.
>
> If you agree I post this to the mailing list else >/dev/null
>
> Regards,
>
> Reinhard
> --
> Software-Engineer, Developer of User Interfaces
> Project: Canorus - the next generation music score editor -
> http://canorus.berlios.de
> GnuPG Public Key available on request
>