[bmpx] Re: Proposal for a common D-Bus interface for media players

[Milosz Derezynski]

> On an unrelated note, I think it might be a good idea to include some
> basic capabilities negotiation.

This was a plan that i had with MPRIS all the way until - it got stopped, by
subversion (not the SCM) through GNOME developers who wanted to base a spec
on it and never came up with anything, yet i believed it so i didn't work on
MPRIS further.

BTW since this is already brought up (additional features of the spec, and
I've just brought up that I've already thought of those), if i may ask and
regardless that it's about me what's exactly the "madness" portion in
"basically mpris just without deadchip madness" in that sentence?

I might be personally interested in what tru meant by that, but this list
isn't the place for it so i just would like to know what Amarok and XMMS2
have agreed on so far (?)


Also, while you're right that doing something like tru proposed (signing up
a draft between 2 parties only so it doesn't take ages) will break the usual
intertia involved in such processes when a lot of parties are involved, you
aren't afraid that everyone else will basically feel coerced into going with
your spec? They may follow, but they might not believe.

This is what Rafael meant (note that he isn't an english speaker and
probably not as proficient in pointing things out), when he emphasized the '
"FREEDOM" ' in his initial mail: So we _ALL_ agree on something _HERE_, and
no one really feels coerced into something.

As he, also, originally pointed out, the spec should be only mostly generic
and contain one object on the interface that is meant for player-specific
methods; as far as generic capability negotiation goes i agree, in the case
of BMPx it's even more complex (and i figure in the case of Amarok, although
i'm not 100% sure) since for BMPx, it depends on whether it can go next or
not on what it's currently playing (e.g. there is no "next" when playing a
http stream, since we're not 100%-playlist based anymore like Amarok, RB,
XMMS (1.2), etc) but it plays directly from the relevant playbacksource).

WRT this it might be even needed to do dynamic (playback-control-)caps
negotiation/sending out status updates on the interface.

Super-brief overview over the current BMPx architecture:

The playbacksources derive from 2 classes: PlaybackSource and UiPart; UiPart
is a base class that gives it an interface to communicate with the
playershell wrt UI control, and PlaybackSource is a class that provides
basic stuff for communicating with the player shell when it comes to
playback control: Simple example, you select an album in the albums list,
thus you basically can start playback (with no selection in the album list,
and the album list being currently visible, you just can't play anything),
so the CAN_PLAY caps gets set and emitted as signal to playershell, which
then sets the "play" action active. Same things happen for next/prev (more
importart wrt the above), since if the app reaches the last item in let's
say the playlist, or for an album, there is no next item anymore (usually),
and hence the CAN_GO_NEXT caps gets disabled, for one so PlayerShell doesn't
even try to go to the next item, and 2ndly so that the controls can be
visibly disabled as a hint to the user.

(Yeah some people think it's irrelevant whether all actions reflect the
current application's state, but i don't.)

Overview like this:

[Source 1]  [Source 2]
         \               |
           \             |
        [        Playershell      ] (Basic/general GUI control, HOSTS:
Playbacksources)
                         |
        [             Core            ] (DBus, application start/stop
control, HOSTS: Shell)


Milosz

On 12/6/06, Daniel Chokola <dan at chokola.com> wrote:
>
> Milosz Derezynski wrote:
> > Allright as i've read on the transcript, you're going to implement the
> > DBus interace as a "client" anyway.
> >
> >
> > So for one: nevermind the part about "DBus or nothing", but then again
> > what is your concern with running one player, and debugging XMMS2 the
> > same time?
> > Milosz
> >
>
> That was just an example. but the concern is that someone might want to
> have a couple clients running at once to different players. For example,
> I already use a couple clients to constantly talk to my stereo PC. While
> in the meantime I run the latest XMMS2 from git to test new features and
> hack away.
>
> It doesn't have to be on different machines, either. If two clients are
> running on the same machine and both running the same DBus service, will
> it be possible to control them individually?
>
>
> On an unrelated note, I think it might be a good idea to include some
> basic capabilities negotiation. Maybe check that a program can support
> playback, playlists, medialib, and metadata. That way simpler media
> players like VLC can omit things like the medialib. I think this could
> save a lot of bickering over implementation and watering down of the spec.
>
> -Dan "puzzles" Chokola
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok/attachments/20061206/cb80d51b/attachment.html>