[Amarok] b0503f5 Move Playlists back into Meta.

[Maximilian Kossick]

On Sun, Mar 28, 2010 at 8:06 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
> On Sun, Mar 28, 2010 at 19:38, Jeff Mitchell <mitchell at kde.org> wrote:
>> On 03/28/2010 01:00 PM, Bart Cerneels wrote:
>>> Let me base this one similarities with Meta::Track.
>>
>> The fact that you architected playlists around Meta's architecture
>> doesn't mean they belong in Meta.
>>
>>> * They are also made available by a provider (ref. TrackProvider). It
>>> can be part of a Collection consisting of a TrackProvider,
>>> UserPlaylistProvider and QueryMaker.
>>>
>>> * have different implementations (Sql, File, UMS),...
>>
>> Like Collections or Plugins. They don't belong in Meta.
>>
>>> * Playlist is a fundamental type in the sense of track being the
>>> fundamental type that has Album, Artist, Genre, ... as it's fields.
>>> Playlist has only has one complex type field: TrackList. All the rest
>>> are strings.
>>
>> Again: so? (Also: if Playlist is a fundamental type, and Meta is a
>> fundamental type, this makes even more sense why they belong outside
>> Meta, instead of having fundamental types inside fundamental type.)
>>
>>> * Playlist could be queried on in QueryMaker as a new QueryType. That
>>> way we can search for playlists that have tracks with certain albums,
>>> artists, Genre, rating, ... in them.
>>
>> They can't, according to the bits of the conversation you just had with Max.
>
> That discussion went nowhere because Maxx didn't want to understand
> the explanation and technical solutions I presented. It's perfectly
> possible that I made incorrect assumptions but there was no
> explanation where I was wrong. Only think I got was a No and a
> restatement of, what I believe to be, incorrect assumptions.
>
> I assume this is another call for Maximilian to correct me or work
> with me to improve this.

In my opinion there are technical challenges which make adding
playlists as a new QueryType to QM impractical. And writing a new
PlaylistQueryMaker interface/implementations has its own issues as
playlists should not store all the metadata that QM can filter on
again.

A possible solution that occured to my yesterday evening might be to
simply query for tracks when filtering in the playlistbrowser, and
then compare the playableUrl or uidUrl of those tracks with the ones
stored in the playlists. That last comparison should be quick enough
to be doable in the GUI thread, and you get QMs full filtering
capabilities without having to extend the data that is stored in
playlists each time the track metadata is extended.

>>
>>> I'm sure there are more arguments to be made, but the biggest one is
>>> more abstract:
>>> Playlists should not be treated as a second class citizen in Amarok by
>>> keeping them out of the true hard of amarok's core: Meta and
>>> Collection. It's as much a technical issue: Playlists not supported by
>>> QueryMaker; as a social one: new collection implementations (MD)
>>> lacking a decent PlaylistProvider.
>>
>> Stop making baseless assumptions. I've never thought of Playlists as a
>> "second class citizen" no matter how many times you have made that
>> claim. Nor do I know of anyone else feeling this way except for you.
>
> This is not an assumtion, it's a statement of fact. I'm the only one
> working on playlists, other peoples implementations are non-functional
> and unmaintained. If Collection would have been treated the same way
> there would be no track browsing, copying or organizing in amarok.
>
>>
>> Maybe instead of saying that the true hearts of Amarok's core are Meta
>> and Collection, you should be making statements that the true hearts of
>> Amarok's core are Meta, Collection, and Playlists.
>>
>> In fact, the evidence is against you: in core/ you find not only meta
>> and collections, but also playlists, plugins, podcasts, statistics, and
>> more.
>>
>>> Even though 2.3 has gotten some excellent comments there are still
>>> very vocal, flat out hostile rejections that are hard to ignore: there
>>> is no decent playlists synchronization and some implementations are
>>> flat out missing.
>>
>> And this has what to do with Playlist being in Meta? (NOTHING.)
>>
>>> Not surprising as there is only one time strapped developer working on
>>> this. Since Jeff has already reverted this I'm sure people are not
>>> interested in improving this though.
>>
>> There's only one time strapped developer working on most of the
>> different parts of Amarok.
>>
>> --Jeff
>>
>
> Your mail did not contain anything constructive. You should stay out
> of this discussion. [1]
>
> [1] http://www.kde.org/code-of-conduct/
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>