KDEREVIEW: nowplaying dataengine and applet for plasma

[Kevin Krammer]

On Thursday 31 January 2008, Ian Monroe wrote:
> On Jan 31, 2008 6:07 AM, Kevin Krammer <kevin.krammer at gmx.at> wrote:
> > On Wednesday 30 January 2008, Ian Monroe wrote:
> > > You just have to pass an extra option to either the cmake command or
> > > to qdbusxml2cpp to change the classname.
> >
> > Right, but I was more referring to having all methods of the interface in
> > the QDBusAdaptor, having to implement all of them in the adaptee.
> >
> > > You can see the code in
> > > kdemultimedia/dragonplayer/src/dbus, I didn't have to do anything too
> > > strange (though I kind of messed up my naming scheme, that's my
> > > fault).
> >
> > Ah, so you have split the interface into separate introspection files
> > already. Consider how awkward your code would look like if you had used
> > the introspection data as specified by MPRIS spec, i.e. with all methods
> > on each node.
>
> I think you must have misread the spec or the spec mis-states itself.
> I based Dragon Player on looking at the spec and also looking at
> VideoLAN in qdbusviewer, and now Dragon Player's DBus looks like
> VideoLAN's.

Well, the spec says there is a D-Bus interface called 
org.freedesktop.MediaPlayer and then lists its methods.

Additionally it says which methods to imlement on which object, but totally 
fails to say how to treat the rest of the methods, so it is up to the 
implementation if they implement all methods on all objects, silently accept 
calls and return dummy values, throw a special D-Bus error or let the 
bindings throw a D-Bus error, a.k.a undefined behaviour.

Especially something placed in the org.freedesktop "namespace" shouldn't be 
that ambiguous.

I am really starting to wonder why there is so much resistance against doing 
it correctly.

> > You introspection files are almost perfect, they just need different
> > names for the interface, but they already split the methods into suitable
> > groups.
> >
> > I'd say suitable names would be org.freedesktop.MediaPlayer for the
> > interface of the root object, org.freedesktop.MediaPlayer.Player for the
> > interface of the player object and org.freedesktop.MediaPlayer.TrackList
> > for the tracklist object.
>
> Yes, this makes sense to me.

I wish you good luck trying to convince other involved developers. Some of 
them seem to enjoy ignoring free expert advice for months.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080131/6cea3127/attachment.sig>