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

List:       kde-commits
Subject:    Re: extragear/multimedia/amarok/src/scriptengine
From:       Jeff Mitchell <mitchell () kde ! org>
Date:       2009-05-05 18:59:09
Message-ID: 4A008C7D.1000809 () kde ! org
[Download RAW message or body]


Leonardo Franchi wrote:
> On Monday 04 May 2009 12:31:19 Dan Meltzer wrote:
>> On Mon, May 4, 2009 at 4:35 AM, Leo Franchi <lfranchi@kde.org> wrote:
>>> SVN commit 963223 by lfranchi:
>>>
>>> +QString
>>> +MetaTrackPrototype::url() const
>>> +{
>>> +    GET_TRACK
>>> +    return track ? track->playableUrl().url() : QString();
>> You should either name the method playableUrl(), or, based on what its
>> used for, name it uidUrl() and use that instead. (TrackForUrl works
>> best with uidUrls, I think..)
>>
>> Api differences between the scripts and the standard c++ code is going
>> to lead to headaches, especially with something like url(), where
>> there are 30 different options....
> 
> 
> I thought about this, but my reasoning was as such:
> 
> 1) Script authors don't care about uidUrl. it's something like 
> sqltrack:/<md5sum>, so really not useful at all. 
> 2) In normal usage the "url" of a track is the location on disk or the 
> playable url, so that is the expected outcome
> 
> 
> we could change it to playableUrl, but that could confuse authors as they 
> would then think "so is there another url() that returns a different url?" 
> which is confusing.

I would have both playbleUrl and uidUrl.

There are definitely some instances where script authors might want to
get a uidUrl.  This could be useful for identifying songs on or
transferring songs to external media, for correlating functionality they
provide to specific tracks (regardless of their location), etc.

--Jeff


["signature.asc" (application/pgp-signature)]

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