Yesterday I have a look to clementine they have local music AND a great set of online account too. As someone write here before, they are also working on a QT5 port. I understand that the clementine users are looking for a amarok 1.4 player, but there are a huge numbers of audio players with different skins.
cheers Andreas 2015-08-04 21:40 GMT+02:00 Ing. Konrad Renner <konrad.ren...@kolabnow.com>: > Hi, > > I can help test and maybe some easy tasks coding ( I have not coded with > C++ for some years and have to get in again). > > Yours Konrad > > Am 04.08.2015 5:47 nachm. schrieb Andrew Lake <jamboar...@gmail.com>: > > > > So far Stefan identified the following as needed: > > -) More People to discuss & flesh out the vision [1] > > -) A motivated team of designers, software architects, coders & testers, > > dedicated to creating a modern music player for our users > > > > I think it shouldn't be difficult to get input on fleshing out the > vision. We could use the KDE Forums or a blog post for that. I also think > we won't have much trouble getting testers. You can count on help from the > VDG for design and from myself to directly support this effort. So really > what remains from the list is software architect(s) and coder(s). > > > > I count the following people who appear to have made explicit offers to > help: > > - Stefan Dertkis (original poster, coder?) > > - Eshtan Robateau (architect? + coder?) > > - Andrew Lake (UI design + architecture support if needed) + VDG > > > > If anyone else is interested, please, please speak up. I genuinely think > there is clear value in what Stefan proposes. The current VDG Music Player > design, including the vision, personas and scenarios, are far from set in > stone so we can certainly revisit it as necessary. Also I think we can > eventually work out the practical details of what code base or pre-existing > solutions we could take advantage of in order to fulfill the vision and > avoid the perils of creating yet-another-music-player. Whether that > solution is from-scratch or as simple as a skin doesn't concern me terribly > at this point. > > > > Stefan, I suggest we take a chance and start with a small core team of > folks who are willing to volunteer at this early stage. If that team can > produce something concrete in the near term, we can work on growing the > contributor base when people have something more concrete to look at. > > > > Hope this helps, > > Andrew > > > > On Sun, Aug 2, 2015 at 3:21 AM Eshton Robateau wrote: > >> > >> Hi all, > >> > >> >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? > >> > >> I'm committed to work on this as main. I've been swimming in the > bangarang codebase and so far we're almost rewriting the entire thing. From > my perspective, porting is near rewrite, so it's better to have a good > design and vision from the start. Might I suggest that we simply have a > survey of what our users (plasma or general) want from a music player > instead of relying on personas. It seems a bit naive to assume we only have > casual users and power users. Feedback from actual users is more concrete > than anything persona we can invent. FWIW I want a music player that plays > music and supports playlists and media info, I'm not likely to use other > features much. > >> > >> ------------------ > >> > >> _______________________________________________ > >> Bangarang mailing list > >> bangar...@kde.org > >> https://mail.kde.org/mailman/listinfo/bangarang > _______________________________________________ > Amarok-devel mailing list > amarok-de...@kde.org > https://mail.kde.org/mailman/listinfo/amarok-devel >
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
