[mpris] [RFC] MPRIS2 Release Candidate

[Ian Monroe]

On Mon, Aug 9, 2010 at 1:02 PM, Alex Merry <kde at randomguy3.me.uk> wrote:
>  On 09/08/10 02:19, Ian Monroe wrote:
>>
>> On Sun, Aug 8, 2010 at 8:01 PM, Alex Merry<kde at randomguy3.me.uk>  wrote:
>>>
>>> I've ditched the property change signals in favour of the new D-Bus
>>> standard.  I've ditched the capabilities stuff in favour of booleans and
>>> optional properties (where getting a NotSupported error when you try to
>>> access a property tells you that it's not implemented).  Times are all in
>>> microseconds.  AdjustVolume is gone.
>>
>> I still think a bit field for capabilities makes more sense. Some of
>> us use caveman tools like QtDbus where its not especially easy to make
>> multiple calls at once afaik.
>
> It's probably time someone submitted a merge request to fix that :-)  Maybe
> I will if I get through the rest of my TODO list...
>
>> Plus aesthetically, using a bit field for capabilities is something I
>> do in my own programming not so much because of efficiency concerns
>> but its just really easy to compare several bits at once and cleanly
>> communicate state to several parts of an application.
>
> But in a C++ application, for example, you'd typically use an enum to
> associate sensible names with those values.  When you are viewing an
> interface using qdbusviewer, for example, or looking at the introspection
> xml, there's nothing to tell you what bit in the bitfield means what.

Copy n' paste it from the API docs. This API is already too
complicated to be usable with just blind qdbusviewer poking IMO. Plus
our API docs are all professional looking now. :)

>> What's that point of this new MediaItem object? What was wrong with
>> the simple dictionaries (that appear to still be in use)?
>
> Well, this version of the spec was supposed to be "with all Lennart's
> suggestions implemented", and that was one of them - using D-Bus objects as
> the unique identifiers.  Also, I was following the design (and, where
> appropriate, the detail) of the MediaServer2 spec.  This approach does have
> the advantage of fixing the metadata fields, and describing them in the
> introspection data.
>
> Note that (a) I haven't tried actually implementing this draft, so I have no
> idea how problematic requiring the tracks to be D-Bus objects is, and (b)
> I'm not really that attached to most of it (although I think much of it is
> sensible).

Ok, that makes more sense. I agree its something worth looking into.
As long as it doesn't make it much more complicated to implement. I've
never returned custom types in DBus before.

Ian