On Tuesday 17. March 2015 15.04.19 Corentin Jabot wrote:
> Regarding QJSEngine, some things are unclear to me.
>
> Let's say I have a QObject-derived class. how do I create an instance of
> that class from a script ?
>
> c++ : class Foo : public QObject { Q_OBJECT }; js : var foo = new Foo()
Yes, custom constructor functions are not supported at the moment. I think
it would be fairly easy to implement this, the meta-object system supports
dynamic construction. If you mark a constructor as Q_INVOKABLE, then you can
do
QObject *instance = metaObject.newInstance(parameters)
So for QObject sub-classes with invokable constructors, we could expose these
as JavaScript constructor functions. Due to the requirement to place
Q_INVOKABLE, it becomes an op-in feature.
Would you be interested in trying to implement that in QJSEngine? :)
> How do I call a c++ function from a js script ? That use case seems not
> supported at all, I'm I right ?
If it is a member function, then it is callable. It can be a member function
of a QObject or a gadget.
Simon
> Those two features seems essential to me for QJSEngine to ever replace
> QScriptEngine. They also are pretty basic.
>
>
> I understand one will have to heavily modify the C++ code to port to
> QJSEngine, but, I find the fact that the port will break the scripts...
> worrisome
>
>
> I think QJSEngine should aim to be compatible with any script that worked
> with QScriptEngine (provided the C++ code is modified accordingly)
>
>
>
> Regards,
> Corentin Jabot
>
> 2015-02-10 4:30 GMT+01:00 Thiago Macieira <thiago.macie...@intel.com>:
> > On Monday 09 February 2015 22:52:34 Kevin Kofler wrote:
> > > Guido Seifert wrote:
> > > > Did something like that happen before?
> > >
> > > Yes, RHEL has never shipped QtWebKit, as far as I know because of
> > > support
> > > (especially with security updates) concerns. (They're likely to also not
> > > ship QtWebEngine, but that will be a topic for RHEL 8. QtWebEngine did
> >
> > not
> >
> > > exist yet when RHEL 7 was released.) They also ship kdelibs with
> > > Plasma::WebView patched out, kdepim without KMail (because it depends on
> > > QtWebKit), Qt Assistant built against QTextBrowser, and similar such
> >
> > feature
> >
> > > removals/degradation throughout KDE.
> > >
> > > If all that stuff moves to QtWebEngine, we will likely end up with
> > > Fedora
> > > and Debian getting similarly crippled. :-(
> >
> > You'll probably have to provide a repository for packages supported less
> > thoroughly. There are just too many requirements for Web parsing.
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >
> > Software Architect - Intel Open Source Technology Center
> >
> > _______________________________________________
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
