On 30 July 2015 at 14:21, Stefan Derkits <ste...@derkits.at> wrote: > The use cases still have to be fleshed out ... maybe streaming services > are more important than ripping CDs? Really hard to say. > Please join the discussion in the boards and add your ideas there :)
It always struck me as weird that we had 4 separate apps for doing essentially the same thing: displaying a list of track metadata for songs belonging to the same album, and then doing something with those tracks, either editing or playing or ripping or burning them. Certainly as a user I could never understand why inserting a CD lead to a different app launching and competing with the MP3 Player for the audio output. And then if I wanted to rip that CD I then had to go find another app which also asked to fetch the same metadata. It's a natural fit, even if ripping doesn't need to be there in v1.0, it's just adding an extra step on to the CD playing code. Designing the UX and code with that in mind from the start is important and a lot easier than tacking it on later, especially for the code side. I don't think we need to add the Audio CD burning feature though, that time is mostly past, leave that to K3B :-) Define streaming services. Like Spotify? Just too complex and almost impossible to keep up with them all, even if you could access the ones you want: leave that to bigger apps. Like internet radio stations? Yes good to have, but a different UX and database backend required than for the CD/MP3 player side, so not a direct fit into what the VDG mock-ups show. You essentially have a single track, with the station taking the role of the album, and the database/management side basically being a web bookmarks file. More advanced is talking to directory services like ShoutCast or TuneIn, but again maybe the myriad of directory services are better left to bigger apps, at least to start with? The heart of this new app is easy management of a track database and playing those tracks in a flexible way. Nail that first, then stuff like ripping and streaming and device export can come later. > Not soo sure about that, JuK seems to still use KDE3Support Libraries > ... porting them to Plasma 5/KF5 could be hard. Urgh, that's a bit of a surprise, I thought mpyne had cleaned it all up. At least talk to Michael, he'll be a able to give a lot of good advice. John. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
