Re: Help wanted to evolve KDEs music players
On 04 Aug, Ben Cooksley wrote : > On Tue, Aug 4, 2015 at 10:38 PM, Martin Sandsmark > wrote: > > On Tue, Aug 04, 2015 at 10:28:35PM +1200, Ben Cooksley wrote: > >> We can't speak for our mirrors in terms of legal risk - those hosting > >> VLC in the questionable countries may have decided they'll take the > >> risk. > >> The USA is the obvious problem country there... > > > > But what kind of legal risk are we talking about here? > > The same one Redhat / Fedora don't like at all, and which SUSE is > working around... Well Redhat got burned on MP3 patents in the past. That's why they are afraid of everything multimedia and patents. But the truth is this is mainly an excuse: they do ship Gstreamer, and it has the same patents issues and a similar architecture to libVLC. > > I can't really see why VLC would be worse than pretty much anything else we > > ship in terms of patents, for example (there are patents covering a ton of > > stuff we do). It's not. VLC does not implement codecs, not more than gstreamer, and is a framework with numerous modules (400 in your average linux install), like gstreamer or any other sane multimedia framework. Patents are in those codec libraries, not in VLC. VLC does not break any DRM, libdvdcss or libaacs do. Noone needs to ship those. The true reason is that they have GStreamer, and they ship GStreamer, and it's hard enough that they don't want another one to ship. But GStreamer is very tied to Gnome technologes and is a key part of GnomeOS and the new technologies (PulseVideo/Pinos). So far, it's hard to use without PackageKit and they don't care if they break other use cases... The only good reason I've seen was that we have one tarball, instead of one per module. With my kindest regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Thanks Konrad! Offers to help update: - Stefan Dertkis (original poster, coder?) - Eshtan Robateau (architect? + coder?) - Olivier Churlaud (architect? + coder?) - Konrad Renner (test + coder?) - Andrew Lake (UI design + architecture support if needed) + VDG :-) On Tue, Aug 4, 2015 at 12:42 PM Ing. Konrad Renner wrote: > 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 > > ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Another offers to help update: - Stefan Dertkis (original poster, coder?) - Eshtan Robateau (architect? + coder?) - Olivier Churlaud (architect? + coder?) - Konrad Renner (test + coder?) - Rishabh Gupta (coder) - Andrew Lake (UI design + architecture support if needed) + VDG :-) ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
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-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
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 : > > 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-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Wow, go for a short one-week holiday and the world explodes On Thu, Jul 30, 2015 at 1:30 PM, Teo Mrnjavac wrote: > On Thursday, July 30, 2015 12:42:14 Stefan Derkits wrote: >> Dear all, >> >> in discussions during Akademy 2015 we found out that while we have with >> Plasma 5 a Desktop that has a modern & consistent look, the state of >> some applications isn't that good. And we want to change that. >> >> At the moment KDE has no up-to-date music player. JuK is very simple to >> use, but lacking a modern design. Amarok is and will stay the >> swiss-knife of KDE music players, but also lacking a modern design and >> may be too complicated for new users. >> >> So let's make a new music player, a successor especially to JuK & Bangarang. >> A music player not for power users or music enthusiasts that want/need 100s >> of features in a player but a simple player designed & made for users of >> the Plasma 5 Desktop. >> >> What do we already have: >> -) A design vision by the VDG including UI mockups & user stories [0] >> >> What do we need: >> -) 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 >> >> 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. >> >> So if you are interested, contact me either in person on Akademy, on IRC >> (HorusHorrendus @ freenode) or via mail (stefan [at] derkits.at) >> > > Excellent idea, a no-nonsense "thing that opens audio files" is much needed. > > Have you thought about picking up and taking over Amarok? A quick look at the > commit log for the past few months suggests that it's essentially > unmaintained, so if it keeps this pace it's unlikely to stay the swiss-knife > of music players as you suggest. I answer here as it would be a tad tedious to respond to all individually: Amarok is NOT unmaintained, we just had some difficulties with a very resistant release-blocker, and sadly the key devs who were supposed to do the release just disappeared into oblivion. So much for "I have time at my new job to work on Amarok, I will do the release soon, I do merge the GSoC work,etc". Sorry if I sound a tad pissed, because I have heard a lot of these and since that person had time to attend Akademy, he could also have finished the work he promised... Currently a 2.9 beta tarball is ready, I just need some help to do the release text and other stuff, as I too have a job that takes on my time. Also, we have started the Qt5 port of Amarok (current WIP as a GSoC task), and Mark also has some ideas on how to make Amarok a tad leaner. If you did follow planetkde you would all know about, btw... So please do not jump to conclusions just because we didn't have many commits lately. FWIW: the current git status is +595 from the last release, and AFAICS there is quite some unfinished work from the previous GSoC students that is just waiting to be merged (CD stack, for instance, which the GSoC mentor told me he would merge). There is only so much I can do, and I am NOT a developer, and Mark has a full-time job that doesn't leave much time And YES, we could need some help for the Qt5 port, as it is a lot of work for just 2 devs. Regards, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On Tue, Aug 04, 2015 at 10:53:16PM +1200, Ben Cooksley wrote: > On Tue, Aug 4, 2015 at 10:38 PM, Martin Sandsmark > wrote: > > But what kind of legal risk are we talking about here? > The same one Redhat / Fedora don't like at all, and which SUSE is > working around... But what are these? I've never heard anything concrete, which makes it extremely hard to try to get something done. It would be nice if we knew why they don't want to ship VLC, both so we can try to resolve it, and so we also know what to do to avoid them suddenly deciding that they can't ship some software we write. -- Martin Sandsmark ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On Mon, Aug 03, 2015 at 09:13:20AM +0200, kainz.a wrote: > Jens from the VDG is in contact with the VLC dev's and they ask some times > ago about an design proposal so in future it could be that VLC is > influenced by the VDG. This is good! But I think it makes sense for us in the KDE community to help out a bit here as well. For us we gain a player with very good integration with Plasma, they gain a really nice interface. The VLC developers also have a lot of things on their plate, and I'm not sure if a revamp of their UI is high on the priority list. I can probably do it myself, but as I work fulltime, I don't really have that much time I can dedicate to things like this. But the initial implementation is what would take time, maintaining just the UI module even I should have time to do. And if more people want to help out with the initial creation, we could probably arrange a tiny sprint to kickstart it. > In addition VLC is theme-able. I made an theme for smplayer and it looks > realy nice in plasma ( > http://forum.smplayer.info/viewtopic.php?f=7&t=8050&p=14312#p14312). I like > the posibility of different designs on different desktops and I'd like to > work on an VLC breeze theme (vision) too. I't doesn't depend on the the > outcome of this task. That looks really nice! > For me VLC is a great player and a lot of people knows him. The player is > well maintained. The questions are how the collaboration would work on the > code base. How deep the kde integration should be (baloo, plasma mobile). > Licence issues, ... Well, I'm fairly certain that the VLC people are pretty open for contributions from KDE. As for the various things we can do to integrate, I don't really see what we would gain from integrating with baloo at all. If people actually have some problem with VLC that would be solved with Baloo, though, we can probably write a module to handle that (probably disabled by default, or just living out of the tree even). For Plasma Mobile I don't see why they wouldn't use VLC, especially if we make a kick-ass qml-based UI for it. I don't see what licensing issues there would be, the core parts of VLC are lgpl 2+, and the rest is gpl2+, pretty much the same as almost everything else in KDE. -- Martin Sandsmark ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Hi, the player (no matter if it is Amarok, JuK or a new one) must be integrated well in Plasma (eg usage of baloo for ratings, tags). If I use Plasma, it does not matter for me if it runs standalone on eg Windows. By the way: Are there any plans to port Bangarang to Plasma 5 and baloo? Sidenote: I think baloo uses the "extended file attributes". The digikam guys already worked on porting a nepomuk backend to baloo, so maybe they can help with their experience. You can find some details here: https://bugs.kde.org/show_bug.cgi?id=332665 Yours, Konrad Am 01.08.2015 12:05 vorm. schrieb Stefan Derkits : > > Hi, > > On 2015-07-31 23:43, kainz.a wrote: > > what's the problem with using Amarok? In kde4 times they are the first > > application that use plasma. now I think an qt 5 port is still open so this > > would be the perfect time to get into an redesign isn't it? If the amarok > > developers don't like an redesign (what I can understand, because the last > > redesign was not that fun) maybe with the port to qt5 the UI can be more > > separate so a lot of code can be shared. > > as I wrote in my previous mails, nothing is set in stone yet. > > But this will (most probably) not be something like Amarok 3. Why not? > One thing is that you can't throw away probably 70 % of the features, > never ever accept those features back into the application (remember: > This should be a simple music player, designed for "standard" users of > Plasma 5, not users that want to use tons of features in their music > player) and call it Amarok. > > Codebase could probably be shared, but it seems easier to start from a > simpler (e.g. the PMC) codebase. But that is a technical decision that > will be done when a team has formed :) > > > baloo integration is for me a must, because plasma offers this and so we > > should use it. > > If using baloo fits into the vision (which I think would fit because > non-experienced users maybe don't know where there music is), why not > use it. PMC uses it, Bangarang used Nepomuk. > > Stefan > > ___ > kde-multimedia mailing list > kde-multime...@kde.org > https://mail.kde.org/mailman/listinfo/kde-multimedia ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
With tags you are right, but the use case for ratings is: I rate a file in Dolphin and this rating should also be used in the music player and vice versa. This would also be useful if there is a multimedia app (maybe a ported Bangarang) which can use the same ratings. Am 01.08.2015 3:49 nachm. schrieb Stefan Derkits : > > Hello, > > On 2015-08-01 08:47, Ing. Konrad Renner wrote: > > the player (no matter if it is Amarok, JuK or a new one) must be integrated > > well in Plasma (eg usage of baloo for ratings, tags). If I use Plasma, it > > does not matter for me if it runs standalone on eg Windows. > > I see a use case for Baloo for finding music files, but probably not for > ratings & tags. While Tags (if done correctly, for music files this also > includes Ratings [0]) could be read by Baloo via the TaglibExtractor of > KFileMetadata, I heard that those attributes can't be written back to > Tags by Baloo. > > So what would be the Use Case for write Tags to extended File attributes > via Baloo instead of correctly writing them via taglib? > > Stefan > > ___ > kde-multimedia mailing list > kde-multime...@kde.org > https://mail.kde.org/mailman/listinfo/kde-multimedia ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Hi! On Sat, Aug 01, 2015 at 08:47:48AM +0200, Ing. Konrad Renner wrote: > the player (no matter if it is Amarok, JuK or a new one) must be integrated > well in Plasma (eg usage of baloo for ratings, tags). If I use Plasma, it > does not matter for me if it runs standalone on eg Windows. Thinking a bit about this, and considering that it seems like there so far hasn't been anyone piping up willing to be a maintainer for a new player like this, I think it makes more sense to look at an existing player, and see if we can improve that instead, instead of trying to start something new (and with "new" I also mean trying to re-boot e. g. amarok or juk). For example VLC has an extremely modular architecture, everything in VLC is basically a plugin/module, including the user interfaces (in case everyone doesn't know, it actually has several different user interfaces already). An idea I've been toying with is to try to write a QML based UI module for VLC, and then I think it makes a lot of sense to base it on the sexy mockups from the VDG. I'm thinking that other kinds of integration functionality (activity-awareness, for example) should be possible to put in a module for VLC as well. If more people are interested in this, maybe we could arrange a small sprint to get this off the ground (the Videolan organization has already sponsored at least one tiny KDE Multimedia sprint, and without asking jbk there might be a chance they'd help out here as well). As I mentioned elsewhere, I myself sold my soul and just use Spotify 90% of the time, so I don't really want to or have the time to maintain a full music player application. But implementing and just maintaining a UI module for e. g. VLC is something that makes more sense for me. Another idea might be to collaborate with the Tomahawk people to see if there's anything we can do there to make it integrate better with Plasma. So, I guess my point can be summarized as a suggestion to instead of trying to start something new on our own, rather try to work with someone established elsewhere (outside of KDE, even). -- Martin Sandsmark ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On Sun, Aug 02, 2015 at 06:12:16PM +0200, Valentin Rusu wrote: > Reusing VLC is a very good idea. I find myself using it in almost all > use-cases, let it be playing a local video file or streaming some > hard-to-decode video from my powerful laptop to the RasberryPI. It also has a media library, actually, and works pretty well as a music player. The problem (IMHO) is the UI; it's not very sexy, and not very newbie-friendly either. Exposing the all the power it has while presenting a clean and intuitive UX is not very easy, but I don't think it is unreasonably hard either. That said, I'm not too familiar with Tomahawk, but I suspect it might already cover more of what people want from a pure music player. But someone who is more familiar with it chime in with what it is missing wrt. integration in Plasma, and then we can see how hard those things are to fix. -- Martin Sandsmark ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On Tue, Aug 04, 2015 at 10:41:45AM +0200, Harald Sitter wrote: > During last akademy I brought up the possibility of killing > phonon-gstreamer and going vlc-only in Phonon. While this discussion > happened on a private packager list I can not point to it but the gist > of it was that Fedora doesn't have VLC, OpenSUSE has a "crippled" VLC > and Slackware doesn't have any packages and probably will not ever. Why don't they provide VLC? > KDE Sysadmins raised concerns that we wouldn't be able to provide VLC > in any sort of bundled binary fashion as our mirror network covers > many jurisdictions where VLC might be problematic (not that I think we > would want to distribute binaries containing VLC anyway although it is > very much a possibility with windows/osx I have been told). Videolan itself has a ton of mirrors all over the world, which parts of the world does KDE have mirrors that Videolan doesn't? (And also same question as above.) And in my humble opinion, that some distros cripple themselves shouldn't be our problem... If a distro doesn't provide what users need, users should use another distro. -- Martin Sandsmark ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
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. --___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On Tue, Aug 04, 2015 at 10:28:35PM +1200, Ben Cooksley wrote: > We can't speak for our mirrors in terms of legal risk - those hosting > VLC in the questionable countries may have decided they'll take the > risk. > The USA is the obvious problem country there... But what kind of legal risk are we talking about here? I can't really see why VLC would be worse than pretty much anything else we ship in terms of patents, for example (there are patents covering a ton of stuff we do). If it is the DVD de-scrambling that is in a separate library, and AFAIK it is fairly straight-forward to just build libdvdread and/or VLC without that dependency. From some simple googling it seems like fedora already ships a libdvdread without de-scrambling enabled, for example. -- Martin Sandsmark ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Am 2015-08-01 17:14, schrieb Vishesh Handa: > These are just some of the cases. Often the solution is just to roll > your own thing. > > Also, I liked having my own database in Jungle and Koko, as they could > then store the data explicitly how they want, and create relevant > indexes. In Koko, I eventually made Baloo optional. Specially since > Baloo has not been (yet?) ported for the Plasma Phone. IMHO when a new software is "created/designed for Plasma" it should integrate tight with other parts of the environment. Because it is designed for this special desktop environment, the goal is not that it is used with this other fancy desktop environment (do the GNOME devs care if GNOME music integrate well on the Plasma desktop?). It should feel like "all was made of one piece". If the software is not "created/designed for Plasma" one can be aware that this software maybe does not integrate well. E.g.: I import some pictures with a "Plasma picture editor app" from my camera, rate the files and attach the tag "holiday". Some days later I want to present my "holiday" pictures friends, but the pictures should have minimum rating of 3 stars (because I don't want to show my friends pictures which are "not so good"), with the "Plasma picture viewer". Maybe a year later I want to find all "holiday" pictures from 2014 and 2015 with the "Plasma file browser", so that I can burn them on a disk for backup. The same is true for a Plasma music application: if it uses its own system for ratings, a possible new "Plasma multimedia application" cannot use this informations and so a user has to define them for each application. And I think the user will not be satisified, if he has to create the same ratings for the same files, in each application he uses. I think to reinvent the wheel for each application cannot be the goal. -- Mit freundlichen Grüßen Ing. Konrad Renner ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
* Martin Sandsmark [2015-08-02 17:31:51 +0200]: > Hi! > > On Sat, Aug 01, 2015 at 08:47:48AM +0200, Ing. Konrad Renner wrote: > > the player (no matter if it is Amarok, JuK or a new one) must be integrated > > well in Plasma (eg usage of baloo for ratings, tags). If I use Plasma, it > > does not matter for me if it runs standalone on eg Windows. > > Thinking a bit about this, and considering that it seems like there so far > hasn't been anyone piping up willing to be a maintainer for a new player like > this, I think it makes more sense to look at an existing player, and see if > we can improve that instead, instead of trying to start something new (and > with "new" I also mean trying to re-boot e. g. amarok or juk). > > For example VLC has an extremely modular architecture, everything in VLC is > basically a plugin/module, including the user interfaces (in case everyone > doesn't know, it actually has several different user interfaces already). An > idea I've been toying with is to try to write a QML based UI module for VLC, > and then I think it makes a lot of sense to base it on the sexy mockups from > the VDG. I'm thinking that other kinds of integration functionality > (activity-awareness, for example) should be possible to put in a module for > VLC as well. > Reusing VLC is a very good idea. I find myself using it in almost all use-cases, let it be playing a local video file or streaming some hard-to-decode video from my powerful laptop to the RasberryPI. -- Valentin Rusu IRC: valir ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On Friday, July 31, 2015 07:32:05 PM Boudhayan Gupta wrote: > On 31 July 2015 at 06:53, Michael Pyne wrote: > > It's basically still a KDE 3 app that got only partially ported to KDE > > 4... > > > > IMHO some kind of rewrite using taglib and Phonon and a very simple GUI > > would be the best way to go for KDE 5. Martin Sandsmark was working on a > > better port but it's a surprisingly annoying task due to bitrot. > > Would there be objections if JuK was ported straight to KF5, losing > functionality if necessary (as in, screw the features, we want a clean > KF5-based implementation first), upon which we can re-add the features > that are most demanded later? Personally, I have no problem with a stripped down player that we can then build up more cleanly (nothing feels better than deleting code!). But this would be a good chance to see what features should be slated to be added so people know what to expect as well what things were roadblocks in other media players in KDE. > People did complain that during the transition from KDE3 to Plasma 4, > a lot of functionality was lost, but eventually it all came back, and > today we have a much cleaner codebase while Plasma itself a lot more > moddable, for lack of a better term. Push-back is inevitable, tbh but it doesn't linger as long as legacy code, no? > Another thing is, do we really want to port to Phonon 5, or can we > port to QtMultimedia? I'm not sure of the pros/cons of either, so I'm > just asking. Er, so would using QtMultimedia allow for less dependencies to be pulled in when used outside of KDE? I figure that this is something people might like (but not necessarily the target for something to be PART of the KDE suite). > > -- Boudhayan Gupta > ___ > Amarok-devel mailing list > Amarok-devel@kde.org > https://mail.kde.org/mailman/listinfo/amarok-devel S -- Jacky Alciné - https://jacky.wtf Work: https://jacky.wtf/work --- They can READ + SEE everything in this email. In your texts. The NSA's been spying on US citizens for too long. Read more: https://www.eff.org/nsa-spying signature.asc Description: This is a digitally signed message part. ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On Sat, Aug 1, 2015 at 3:40 AM, Be wrote: > > > On 07/30/2015 07:08 AM, Martin Steigerwald wrote: > > So instead of 3, 4, 5 or more KDE/Qt based music players I´d rather see >> one or >> two. I´d envision something like the Plasma devs did for Plasma. Make one >> extensible core and give it several faces. Make one player core that for a >> change is absolutely solid and robust – I still have bugs with Phonon >> without >> Pulseaudio here and with Pulseaudio I also have bugs – and then build upon >> that core and simple interfaces and an advanced interface. >> >> > Would a common media database library would be a good idea? What else do > music players have as a common core other than playback, which is already > handled by the Phonon library? +1 for a shared media database library. This is something I always wished was available because all the players reinvent this more or less. > > > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe >>> << >>> >> -- Shantanu Tushar(UTC +0530) shantanu.io ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On Tue, Aug 4, 2015 at 10:38 PM, Martin Sandsmark wrote: > On Tue, Aug 04, 2015 at 10:28:35PM +1200, Ben Cooksley wrote: >> We can't speak for our mirrors in terms of legal risk - those hosting >> VLC in the questionable countries may have decided they'll take the >> risk. >> The USA is the obvious problem country there... > > But what kind of legal risk are we talking about here? The same one Redhat / Fedora don't like at all, and which SUSE is working around... > > I can't really see why VLC would be worse than pretty much anything else we > ship in terms of patents, for example (there are patents covering a ton of > stuff we do). > > If it is the DVD de-scrambling that is in a separate library, and AFAIK it is > fairly straight-forward to just build libdvdread and/or VLC without that > dependency. From some simple googling it seems like fedora already ships a > libdvdread without de-scrambling enabled, for example. > > -- > Martin Sandsmark Regards, Ben > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On Tue, Aug 4, 2015 at 10:18 PM, Martin Sandsmark wrote: > On Tue, Aug 04, 2015 at 10:41:45AM +0200, Harald Sitter wrote: >> During last akademy I brought up the possibility of killing >> phonon-gstreamer and going vlc-only in Phonon. While this discussion >> happened on a private packager list I can not point to it but the gist >> of it was that Fedora doesn't have VLC, OpenSUSE has a "crippled" VLC >> and Slackware doesn't have any packages and probably will not ever. > > Why don't they provide VLC? > > >> KDE Sysadmins raised concerns that we wouldn't be able to provide VLC >> in any sort of bundled binary fashion as our mirror network covers >> many jurisdictions where VLC might be problematic (not that I think we >> would want to distribute binaries containing VLC anyway although it is >> very much a possibility with windows/osx I have been told). > > Videolan itself has a ton of mirrors all over the world, which parts of the > world does KDE have mirrors that Videolan doesn't? (And also same question > as above.) We can't speak for our mirrors in terms of legal risk - those hosting VLC in the questionable countries may have decided they'll take the risk. The USA is the obvious problem country there... > > And in my humble opinion, that some distros cripple themselves shouldn't be > our problem... If a distro doesn't provide what users need, users should use > another distro. > > -- > Martin Sandsmark Cheers, Ben > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On Sun, Aug 2, 2015 at 5:31 PM, Martin Sandsmark wrote: > VLC is something that makes more sense for me. Not disagreeing or anything since it is a well known fact that I am a VLC fanboy :P BUT During last akademy I brought up the possibility of killing phonon-gstreamer and going vlc-only in Phonon. While this discussion happened on a private packager list I can not point to it but the gist of it was that Fedora doesn't have VLC, OpenSUSE has a "crippled" VLC and Slackware doesn't have any packages and probably will not ever. KDE Sysadmins raised concerns that we wouldn't be able to provide VLC in any sort of bundled binary fashion as our mirror network covers many jurisdictions where VLC might be problematic (not that I think we would want to distribute binaries containing VLC anyway although it is very much a possibility with windows/osx I have been told). Back then we actually outlined ways for Fedora to also ship a crippled VLC. From what I have heard rumor-wise that went nowhere on account of red hat not wanting anything even remotely problematic on their servers, which seems very reasonable considering they are a US based company. At any rate though a VLC on Fedora will be worse off than a GStreamer based thing. Unlike GStreamer [1] there is no built-in runtime installer for VLC right now, so if one were to pursue this and doesn't want subpar experience on some distributions at the very least one would also need to craft a plugin installer. And TBH, having silly installer dialogs pop up when trying to watch porn kinda screws up the whole experience :P Anyway, just something more to consider. [1] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-gstpbutilsinstallplugins.html HS ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
2015-08-02 20:35 GMT+02:00 Martin Sandsmark : > On Sun, Aug 02, 2015 at 06:12:16PM +0200, Valentin Rusu wrote: > > Reusing VLC is a very good idea. I find myself using it in almost all > > use-cases, let it be playing a local video file or streaming some > > hard-to-decode video from my powerful laptop to the RasberryPI. > > It also has a media library, actually, and works pretty well as a music > player. > > The problem (IMHO) is the UI; it's not very sexy, and not very > newbie-friendly either. Exposing the all the power it has while presenting > a > clean and intuitive UX is not very easy, but I don't think it is > unreasonably > hard either. > Hi, Jens from the VDG is in contact with the VLC dev's and they ask some times ago about an design proposal so in future it could be that VLC is influenced by the VDG. In addition VLC is theme-able. I made an theme for smplayer and it looks realy nice in plasma ( http://forum.smplayer.info/viewtopic.php?f=7&t=8050&p=14312#p14312). I like the posibility of different designs on different desktops and I'd like to work on an VLC breeze theme (vision) too. I't doesn't depend on the the outcome of this task. For me VLC is a great player and a lot of people knows him. The player is well maintained. The questions are how the collaboration would work on the code base. How deep the kde integration should be (baloo, plasma mobile). Licence issues, ... Cheers Andreas ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Ahoy ahoy, ramblings ahead! On Thu, Jul 30, 2015 at 12:42 PM, Stefan Derkits 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
Re: Help wanted to evolve KDEs music players
On Sat, Aug 1, 2015 at 3:49 PM, Stefan Derkits wrote: > Hello, > > On 2015-08-01 08:47, Ing. Konrad Renner wrote: >> the player (no matter if it is Amarok, JuK or a new one) must be integrated >> well in Plasma (eg usage of baloo for ratings, tags). If I use Plasma, it >> does not matter for me if it runs standalone on eg Windows. > > I see a use case for Baloo for finding music files, but probably not for > ratings & tags. While Tags (if done correctly, for music files this also > includes Ratings [0]) could be read by Baloo via the TaglibExtractor of > KFileMetadata, I heard that those attributes can't be written back to > Tags by Baloo. Correct. And they never will be. Perhaps via KFileMetaData, but at that point you're just using a light wrapper on top of TagLib, and you may as well use TagLib. > > So what would be the Use Case for write Tags to extended File attributes > via Baloo instead of correctly writing them via taglib? Since Baloo has been mentioned, I thought I should chime in; Currently, Baloo is just a file indexing and searching solution. That's it. I've done a video player (Jungle) and an Image application (Koko), in both cases I tried to use Baloo in order to search for all videos and images. It was trivial and required 4-10 lines of code. However, I also had to deal with the following cases - * Baloo is disabled * Your image folder is in the exclude folders list * Your Image folder has not yet been indexed, cause of reason x * Your image folder is currently being indexed, and you need to wait. * The correct file indexing plugins are not installed and therefore Baloo does not get any Image (or Video) file metadata These are just some of the cases. Often the solution is just to roll your own thing. Also, I liked having my own database in Jungle and Koko, as they could then store the data explicitly how they want, and create relevant indexes. In Koko, I eventually made Baloo optional. Specially since Baloo has not been (yet?) ported for the Plasma Phone. -- Vishesh Handa ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Hello, On 2015-08-01 08:47, Ing. Konrad Renner wrote: > the player (no matter if it is Amarok, JuK or a new one) must be integrated > well in Plasma (eg usage of baloo for ratings, tags). If I use Plasma, it > does not matter for me if it runs standalone on eg Windows. I see a use case for Baloo for finding music files, but probably not for ratings & tags. While Tags (if done correctly, for music files this also includes Ratings [0]) could be read by Baloo via the TaglibExtractor of KFileMetadata, I heard that those attributes can't be written back to Tags by Baloo. So what would be the Use Case for write Tags to extended File attributes via Baloo instead of correctly writing them via taglib? Stefan signature.asc Description: OpenPGP digital signature ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On 07/30/2015 07:08 AM, Martin Steigerwald wrote: So instead of 3, 4, 5 or more KDE/Qt based music players I´d rather see one or two. I´d envision something like the Plasma devs did for Plasma. Make one extensible core and give it several faces. Make one player core that for a change is absolutely solid and robust – I still have bugs with Phonon without Pulseaudio here and with Pulseaudio I also have bugs – and then build upon that core and simple interfaces and an advanced interface. Would a common media database library would be a good idea? What else do music players have as a common core other than playback, which is already handled by the Phonon library? ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Hi, On 2015-07-31 23:43, kainz.a wrote: > what's the problem with using Amarok? In kde4 times they are the first > application that use plasma. now I think an qt 5 port is still open so this > would be the perfect time to get into an redesign isn't it? If the amarok > developers don't like an redesign (what I can understand, because the last > redesign was not that fun) maybe with the port to qt5 the UI can be more > separate so a lot of code can be shared. as I wrote in my previous mails, nothing is set in stone yet. But this will (most probably) not be something like Amarok 3. Why not? One thing is that you can't throw away probably 70 % of the features, never ever accept those features back into the application (remember: This should be a simple music player, designed for "standard" users of Plasma 5, not users that want to use tons of features in their music player) and call it Amarok. Codebase could probably be shared, but it seems easier to start from a simpler (e.g. the PMC) codebase. But that is a technical decision that will be done when a team has formed :) > baloo integration is for me a must, because plasma offers this and so we > should use it. If using baloo fits into the vision (which I think would fit because non-experienced users maybe don't know where there music is), why not use it. PMC uses it, Bangarang used Nepomuk. Stefan signature.asc Description: OpenPGP digital signature ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
what's the problem with using Amarok? In kde4 times they are the first application that use plasma. now I think an qt 5 port is still open so this would be the perfect time to get into an redesign isn't it? If the amarok developers don't like an redesign (what I can understand, because the last redesign was not that fun) maybe with the port to qt5 the UI can be more separate so a lot of code can be shared. baloo integration is for me a must, because plasma offers this and so we should use it. ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On Thu, July 30, 2015 15:06:46 Stefan Derkits wrote: > Hi, > > On 2015-07-30 14:08, Martin Steigerwald wrote: > > Why a new one? Aren´t none of the existing ones in a state that they can´t > > be evolved into what you envision? > > > > There is already Amarok, JuK, Bangarang, Clementine, Plasma Media Center > > and you name it. As a user I am confused. Which do I use? Well for me I > > started with Amarok and I really do like it a lot, just want to see it > > modernized instead of looking at all the others to find out which new one > > to use. > At the moment the only thing we have is a design vision. Of course this > vision replaces most of the things that JuK and Bangarang does. Also > Andrew Lake is the Creator of Bangarang and he is the one who started > the UI mockups & vision development, so you can see it as a replacement > of Bangarang (probably with a new name). JuK has a simillar feature set > than what is planned, but I don't know in what shape the codebase is. It's basically still a KDE 3 app that got only partially ported to KDE 4... IMHO some kind of rewrite using taglib and Phonon and a very simple GUI would be the best way to go for KDE 5. Martin Sandsmark was working on a better port but it's a surprisingly annoying task due to bitrot. Regards, - Michael Pyne ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Hello! I've probably missed some previous conversations, but how about take a look at mopidy and deskop client for this music server? [1] [1] https://www.mopidy.com/ чт, 30 июля 2015 г. в 14:30, Teo Mrnjavac : > On Thursday, July 30, 2015 12:42:14 Stefan Derkits wrote: > > Dear all, > > > > in discussions during Akademy 2015 we found out that while we have with > > Plasma 5 a Desktop that has a modern & consistent look, the state of > > some applications isn't that good. And we want to change that. > > > > At the moment KDE has no up-to-date music player. JuK is very simple to > > use, but lacking a modern design. Amarok is and will stay the > > swiss-knife of KDE music players, but also lacking a modern design and > > may be too complicated for new users. > > > > So let's make a new music player, a successor especially to JuK & > Bangarang. > > A music player not for power users or music enthusiasts that want/need > 100s > > of features in a player but a simple player designed & made for users of > > the Plasma 5 Desktop. > > > > What do we already have: > > -) A design vision by the VDG including UI mockups & user stories [0] > > > > What do we need: > > -) 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 > > > > 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. > > > > So if you are interested, contact me either in person on Akademy, on IRC > > (HorusHorrendus @ freenode) or via mail (stefan [at] derkits.at) > > > > Excellent idea, a no-nonsense "thing that opens audio files" is much > needed. > > Have you thought about picking up and taking over Amarok? A quick look at > the > commit log for the past few months suggests that it's essentially > unmaintained, so if it keeps this pace it's unlikely to stay the > swiss-knife > of music players as you suggest. > > This stuff is hard and time consuming so I think it makes sense to reuse > code. > > While Amarok does have a sizeable feature set, a good portion of those > features are either poorly designed, broken or outdated. Perhaps by taking > over as maintainer, yanking out all the cruft and taking UX hints from the > VDG > you could get a modern and pretty music player up and running more quickly > and > easily than jumping into the umpteenth "magic rewrite that will fix all > things > forever". You could cut down on the feature set significantly, and present > the > features that you don't remove in a much better way. > > Cheers, > -- > Teo Mrnjavac > http://teom.org | t...@kde.org > ___ > Amarok-devel mailing list > Amarok-devel@kde.org > https://mail.kde.org/mailman/listinfo/amarok-devel > ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On Thursday 30 July 2015, Stefan Derkits wrote: > Hello Teo, > > On 2015-07-30 13:30, Teo Mrnjavac wrote: > > Have you thought about picking up and taking over Amarok? A quick look at > > the commit log for the past few months suggests that it's essentially > > unmaintained, so if it keeps this pace it's unlikely to stay the > > swiss-knife of music players as you suggest. > > > > This stuff is hard and time consuming so I think it makes sense to reuse > > code. > > > > While Amarok does have a sizeable feature set, a good portion of those > > features are either poorly designed, broken or outdated. Perhaps by > > taking over as maintainer, yanking out all the cruft and taking UX hints > > from the VDG you could get a modern and pretty music player up and > > running more quickly and easily than jumping into the umpteenth "magic > > rewrite that will fix all things forever". You could cut down on the > > feature set significantly, and present the features that you don't > > remove in a much better way. > > thanks for your answer. > > I was definitly thinking about starting (actually I don't feel confident > enough to create the architecture) from an existing codebase, but > probably not from the Amarok codebase (except of reusing some parts). I > also talked with strohel at Akademy who has a better knowledge of the > codebase and his opinion was that UI & backendcode are too much > intertwined to allow replacing the UI easily. > > What I don't want to do is to take over Amarok. While it is true that > Amarok is pretty much unmaintained, I don't think a player that has > maybe only a third of the features should be called Amarok. > As long as it does the core functionality that users of Amarok uses (indexing and playing audio), and the Amarok team are on board, it shouldn't be a problem. It IS a large codebase however. Just remember while a simple audio player is simple to write, the hard part is the audio indexing and cataloging, and dealing with third party plugin for the popular internet audio products de jure. `Allan ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On 31 July 2015 at 06:53, Michael Pyne wrote: > It's basically still a KDE 3 app that got only partially ported to KDE 4... > > IMHO some kind of rewrite using taglib and Phonon and a very simple GUI would > be the best way to go for KDE 5. Martin Sandsmark was working on a better port > but it's a surprisingly annoying task due to bitrot. Would there be objections if JuK was ported straight to KF5, losing functionality if necessary (as in, screw the features, we want a clean KF5-based implementation first), upon which we can re-add the features that are most demanded later? People did complain that during the transition from KDE3 to Plasma 4, a lot of functionality was lost, but eventually it all came back, and today we have a much cleaner codebase while Plasma itself a lot more moddable, for lack of a better term. Another thing is, do we really want to port to Phonon 5, or can we port to QtMultimedia? I'm not sure of the pros/cons of either, so I'm just asking. -- Boudhayan Gupta ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On 30 July 2015 at 11:42, Stefan Derkits wrote: > At the moment KDE has no up-to-date music player. JuK is very simple to > use, but lacking a modern design. Amarok is and will stay the > swiss-knife of KDE music players, but also lacking a modern design and > may be too complicated for new users. > > So let's make a new music player, a successor especially to JuK & Bangarang. > A music player not for power users or music enthusiasts that want/need > 100s of features in a player but a simple player designed & made for > users of the Plasma 5 Desktop. 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. Then again, a very simple default audio player is something that is attractive in the desktop, I know it's all I want which is why I use juk. My simple advice: merge, juk, kscd, kaudiocreator and add some internet radio stream playing (a lot of the code is in shared libraries already) and launch it as a new application in Extragear. Then we retire kdemultimedia as a module. Target the simplest possible feature set for playing/ripping the most common audio only. Personally, I think a CD/MP3 player/manager/ripper and an online radio stream player/manager is all we need in a simple default audio player. Adding streaming music services like Spotify or whatever greatly complicates matters, if you support a couple of online services, then people ask why you don't support the one they use, you end up at Amarok, or with lots of unmaintained or broken plugins that you can't support. Same for video. Something to be very wary of is the fate of Dragon Player: it was only intended as a very basic player for quickly viewing files, almost a test-bed for Phonon video, but people misunderstood it, expected it to do more, and came away disappointed and judgemental. We would almost have been better not shipping it as an app I think and only a plugin/kpart. For video playing, VLC is miles ahead, we should work with them instead to integrate into KDE better. For a full media player/manager combining them all, leave that to PMC. But remember the KDE way: make lots of reusable libraries for each function, design a plugin infrastructure that suits different scenarios, reuse as much as possible and don't try reinvent what others have already done. Think Kipi or similar. > [0] https://community.kde.org/KDE_Visual_Design_Group/Music_Player Nice designs, wrap those around juk's well-tested backend and we're done! John. ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Am Donnerstag, 30. Juli 2015, 13:30:00 schrieb Teo Mrnjavac: > On Thursday, July 30, 2015 12:42:14 Stefan Derkits wrote: > > Dear all, > > > > in discussions during Akademy 2015 we found out that while we have with > > Plasma 5 a Desktop that has a modern & consistent look, the state of > > some applications isn't that good. And we want to change that. > > > > At the moment KDE has no up-to-date music player. JuK is very simple to > > use, but lacking a modern design. Amarok is and will stay the > > swiss-knife of KDE music players, but also lacking a modern design and > > may be too complicated for new users. > > > > So let's make a new music player, a successor especially to JuK & > > Bangarang. A music player not for power users or music enthusiasts that > > want/need 100s of features in a player but a simple player designed & > > made for users of the Plasma 5 Desktop. > > > > What do we already have: > > -) A design vision by the VDG including UI mockups & user stories [0] > > > > What do we need: > > -) 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 > > > > 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. > > > > So if you are interested, contact me either in person on Akademy, on IRC > > (HorusHorrendus @ freenode) or via mail (stefan [at] derkits.at) > > Excellent idea, a no-nonsense "thing that opens audio files" is much needed. > > Have you thought about picking up and taking over Amarok? A quick look at > the commit log for the past few months suggests that it's essentially > unmaintained, so if it keeps this pace it's unlikely to stay the swiss-knife > of music players as you suggest. > > This stuff is hard and time consuming so I think it makes sense to reuse > code. > > While Amarok does have a sizeable feature set, a good portion of those > features are either poorly designed, broken or outdated. Perhaps by taking > over as maintainer, yanking out all the cruft and taking UX hints from the > VDG you could get a modern and pretty music player up and running more > quickly and easily than jumping into the umpteenth "magic rewrite that will > fix all things forever". You could cut down on the feature set > significantly, and present the features that you don't remove in a much > better way. Wow, it seems we thought similar things at the same time. See my other post. However what ever the approach is: Rewrite and replace some existing or reuse and adapt it. Make it as robust and reliable as you can. Make it just work. 100% of the time (or at least 99,99%), like my CD player, like my Rockbox based Sansa e260. When I want to enjoy multimedia, I am absolutely not in the mood to discuss with unfinished and buggy software. Or to get a diploma about how the Linux audio stack works in order to find out what the issue is this time. Thanks, -- Martin ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Am Donnerstag, 30. Juli 2015, 12:42:14 schrieb Stefan Derkits: > Dear all, Hello Stefan, > in discussions during Akademy 2015 we found out that while we have with > Plasma 5 a Desktop that has a modern & consistent look, the state of > some applications isn't that good. And we want to change that. > > At the moment KDE has no up-to-date music player. JuK is very simple to > use, but lacking a modern design. Amarok is and will stay the > swiss-knife of KDE music players, but also lacking a modern design and > may be too complicated for new users. > > So let's make a new music player, a successor especially to JuK & Bangarang. > A music player not for power users or music enthusiasts that want/need 100s > of features in a player but a simple player designed & made for users of > the Plasma 5 Desktop. > > What do we already have: > -) A design vision by the VDG including UI mockups & user stories [0] Why a new one? Aren´t none of the existing ones in a state that they can´t be evolved into what you envision? There is already Amarok, JuK, Bangarang, Clementine, Plasma Media Center and you name it. As a user I am confused. Which do I use? Well for me I started with Amarok and I really do like it a lot, just want to see it modernized instead of looking at all the others to find out which new one to use. Creating a new one will split energies to another player. Unless it, as you suggest it being a successor of JuK & Bangarang, will succeed one or two of the existing ones. I looked at Bangarang, and liked the clean looks of it, but then it had several annoying bugs and was done with it. I didn´t even bother to report them. That is not to say that Amarok is free of bugs, but it definately does the basic job of playing music just fine for me. And frankly I do not bother about many of the extended feature so I wouldn´t even notice when some of them are buggy. But the player gets it mostly right for the basic job of playing music and browsing my collection. For me. So instead of 3, 4, 5 or more KDE/Qt based music players I´d rather see one or two. I´d envision something like the Plasma devs did for Plasma. Make one extensible core and give it several faces. Make one player core that for a change is absolutely solid and robust – I still have bugs with Phonon without Pulseaudio here and with Pulseaudio I also have bugs – and then build upon that core and simple interfaces and an advanced interface. But so or so I think what KDE/Plasma needs most in terms of multimedia is fixing of existing bugs like [Bug 339135] New: JBL Pepples USB laud speakers do not work without PulseAudio https://bugs.kde.org/339135 [Bug 339134] New: JBL Pepples USB laud speakers do not work without PulseAudio https://bugs.kde.org/339134 (My focus on Randa Meetings will be on KDEPIM, but I think I will bring this JBL Pebbles with me as well, in case someone wants to look at the issue together with me and help me to find the cause of it) and an audio stack that I as an user can either understand or, ideally and that I do not have to care about, cause it just works. With Pulseaudio and Phonon I have Pulseaudio, ALSA, Phonon, VLC or Gstreamer backends. And now when something is not working: Where exactly do I look? Who is responsible? Where do I report the bug? So for me also due to the following bug I took out Pulseaudio out of the equation already, simplifying things – I am grateful that Phonon still gives me the freedom to do that (despite above bugs): [Bug 85445] PlaneShift with OpenAL sound stutters: PulseAudio returned minreq tlength/2; expect break up https://bugs.freedesktop.org/show_bug.cgi?id=85445 (basically making the game unenjoyable to play) That are just three of the bugs that I didn´t even look out for, they found me. A new one is in VLC selecting a non-existing loud speaker by default requiring me to select the right one *each* time, stop the video and press play again. Friends that come to my place to watch movies with me often joke about this "Linux not working right". And heck, they do have a point. From what I see, also in discussions on debian-user-german and elsewhere, I got the impression that the Linux multimedia stack still needs a lot of work. I know not all of this is related to KDE/Plasma, but if there is one wish I have: It is about a player that *just* works. 100%. All of the time. A player I do not have to discuss with that it finally plays music. Right now, on above my hi-fi amplifier is a ThinkPad T42 with Amarok and for now it does the job, even after suspend/hibernate, cause Amarok stops playback then. But only… with the internal audio, not with the way better USB sound card. With audio and multimedia related issues I switch players often. For video I am with VLC, despite the bug, cause non of the KDE based players work satisfactorily for me. Kaffeine and Dragon Player do not work for me currently. I forgot about the issues they had, since I switched to
Re: Help wanted to evolve KDEs music players
why we can't use PMC as standard audio and video player? I think there was also an discussion about an standard video player so PMC is in our source and we don't have to start developing again. cheers Andreas ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Am Donnerstag, 30. Juli 2015, 15.16:56 schrieb Allan Sandfeld Jensen: Morning > > On 2015-07-30 13:30, Teo Mrnjavac wrote: > > > Have you thought about picking up and taking over Amarok? A quick look > > > at the commit log for the past few months suggests that it's > > > essentially unmaintained, so if it keeps this pace it's unlikely to > > > stay the swiss-knife of music players as you suggest. > > > > > > This stuff is hard and time consuming so I think it makes sense to > > > reuse code. > > > > > > While Amarok does have a sizeable feature set, a good portion of those > > > features are either poorly designed, broken or outdated. Perhaps by > > > taking over as maintainer, yanking out all the cruft and taking UX > > > hints from the VDG you could get a modern and pretty music player up > > > and running more quickly and easily than jumping into the umpteenth > > > "magic rewrite that will fix all things forever". You could cut down > > > on the feature set significantly, and present the features that you > > > don't remove in a much better way. > > > > thanks for your answer. > > > > I was definitly thinking about starting (actually I don't feel confident > > enough to create the architecture) from an existing codebase, but > > probably not from the Amarok codebase (except of reusing some parts). I > > also talked with strohel at Akademy who has a better knowledge of the > > codebase and his opinion was that UI & backendcode are too much > > intertwined to allow replacing the UI easily. > > > > What I don't want to do is to take over Amarok. While it is true that > > Amarok is pretty much unmaintained, I don't think a player that has > > maybe only a third of the features should be called Amarok. > > As long as it does the core functionality that users of Amarok uses > (indexing and playing audio), and the Amarok team are on board, it > shouldn't be a problem. It IS a large codebase however. Just remember > while a simple audio player is simple to write, the hard part is the audio > indexing and cataloging, Simple and maybe naive question: why not using Baloo for this. IIRC there was someting about a music or multimedia player using Baloo already. Jungle or so was it's preliminary name? > and dealing with third party plugin for the > popular internet audio products de jure. griits Mario ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Hello, On 2015-07-30 12:42, Stefan Derkits wrote: > What do we need: > -) 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 thank you all for your feedback, suggestions & offers for help. I've decided to move the discussion about this to the (until now unused) kde multimedia mailinglist, if you are interested, please join it [0]. Also we could use #kde-multimedia IRC channel on freenode for further discussions (my nick is HorusHorrendus). Stefan [0] https://mail.kde.org/mailman/listinfo/kde-multimedia signature.asc Description: OpenPGP digital signature ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Hi, On 2015-07-30 14:08, Martin Steigerwald wrote: > Why a new one? Aren´t none of the existing ones in a state that they can´t be > evolved into what you envision? > There is already Amarok, JuK, Bangarang, Clementine, Plasma Media Center and > you name it. As a user I am confused. Which do I use? Well for me I started > with Amarok and I really do like it a lot, just want to see it modernized > instead of looking at all the others to find out which new one to use. At the moment the only thing we have is a design vision. Of course this vision replaces most of the things that JuK and Bangarang does. Also Andrew Lake is the Creator of Bangarang and he is the one who started the UI mockups & vision development, so you can see it as a replacement of Bangarang (probably with a new name). JuK has a simillar feature set than what is planned, but I don't know in what shape the codebase is. Stefan signature.asc Description: OpenPGP digital signature ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
Hello Teo, On 2015-07-30 13:30, Teo Mrnjavac wrote: > Have you thought about picking up and taking over Amarok? A quick look at the > commit log for the past few months suggests that it's essentially > unmaintained, so if it keeps this pace it's unlikely to stay the swiss-knife > of music players as you suggest. > > This stuff is hard and time consuming so I think it makes sense to reuse code. > > While Amarok does have a sizeable feature set, a good portion of those > features are either poorly designed, broken or outdated. Perhaps by taking > over as maintainer, yanking out all the cruft and taking UX hints from the > VDG > you could get a modern and pretty music player up and running more quickly > and > easily than jumping into the umpteenth "magic rewrite that will fix all > things > forever". You could cut down on the feature set significantly, and present > the > features that you don't remove in a much better way. thanks for your answer. I was definitly thinking about starting (actually I don't feel confident enough to create the architecture) from an existing codebase, but probably not from the Amarok codebase (except of reusing some parts). I also talked with strohel at Akademy who has a better knowledge of the codebase and his opinion was that UI & backendcode are too much intertwined to allow replacing the UI easily. What I don't want to do is to take over Amarok. While it is true that Amarok is pretty much unmaintained, I don't think a player that has maybe only a third of the features should be called Amarok. Codebases I feel that are small and could be a good starting point (better evaluation is of course needed): -) Bangarang -) JuK And of course inspiration, GPL code and experience can be shared with many other music players. Stefan signature.asc Description: OpenPGP digital signature ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Help wanted to evolve KDEs music players
On Thursday, July 30, 2015 12:42:14 Stefan Derkits wrote: > Dear all, > > in discussions during Akademy 2015 we found out that while we have with > Plasma 5 a Desktop that has a modern & consistent look, the state of > some applications isn't that good. And we want to change that. > > At the moment KDE has no up-to-date music player. JuK is very simple to > use, but lacking a modern design. Amarok is and will stay the > swiss-knife of KDE music players, but also lacking a modern design and > may be too complicated for new users. > > So let's make a new music player, a successor especially to JuK & Bangarang. > A music player not for power users or music enthusiasts that want/need 100s > of features in a player but a simple player designed & made for users of > the Plasma 5 Desktop. > > What do we already have: > -) A design vision by the VDG including UI mockups & user stories [0] > > What do we need: > -) 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 > > 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. > > So if you are interested, contact me either in person on Akademy, on IRC > (HorusHorrendus @ freenode) or via mail (stefan [at] derkits.at) > Excellent idea, a no-nonsense "thing that opens audio files" is much needed. Have you thought about picking up and taking over Amarok? A quick look at the commit log for the past few months suggests that it's essentially unmaintained, so if it keeps this pace it's unlikely to stay the swiss-knife of music players as you suggest. This stuff is hard and time consuming so I think it makes sense to reuse code. While Amarok does have a sizeable feature set, a good portion of those features are either poorly designed, broken or outdated. Perhaps by taking over as maintainer, yanking out all the cruft and taking UX hints from the VDG you could get a modern and pretty music player up and running more quickly and easily than jumping into the umpteenth "magic rewrite that will fix all things forever". You could cut down on the feature set significantly, and present the features that you don't remove in a much better way. Cheers, -- Teo Mrnjavac http://teom.org | t...@kde.org ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
