I'm prioritizing this P4 for now - while I agree with the importance of this
issue, this might be non-trivial to do and it might be better to postpone it
after the 1.0 release. ... but I'm open for discussion about this. :-)

Do you have some test code to show us the issue?

Created attachment 231 [details]
Test case, which shows both python lists and QAbstractLists cannot be read from
a QObject property

There is a test-case attached which shows the issue. 

It seems that python lists/dicts also suffer this problem. They work fine if
you set them as a contextProperty, but not as a QObject property. See the
test-case for example. 

As I mentioned on the mailing list, I tried the same setup in C++ (QObject with
QAbstractListModel as a property) and it would not work, even after correctly
registering the QAbstractListModel type with Q_DECLARE_METATYPE and
qRegisterMetaType.

Even more info:

Actually, this DOES work in C++ , and without needing to register any new types
with the MetaType system. It's enough to return your AbstractList, cast to a
QObject*, wrapped in a QVariant:

return QVariant::fromValue((QObject*) _list); // _list is QAbstractListModel*

QML can then access this property and use it as model. 

fwiw... PyQt has the exact same behavior, but you can work around it in the
python list case by declaring your QObject property as type QVariant. This
doesn't seem to work in the AbstractList case.

Apologies for the unorganized nature of the info, but I should add: 

In fact the PyQt workaround (setting Property type to QVariant) DOES work with
Abstract*Models, as long as you keep the reference around :)

So it seems we just need to be able to wrap objects in QVariants when returning
them from QObject properties, either automatically or explicitly.

Now prioritizing P4 (as told I would do - just forgot earlier).

Aidan, thanks for all the analysis - it'll become useful when we get to fixing
this one. And don't worry about the organization. :-)

No probs, but this bug should be renamed or split into two, as the problem
described is not fixed by using qRegisterMetaType, that was just my initial
assumption.

A more accurate title might be.. 'Certain types of QObject properties cannot be
accessed from QML without being wrapped in a QVariant'  

This might be a bug in Qt rather than PySide, as having to do those ugly casts
in C++ to get it to work, is surely not right.

Created attachment 269 [details]
Much cleaner demonstration of the bug.

Just another example, much cleaner.

You can see how QObject properties are handled differently than properties set
with setContextProperty

This was deprioritized to P4 because the bug was regarded as post-1.0 material.
Now that 1.0 has been published for one month already, I'd like to see this
bumped to P3.

I don't know if it's possible to implement this function without hacks like the
ones we did on qmlRegisterType, because qRegisterType binds a name to a C++
symbol, if you use two names for just one symbol qRegisterType will think that
this is just a alias. The problem is that we can't create C++ symbols at
runtime.

Another point is that qRegisterType is not needed in PySide, in C++ it's used
when you want to use a type onto queued signals, but you don't need to do this
on PySide to use your type on whatever signal connection you want to.

Other use of qRegisterType on C++ is when you need to put your type inside a
QVariant, you also don't need to do this on PySide.

So IMO this bug should be marked as WONTFIX unless someone came with a
reasonable use case for this function on PySide.

(In reply to comment #10)
> I don't know if it's possible to implement this function without hacks like the
> ones we did on qmlRegisterType, because qRegisterType binds a name to a C++
> symbol, if you use two names for just one symbol qRegisterType will think that
> this is just a alias. The problem is that we can't create C++ symbols at
> runtime.
> 
> Another point is that qRegisterType is not needed in PySide, in C++ it's used
> when you want to use a type onto queued signals, but you don't need to do this
> on PySide to use your type on whatever signal connection you want to.
> 
> Other use of qRegisterType on C++ is when you need to put your type inside a
> QVariant, you also don't need to do this on PySide.
> 
> So IMO this bug should be marked as WONTFIX unless someone came with a
> reasonable use case for this function on PySide.

OK - given your reasoning, I'm of course fine with WONTFIX as well.

So marking it as WONTFIX :-)

If this is a WONTFIX, what about this bug's test case? Would we ever be able to
access python lists from a QObject property in QML?

(In reply to comment #13)
> If this is a WONTFIX, what about this bug's test case? Would we ever be able to
> access python lists from a QObject property in QML?

Luca, a good point - actually it might be better to reopen and rename the bug
according to Aidan's proposal in comment 7... Doing that.

I do not agree with mark this bug as wontfix, I think we need keep this bug
open.
First because someone can try use and report a new one.
Second because this is a missing feature and we do not have 100% about the
possibility of implement this, we need study more the QML core code, before
give a final answer.

(In reply to comment #13)
> If this is a WONTFIX, what about this bug's test case? Would we ever be able to
> access python lists from a QObject property in QML?

Yes, we would, but qRegisterType isn't related to this.

I still thinking the same way, there's no use case yet for Python version of
qRegisterType.

(In reply to comment #15)
> I do not agree with mark this bug as wontfix, I think we need keep this bug
> open.
> First because someone can try use and report a new one.

No, if we start thinking this way we need to keep ALL bugs always open because
if a regression occur and someone try to open a new bug...

> Second because this is a missing feature and we do not have 100% about the
> possibility of implement this, we need study more the QML core code, before
> give a final answer.

It's not a missing feature, it's a unneeded feature and IMO it's not related to
QML, this is qRegisterType not qmlRegisterType, PyObject is already an type
registered on Qt metatype system by PySide, so this isn't the deal.

The problem is that at the moment we don't known how to tell QML to convert a
Python list onto a JavaScript list, just this.

If the scope of this bug is what the title suggest "Certain types of QObject
properties cannot be accessed from QML" rather than implement qRegisterType,
I'm fine.

(In reply to comment #17)

> If the scope of this bug is what the title suggest "Certain types of QObject
> properties cannot be accessed from QML" rather than implement qRegisterType,
> I'm fine.

Yes, that was my idea when I reopened the bug.

Ok, Now I understand the problem  and I have a solution and a good explanation
for that.

First: For declare properties types with C++ types you can use string to
describe your type.

p1 = Property("Qvariant", getP1)

This will allow you declare properties with QVariant type.


Second: If you will use the properties inside on QML code return types witch
the QML can handle. Do not use python types ("list, dict, object") these types
will be wrapped to a PyThonType object which is unknown by QML. 


Third: If you return new QObject make sure that QQboject will exists as long as
necessary(keep a reference on pyside, or set some parent object for that),
otherwise pyside will destroy that and c++ will crash.

With that in mind you can fix you example to work as you like.

I will upload the code based on these facts for you check. Give me some reply 
about that, and feel free to give new ideas or complains, or please mark the
bug as closed if you fell satisfied with that explanation.

Created attachment 323 [details]
test updated

Ok, I will close this bug since the problem was solved.

PySide release 1.0.3