[PyQt] Conversion from QML

[B. B.]

Hello Phil,

I am not a experienced at all with qml, pyqt or qt, but after reading more
docs, and try things out, I am quite sure what I think would be the correct
to do in this case....

I would let the implementation be as it is now, meaning always returning
the QJSValues.

Why:

- as you write, there must be a reason, that the functions returns
QJSValues. ( Maybe it is the "monadic" evaluation environment, making
people able to create javascript object, and execute functions and
memberfunctions on them deeply inside qml - I do not know if there exists a
fair usage for that..:-). )

- you wrote that old return value was a QVariant, ( I was not aware of
that, and not aware of QVariants automatic conversion to python types ).
The QJSValue has a toVariant function, that converts to right type, as you
described above.
So calling a the toVariant() function on the returned QJSValue, to get
objects packed out to dicts, arrays to lists, strings to str etc.etc seems
to me very fair, avoiding breaking anything with Qt v.5.4.


Using the example .

data = item.getStuff()    # Qt v.5.3

data = item.getStuff().toVariant()  # Qt v.5.4

the 2 data is both "python values". If I knew this QVariant thing, ( read:
If I had read the docs more carefully ), I would never have asked this
question. Just used it - it is simple, it actually follows the documentation


Best Regards

Brian



On Thu, Jan 8, 2015 at 5:23 AM, Phil Thompson <phil at riverbankcomputing.com>
wrote:

> On 08/01/2015 5:36 am, B. B. wrote:
>
>> Didn't you always have to call toString() etc. to get the actual values,
>>> even with Qt v5.3?
>>>
>> >
>>
>>>
>>> If so then implementing the mapping protocol should allow you to write
>>> code that would work with both v5.3 and v5.4 without needing to be
>>> changed.
>>>
>>> Phil
>>>
>>>
>>
>> No, It was not neccesary, because there was no QJSValue in what the
>> function returned.
>>
>
> I was misled by your app.py example calling property() in section 2.
>
>
>  With the combination :
>> Qt :
>>  5.3
>>
>> PyQt :
>> PyQt-gpl-5.4-snapshot-
>> 15b37c22d541  ( from around 17 of november )
>>
>> Sip:
>> sip-4.16.5-snapshot-c005a6d2e53e ( around 17 of november )
>>
>> All values returned were already "python values":
>> ( from the example, earlier in this thread ):
>>
>>
>> The return value with combination Qt5.3 , PyQt, sip from 17/11 )
>>
>>  {'texts': [<PyQt5.QtCore.QObject object at 0x7f1d6c11fc18>], 'good':
>> 'yes'}
>>
>>
>>
>> The return value with Qt5.4 , PyQt, sip from about 25/12, is that
>> QJSValue:
>>
>> <PyQt5.QtQml.QJSValue object at 0x7f2563921898>
>>
>> This is the QJSValue type, one have to pack out, to get the "python one"
>> like the one above...
>>
>>
>>
>> Because the return value earlier contained "pure python", like str, dict
>> and list, along with PyQt5 objects, like QObjects,
>> I thought the PyQt5 earlier did a processing, prepareing the result. But
>> that was somehow lost in progress since november.
>>
>> This was a pure guess, I have really not looked into changes from qt-5.3
>> to
>> qt-5.4, or in any PyQt sources....
>>
>>
>> Because of you question, I see a little hope for the smooth easier old way
>> of returning :-)..
>> I will try to run the example a crossed sources, ( New PyQt5 with qt-5.3 ,
>> or PyQt5 from november with qt-5.4 - if that is possible ). Just to
>> verify...
>>
>
> I could do the automatic conversion of bool, QDateTime, QObject etc. and
> leave it as a QJSValue if no obvious conversion could be done. However
> there must have been a reason for the change in Qt v5.4 - maybe because the
> isError(), isNull(), isUndefined() states were being lost by Qt v5.3
> automatically converting to a QVariant.
>
> I don't have enough personal experience with using QML to know what the
> right thing to do is, so feedback needed.
>
> Phil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20150108/c2dab575/attachment-0001.html>