extragear/multimedia/amarok/src

[Daniel Winter]

ARGH, sorry i somehow read a not more than there was.  lol. You are right. We 
both meant the same. So just ignore my mail.

DanielW

On Saturday 02 August 2008 16:31:23 Daniel Winter wrote:
> On Saturday 02 August 2008 15:26:21 Maximilian Kossick wrote:
> > Daniel is right. current.xspf's purpose is restoring Amarok's internal
> > state after a restart. Using the internal uidUrl for current.xspf (or
> > any other internal playlist). We do have to distinguish between
> > internal playlists (even if they are stored as files), which use
> > uidUrl (and will work even after moving files around if everything
> > works correctly) and external playlists ofr use in other applications,
> > which must contain the actual url of the track.
>
> Well, in that point you get me  wrong *g*
>
> I think storing the uidUrl (it was url() before) is the best for internal
> playlists..
>
> Only for exporting we should use playableUrl().
>
> That way collections could return what every they want as url() (now
> uidUrl()) do identify a track unqiue even after a move of the file on the
> filesystem.
>
> I already use that for NepomukCollection to make playlists which even work
> after moving the files arround on the disk.
>
> It didn't break anything.  Other collection (for example some remote
> collections) could also use that to just use some id which that service is
> using.
>
> Also it alows for faster trackForUrl() as a collection can direct say "no"
> for a track when there is a url like amarokcollection_sqltrackuid:/ or
> something like that.
>
> So i see no problems for that, I even see a need for that.
>
> And export playlist and some dbus api functions is the only place where we
> have to make sure to use the correct url() function.
>
> If that should not get used in this way, for what should that used then? I
> understood it that way, that that is the exact use case for that thing in
> the meta api.
>
> DanielW
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel