rt rules more strict, recently (however we also
intended to keep current import semantics mostly working, to support legacy
modules). Matt (cc'd) should be able to give more information.
Cheers,
Chris.
From: development-bounces+christopher.adams=nokia@qt-
ipt environment in QML, see
http://qt.gitorious.org/qt/qtdeclarative/blobs/master/src/qml/doc/src/javascript/hostenvironment.qdoc
for more information.
Cheers,
Chris.
> -Original Message-
> From: development-bounces+christopher.adams=nokia.com@qt-
> project.org [mailto:devel
Hi Sivan,
> Hi All,
>
> Following the rather interesting discussion that started by Rene[0] , I've
> summarized the bits I believed to be important for others seeking the same
> information as he did, and put it on the wiki[1]. I've also created a new
> category on the wiki main page, dubbed as
Hi,
> > In QtQuick 2.0 (ie, Qt 5.0), we are thinking about using property var
> > more often in the implementation (eg, of qobject-derived-type
> > properties) to avoid some of those edge-cases, and providing more
> > consistent (and useful) referencing semantics.
>
> Can you say what 'var' is an
Hi Rene,
I certainly agree that constructive discussion about the QML language and ways
that it could be improved are important. You raise a lot of important points,
some of which will be addressed in Qt5.0, some of which we still need to
consider how to fix, and what priority they should be,
Hi,
>> At this point, I'm either looking for an alternative to V8
>
> This is more of an follow-up question for the list than a reply:
>
> QtDeclarative includes the V4 javascript interpreter that (as far as I know)
> can
> handle simple javascript expressions. How far can you get with V4
Hi Alberto,
Firstly, this is a really interesting topic, so thanks for bringing it up, and
even more thanks for offering to help investigate and implement changes!
Secondly, this problem is one that we have considered before, and the ideal
solution is probably some "binding is dirty" flag, combi
Hi Holger,
> > Hi again,
> >
> > the previous points are not answered but I have one more question. Why
> > do we need to have the QML_GLOBAL_INDEX slot and carry it around?
> Why
> > can't we just patch src/contexts.cc with the current code but resolve
> > the qml_global and qml_global_global thr
Hi,
> And the splice function on longer remove the "rants" from the list now...
> But now I can still get e.g. stringList.length, stringList[1] working fine as
> before.
>
> Any hints? A bug, or just an expected change of the behavior?
>
Yes, I probably broke this accidentally while adding sup
Hi,
Regarding QContactLocalId in particular, I personally think doing something
like QOrganizerItemId makes the most sense, but more benchmarking and
prototyping is required before anyone could say for sure, I guess. Matthias
and Robin have mentioned (on IRC) some performance considerations wh
10 matches
Mail list logo
