content and doc string of RemoteInterface.EventsChanged signal are different
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Zeitgeist Framework |
Fix Released
|
Undecided
|
Markus Korn | ||
Bug Description
From the docstring of this signal:
"""It contains a list of dictionaries containing one or more of `added`, [...]"""
Given that the signature of this signal is "a{sv}" this will never return a list of dicts. The result will always be a dict with one single item with the type of change as the key, and a list of changed items (or uris) as value.
So the docstring needs to be fixed.
And while we are on it we should think about the content of this signal again: why are we using a dict here? In my opinion a dict would only make sense if the content can be something like:
{"changed": [<item1>, <item2>], "deleted": ["uri/to/item3", "uri/to/item4"]}
With the current design of our engine such signal is impossible, and as far as I can see we will never be able to send such signal.
So I suggest changing the content of this signal to a tuple, with <type of change> as first element and a list of changed items as 2nd one:
("changed", [<item1>, <item2>])
Markus
Related branches
- Siegfried Gevatter: Approve
- Natan Yellin: Pending (code singleton) requested
- Zeitgeist Framework Team: Pending requested
- Diff: None lines
| Siegfried Gevatter (rainct) wrote | #1 |
| Changed in zeitgeist: | |
| milestone: | none → 0.2 |
| Siegfried Gevatter (rainct) wrote | #2 |
| Markus Korn (thekorn) wrote | #3 |
| Changed in zeitgeist: | |
| assignee: | nobody → Markus Korn (thekorn) |
| status: | New → In Progress |
| Markus Korn (thekorn) wrote | #4 |
| Siegfried Gevatter (rainct) wrote | #5 |
| Changed in zeitgeist: | |
| status: | In Progress → Fix Released |
That signature, "a{sv}", *is* a list of dicts (the "a" stands for the list, and the "{}" for the dict), albeit with only one item, as you can see below. It is like this because D-Bus doesn't seem to accept standalone dicts.
Generally I wouldn't don't agree with your argument about the current engine, as that may change (and whatever the engine does is an implementation detail, not an API one), but given that I can't think of any use case where having a dict would be useful (other than an implementation which would buffer the signals, in which case sending out three signals instead of one wouldn't be that a big problem either) and for the principle of KISS (and making use of the API easier) I'll agree with you. Let's change this in 0.2.
(dbus.Dictionar