Ahoy ahoy, ramblings ahead! On Thu, Jul 30, 2015 at 12:42 PM, Stefan Derkits <ste...@derkits.at> wrote: > This music player should not replace Amarok or other great Qt-based > music players like Tomahawk or Clementine, as their feature set is much > bigger than this new music player should ever have.
^ this One of the great regrets and failures of Dragon Player was that it went from the original vision of the simplest of video players to I don't even know what. It now plays audio cds don't you know... I think jlayt put it best: > Personally, I've been thinking most of kdemultimedia needs to die in > the KF5 era, people are no longer interested in maintaining the code, > much functionality is close to obsolete, and far bigger, better > standalone projects have media playing well covered. sandsmark and sebas at least support this assertion as they use streaming services and hardware players. And as sebas said: > Building what's basically an MP3 player today seems like going back to the > past. All of this I agree with. If we want to build something that is still relevant in a couple of years I'd not hold on to the idea of building a feature rich *local* music player with collection. It's a substantial effort tech-wise and probably becoming pointless since the rise of smartphones and tablets and their numerous cloud streaming services which are just so much more convenient. Now with that in mind I do not think that the present user stories or visual design line up with the expectancy that a possible new player is *not* going to replace (that is: feature wise excessively compete with the existing ones). Looking at the user scenarios I see profound overlap with all major features of Amarok and Clementine and to a lesser degree Tomahawk (this one actually is pretty unique in terms of how it integrates with the internet). So I do not think what is layed out actually reflects what we want here. To solve this I think three very central question need to be answered very precisely before doing anything else. 1. How many people will actively commit to working on this as their *main* project? 2. What does the primary target audience of Plasma even need? 3. What do the contributors want to actually have in the end understanding their own time constraints? The first question is extremely relevant. One person could implement the existing design to meet all scenarios. It will have substantial shortcomings though and long term would likely require too much investment from one person to work out. As this thread shows everyone has their own corner case requirements they want to put on the table and just fighting out what gets even considered is extremely demanding and pretty much an endless fight. Assuming we design a player for Plasma rather than just a good music player in general, I am also not convinced that the design we have is in fact what the target audience needs as far as Plasma personas are concerned. [1] Carla owns 3 devices that can play music, I doubt she'd faff around with syncing up local music files when she probably can afford a subscription to spotify, apple whatever or google music (same for the currently used Susan persona FWIW since she even likes to share music a lot). Raj is a different story though, I'd be inclined to argue that instead of spending money on a sub he'd much rather pirate music so he needs local playback if he wants to enjoy music ;). Food for thought. Lastly I think contributors need to be on the same page with regards to where the product should go long-term and this needs to be messaged properly through the UI and also in promo effort. No one wants another frankenDragon that has a new maintainer every year and has worse feature scope creep than systemd. There are a million features one can put in a music player. At the end of the day the million features won't make it a good player though. Being reliable and smart about its core functionality will. And in terms of the being reliable thing, less is usually more. [1] https://community.kde.org/Plasma/Workspace_Sprint/Personas HS _______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
