[mpris] playlist name change

[Conor Curran]

Sound good Mirsal.
+1

Conor


On 27/01/11 10:22, mirsal at mirsal.fr wrote:
> On Thu, Jan 27, 2011 at 6:25 PM, Conor Curran
> <conor.curran at canonical.com>  wrote:
>> Hi folks,
> Hey !
>
>> On testing with Rhythmbox and Banshee I just noticed that I have no way to
>> tell if the name of a playlist changes at some point.
> Indeed, we should fix that flaw.
>
>> Would it be possible to add another signal to inform that a playlist detail
>> has been edited.
> I think that this is the way to go.
>
> What about this one :
>
>      <signal name="PlaylistChanged" tp:name-for-bindings="Playlist_Changed">
>        <arg name="Playlist" type="(oss)" tp:type="Playlist">
>          <tp:docstring>
>            <p>The playlist which details have changed</p>
>          </tp:docstring>
>        </arg>
>        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
>          <p>
>            Indicates that either the Name or Icon attribute of a
> playlist has changed
>          </p>
>        </tp:docstring>
>      </signal>
>
>> Alternatively the server could send another playlist count
>> change signal after the edit is complete.
> Well, this would work around the issue, but I am not sure that this is
> a good idea, as it is rather counter-intuitive with respect to the
> intended usage of the
> org.freedesktop.DBus.Properties.PropertiesChanged signal
>
> As a workaround, I'd rather suggest considering playlists as immutable
> (that is, changing the name of the playlist would be equivalent to
> removing the playlist and adding a new one)
>
> Anyway, The issue is clearly on the mpris side, IMHO, and the new
> signal approach seems more correct.
>
> Best regards,
>