Summer of Code: Draft of Playdar Proposal

[Bart Cerneels]

On Thu, Mar 25, 2010 at 16:17, Leo Franchi <lfranchi at kde.org> wrote:
> On Thu, Mar 25, 2010 at 10:46 AM, Bart Cerneels <bart.cerneels at kde.org> wrote:
>> On Thu, Mar 25, 2010 at 14:40, Maximilian Kossick
>> <maximilian.kossick at googlemail.com> wrote:
>>> On Thu, Mar 25, 2010 at 2:32 PM, Leo Franchi <lfranchi at kde.org> wrote:
>>>> Hi Andy,
>>>>
>>>> Thanks for the comprehensive proposal!
>>>>
>>>>>
>>>>> On the technical side I like to comment though:
>>>>> You list a few custom GUI's required to use playdar in amarok. I
>>>>> suggest you try to do without custom user interface elements for
>>>>> playdar, except of course configuration, which will very likely be
>>>>> required.
>>>>
>>>> I don't think I agree. I think a custom UI in the service browser is
>>>> perfect---a nice delgate for track items that shows what resolver they
>>>> are coming from, for example, as well as the track name/info. Just a
>>>> thought.
>>
>> Yes, that is possible although probably a bit confusing for the end user.
>>
>> One good reason I'm trying to prevent adding more custom GUI's because
>> those will prevent the integration being used in amarok mobile. This
>> is true for many of the services, while the problem doesn't exist for
>> collections.
>
> I don't see how this is relevant.
>
> a) If we use a delegate and M/V stuff we can just write a different or
> standard view for Amarok Mobile, getting around the issue.

But as far as I know not all Services have good model view separation.
It might be a good idea to think about ways to make this possible,
easy and later enforce it.

> b) I strongly disagree with rejecting features from the desktop app
> because of a potential perceived difficultly in a future mobile
> application. We should  keep the mobile app in mind---but i don't
> think that's a valid reason for rejecting a UI decision outright.

OK, I see the point there. I don't want to reject features based on that either.

I do think however that in this specific case, the best playdar
implementation will be a Collection and one that doesn't require
custom UI's. In general good integration into the app will always be
higher quality and nicer to use then something that feels hacked in.