Merge lp:~laney/python-dbusmock/introspection-properties into lp:~pitti/python-dbusmock/old-bzr-trunk
Status: | Merged |
---|---|
Merged at revision: | 164 |
Proposed branch: | lp:~laney/python-dbusmock/introspection-properties |
Merge into: | lp:~pitti/python-dbusmock/old-bzr-trunk |
Diff against target: |
115 lines (+49/-16) 2 files modified
dbusmock/mockobject.py (+32/-0) tests/test_api.py (+17/-16) |
To merge this branch: | bzr merge lp:~laney/python-dbusmock/introspection-properties |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Martin Pitt | Approve | ||
Review via email: mp+198906@code.launchpad.net |
Description of the change
The introspection XML currently doesn't include <property> nodes, breaking some things which rely on it such as Qt's property support.
I found an old-ish dbus-python bug about adding this there but it doesn't seem to have gained much traction:
https:/
Since we already override Introspect(), I figure it's not too bad to add this there even if it is a bit ugly.
One wart:
+ # copy.copy removes one level of variant-ness, which means that the
+ # types get exported in introspection data correctly, but we can't do
+ # this for container types.
+ if not (isinstance(value, dbus.Dictionary) or isinstance(value, dbus.Array)):
+ value = copy.copy(value)
While the support works for properties added via the python library (e.g. in templates) without this, dynamic proeprties added using AddProperty over dbus don't. If you remove this and run the testsuite you'll see what I mean. AddPropert{y,ies} get type 'v' when introspected. We probably want them to have the actual types, so this tries to unpack the variant by one level (you can't just decrement variant_level as the object is immutable; copying it doesn't preseve this). It breaks for container types though, so we don't do this there—again, remove that bit and see what happens to the NM tests. I'd be glad to replace this with something better if you can think of an improved way around.
The test changes are because we now take the XML through a parser which changes the order of the arguments. Shouldn't be anything clients need to worry about.
Thanks a lot for this! That's indeed a long-standing wart. I merged it with some stylistic changes and changing properties to be readwrite.