[Development] Deprecating modules with 5.5

Simon Hausmann simon.hausmann at theqtcompany.com
Wed Mar 18 11:00:19 CET 2015


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.macieira at 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 at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development




More information about the Development mailing list