One of the reasons to use QVariant is that it's usually what is needed to
connect a C++ signal to a QML function or to use invokeMethod, I could only
ever get this to work by passing all arguments as QVariants.
See for example:
http://doc.qt.io/qt-5/qtqml-cppintegration-interactqmlfromcpp.html#i
I'm certain that it's possible. I suspect the reason why the code used
QVariant is that when it was originally written (in Qt 4.7 days, IIRC),
QJSValue didn't exist, and it simply hasn't been ported to newer interfaces
since then. Without knowing too much about the QML bindings in QtPIM, I am
goi
On quarta-feira, 28 de setembro de 2016 15:42:06 PDT Simon Hausmann wrote:
> I don't think the QVariant interface is deprecated, but it just inherently
> unsuitable for JavaScript specific things such as distinguishing undefined
> from null or storing function closures. That is why the engine suppo
macie...@intel.com
Sent: September 28, 2016 17:37
To: development@qt-project.org
Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null
On quarta-feira, 28 de setembro de 2016 08:54:10 PDT Simon Hausmann wrote:
> Hi,
>
> Ok, let me clarify: When the JavaScript engine wants to
On quarta-feira, 28 de setembro de 2016 08:54:10 PDT Simon Hausmann wrote:
> Hi,
>
> Ok, let me clarify: When the JavaScript engine wants to map a JS null value
> to a QVariant, it used to use
>
> QVariant(QMetaType::VoidStar, (void *)0);
>
> and now uses
>
> QVariant::fromValue(nullptr
On Wednesday 28 September 2016, Olivier Goffart wrote:
>
> int main() {
> QVariant v1 = QVariant::fromValue(nullptr);
> QVariant v2 = QVariant::fromValue(nullptr);
> qDebug() << v1.isNull() << v2.isNull() << (v1 == v2) << (v2 == v1);
> qDebug() << v2.canConvert() << v2.canConver
On Mittwoch, 28. September 2016 10:39:42 CEST Allan Sandfeld Jensen wrote:
> On Wednesday 28 September 2016, Thiago Macieira wrote:
> > On quarta-feira, 28 de setembro de 2016 01:22:33 PDT Allan Sandfeld Jensen
> >
> > wrote:
> > > > QVariant::fromValue(nullptr).isNull() == false
> > > > QVariant(
: development@qt-project.org
Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null
On terça-feira, 27 de setembro de 2016 18:22:34 PDT Simon Hausmann wrote:
> I'm fairly sure we used QVariant(QMetaType::VoidStar);
Can you guarantee that the only time the QML engine genera
On Wednesday 28 September 2016, Thiago Macieira wrote:
> On quarta-feira, 28 de setembro de 2016 01:22:33 PDT Allan Sandfeld Jensen
>
> wrote:
> > > QVariant::fromValue(nullptr).isNull() == false
> > > QVariant(QMetaType::Nullptr).isNull() == true
> >
> > And QVariant(nullptr) doesn't compile.
>
On quarta-feira, 28 de setembro de 2016 01:22:33 PDT Allan Sandfeld Jensen
wrote:
> > QVariant::fromValue(nullptr).isNull() == false
> > QVariant(QMetaType::Nullptr).isNull() == true
>
> And QVariant(nullptr) doesn't compile.
>
> We should probably fix the fromValue constructor.
I don't think s
On Tuesday 27 September 2016, Thiago Macieira wrote:
> On terça-feira, 27 de setembro de 2016 18:22:34 PDT Simon Hausmann wrote:
> > I'm fairly sure we used QVariant(QMetaType::VoidStar);
>
> Can you guarantee that the only time the QML engine generates null
> QVariants is for null JS Values? That
On terça-feira, 27 de setembro de 2016 18:22:34 PDT Simon Hausmann wrote:
> I'm fairly sure we used QVariant(QMetaType::VoidStar);
Can you guarantee that the only time the QML engine generates null QVariants
is for null JS Values? That is, no null QStrings, null QVariantLists, null
QVariantMaps/
I'm fairly sure we used QVariant(QMetaType::VoidStar);
Simon
From: thiago.macie...@intel.com
Sent: September 27, 2016 19:26
To: development@qt-project.org
Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null
On terça-feira, 27 de setembro de 2016 09:31:14 PDT T
On terça-feira, 27 de setembro de 2016 09:31:14 PDT Thiago Macieira wrote:
> On terça-feira, 27 de setembro de 2016 15:29:16 PDT Simon Hausmann wrote:
> > That said, I think it can be written without #ifdef perhaps by using
> > QVariant::isNull() ?
> >
> >
> > (QVariant(nullptr) maps to isNull()
On terça-feira, 27 de setembro de 2016 15:29:16 PDT Simon Hausmann wrote:
> That said, I think it can be written without #ifdef perhaps by using
> QVariant::isNull() ?
>
>
> (QVariant(nullptr) maps to isNull() as well, right? ;-)
It should.
But QVariant(QString()) [after you bypass C++'s most v
t on
behalf of Thiago Macieira
Sent: Tuesday, September 27, 2016 5:04:56 PM
To: development@qt-project.org
Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null
On terça-feira, 27 de setembro de 2016 11:25:49 PDT Simon Hausmann wrote:
> That is exactly the part I'm
On terça-feira, 27 de setembro de 2016 11:25:49 PDT Simon Hausmann wrote:
> That is exactly the part I'm referring to. Receiving a QVariant from the QML
> engine and relying on it to contain a specific type.
Well, I would say it's acceptable that the QVariant contain different numeric
types as th
smann
Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null
On segunda-feira, 26 de setembro de 2016 09:31:34 PDT Simon Hausmann wrote:
> That said, this is not quite the same as changing the return type of a typed
> C++ function. QVariant is designed
> to hold any t
On segunda-feira, 26 de setembro de 2016 09:31:34 PDT Simon Hausmann wrote:
> That said, this is not quite the same as changing the return type of a typed
> C++ function. QVariant is designed
> to hold any type and if you receive a QVariant it has always been a little
> dangerous to rely on specifi
M
To: development@qt-project.org
Subject: Re: [Development] Behaviour change in QML in Qt 5.8 regarding null
On segunda-feira, 26 de setembro de 2016 09:02:58 PDT Jędrzej Nowacki wrote:
> On mandag 19. september 2016 11.14.51 CEST Chris Adams wrote:
> > Hi,
> >
> > Recently, a few
On segunda-feira, 26 de setembro de 2016 09:02:58 PDT Jędrzej Nowacki wrote:
> On mandag 19. september 2016 11.14.51 CEST Chris Adams wrote:
> > Hi,
> >
> > Recently, a few unit test failures[1] in the (unreleased) QtPIM module
> > showed that the recent change[2] which changes the semantics of nu
On mandag 19. september 2016 11.14.51 CEST Chris Adams wrote:
> Hi,
>
> Recently, a few unit test failures[1] in the (unreleased) QtPIM module
> showed that the recent change[2] which changes the semantics of null
> assignment (from JS) to a QVariant Q_PROPERTY can affect existing client
> code.
>
Hi,
Recently, a few unit test failures[1] in the (unreleased) QtPIM module
showed that the recent change[2] which changes the semantics of null
assignment (from JS) to a QVariant Q_PROPERTY can affect existing client
code.
Certainly, the cases which are affected are most likely edge-cases (that
i
23 matches
Mail list logo
