[mpris] [RFC] MPRIS2 Release Candidate

[Mirsal Ennaime]

On Thu, Aug 12, 2010 at 8:47 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 10.08.10 14:15, Ian Monroe (ian at monroe.nu) wrote:
>
>> > Bindings which generate code from introspection data will probably not
>> > be able to handle these signals.
>> > As signals which indicate changes in the media player state are a
>> > critical part of the mpris functionality, using PropertiesChanged
>> > would mean that applications which use these bindings would have a
>> > hard time using the mpris.
>> >
>> > Switching to different dbus bindings or working around this looks much
>> > more complex than merely meeting an additional dependency.
>>
>> These sound like good reasons to never use PropertiesChanged.
>
> Fix the problems where they are, don't try to tape over them. Write the
> specs clean, don't write the spec to work around currently broken
> software.

Anyway, Alex and I wrote test-cases with existing bindings in order to
be sure that this signal doesn't make it impossible to implement the
spec.

Alex's test case showed that only the only thing which breaks when
using Qt-DBus is introspection, and I successfully tested that gdbus's
support of the PropertiesChanged signal works even with broken remote
introspection data.

So this particular issue is not actually relevant.

(As this happened on IRC, I think I should share why we switched to
org.freedesktop.DBus.Properties.PropertiesChanged after all)

-- 
Mirsal