On Monday 03 August 2015 11:33:54 Ing. Konrad Renner wrote: > 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.
IMHO, apart from the technicalities, there are two points of view. One is, that a local music player is obsolete in this highly connected world. The other is to argue, that playing whatever music one owns should be easy and pleasant. My point of view is that the opposite of a local music player is not spotify and friends, but a self hosted multimedia collection e.g. encoded CDs. Thus rendering a well-done local music player which connects to all my self hosted media properly an appreciated piece of software. Especially if it embraces different form factors and connects multiple devices. Persona Mia is a member of a research group at university. She writes code in R and sends it to the cluster of her department. She works on Linux and enjoys the freedom to set up her system to her liking as well as the freedom to decide where here private data goes. At home she runs a small server which servers pictures and music to her local network via samba. She listens to this music on her smart phone when cooking and she hooks her notebook or tablet up to the stereo to enjoy her music in the living room. She is technical, but when it comes to recreation, she likes things to just work. The vision I think, that this discussion is perfect in time given the announcement of the plasma phone. I wish for an application that is great to use on a notebook, a tablet, or a phone and is able to access all the music that lives on my own storage. Moreover, multi devices running this application should play nice together, such that remote control is possible or the plasma phone can turn down the volume of the music on the tablet connected to the stereo when a call happens. How to access data? The discussion on the list so far showed, that it is to be avoided to let feature by feature sneak in. Thus, I would suggest to access data via kio. Whatever fancy mechanism we want to add in the future, the heavy lifting can be done in kio. Moreover, everyone using kio benefits from these extension. E.g., if at some point spotify decides to open up their access, I guess that a spotify-kio should be possible in principal. However, I would not try too hard to access such services. We can not beat (or even play with) them in their own yard, for they decided to wall it. I also think that using kio is not a limitation for the user experience. All music should be presented in the same way, irrespective of its origin. Therefore, no special treatment for music coming from source A or B is needed and kio should serve this task well. Device interplay While it is possible to leverage networks like jabber to find devices, for a start I would stay withing the local network and do something along the lines of kdeconnect. In fact, I would integrate with kdeconnect, for I would not like to pair my devices more than once for different services. (I must admit that I do not know a lot of how kdeconnect does its thing, though.) Once devices in the same network know of each other they can interact. It should be possible to control the music played on the notebook or the table from the ui of the smart phone, but also all other combinations are useful. E.g., if Mia works at her notebook and has her phone plugged to the stereo, she wants to change the song or album right from where she sits. Or, if she takes a call and her tablet is the music source, the sound volume should go down automatically. (Maybe it would even be possible to stream the audio of the call to her stereo, but this is beyond this project, I guess.) Summary IMHO, it would be great if this new music player would target self-hosted media and the multi-device scenario which becomes feasible with the announcement of the plasma phone. My general take on this is, that especially applications from the entertainment area like music, film, or images viewers, should not be applications for the desktop, but for the plasma universe. With plasma running on different form factors it is much more likely for users to have more than one plasma powered device, and all these devices should play together with as little hassle as possible. Taken this idea further, it could lead to a device-connection layer (maybe a framework) which can be used by all applications interested in such a mechanism. I hope I have not kicked over the traces.
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
