[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDEREVIEW: nowplaying dataengine and applet for plasma
From:       "Ian Monroe" <ian () monroe ! nu>
Date:       2008-01-31 16:37:16
Message-ID: f680fec50801310837l7275efaclf4333eaf8c4298bf () mail ! gmail ! com
[Download RAW message or body]

On Jan 31, 2008 6:07 AM, Kevin Krammer <kevin.krammer@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.

> > > It also messes up the discoverability. Any user using tools like qdbus
> > > will see all methods on each node and probably wonder why certain methods
> > > return a D-Bus error when being called.
> >
> > I haven't noticed this problem. That said, I'll ping the list and ask
> > why we're doing it this way.
>
> 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.
[prev in list] [next in list] [prev in thread] [next in thread]