2015-03-18 11:00 GMT+01:00 Simon Hausmann <***@theqtcompany.com>:
> 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.
>
That's a fair requirement.
>
> Would you be interested in trying to implement that in QJSEngine? :)
>
Sorry, I already taken too many engagements for the time being. I home
someone else do it though !
>
> > 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
I was specifically speaking about free functions. Skimming my code, I use
them to define utilities like print,
as well as supporting the PAC specification.
For some use case, I guess you could do something like : var foo =
object.foo (where foo is a function), but it doesn't solve
every use case, notably, functions like print can take an arbitrary number
of arguments. QtScript solves that by registering functions
taking a "context" object, holding the parameters as well as other useful
info, like the value of this.
Will that sort of thing be supported in the future ?
>
> 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 <***@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
> > > ***@qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/development
>
>