Hi all, On Sun, Aug 30, 2015 at 11:57 AM, Olivier Churlaud <oliv...@churlaud.com> wrote: > Le 30/08/2015 02:07, Stefan Derkits a écrit : >> >> Hi, >> >> On 2015-08-30 00:47, Olivier Churlaud wrote: >>> >>> I tried to do this just to show you how it could be but it doesn't seem >>> to be doable: everything is too connected... >> >> I tried it to and seems good atm, see >> http://commits.kde.org/amarok/1f01a5c9cbb1dc841004a800a2ce41353d049c80 >> >> I disabled: services, context, every collection except sql, importers >> > Maybe we should (when the porting is done) review the cmakelists to disable > more easily the plugins. So that we could more easily compile just the core > or the core +... and so on. > > I've seen that we already have it for Playground, Ipod and 2(?) others but > we might be able to do it in a more thorough way.
Makes sense, but: Playground is not something that is shipped with Amarok by default, and the iPod stuff is separated due to the non-free nature of the iPods, and due to historical reasons, at some point the distributions wanted it to be not integrated by default (Debian IIRC). But yes, more modularity is a good idea overall. In that spirit: please all read the mail sent by the icon developer to this ML a few weeks ago and try to work with him during the port, to avoid having to do things all over again because we didn't change the hard-coding of the icons. > > @Mamarok: Rishabh and Aditya will join us in a few days I think, since they > begin to have it compiled in the same way as we do. Are they in this ML? if > not, can you add them or have them registering? They are already subscribed > > @Mamarok: because of your disagreement the other day with Stefan, please > take some time to answer on this thread if it seems ok for you too (or if > you don't care the way we do it, if everything is done at some point :D) Building core as a first target sounds like a good idea, as it allows to the split the porting work more easily over several contributors. But what is something really important are unit tests, those really need to be written in parallel, writing them afterwards is not exactly in the spirit of agile development and continuous integration, it is also a very tedious job to do if those are pushed to after the port. We have already gone through that path with a lot of pain when we introduced the unit tests a few years ago. My disagreement with Stefan was simply due to his "Kill it!" orders in the devel channel for several core features of Amarok, something which, coming from somebody barely involved in Amarok in the last years, is a very bold and unacceptable statement. Removing whole sections of Amarok like podcasts or dynamic playlists is an absolute no-go, just because one developer doesn't need it for his use. Just for the record: Amarok is not and never will be part of the default packages shipped by KDE, as it is not meant to and never was meant to be a simple player. We have a very specific user base that counts on the great variety of features, which makes Amarok rather complex and not the first choice just for playing the occasional mp3. Our users need a reliable database as they have huge collections, working integration of external collections as most keep their music on remote partitions and/or servers, saved playlists and external media support are equally important, we have many listeners of classical music who use Amarok at home combined with their external sound systems and a vast user base of the podcast and dynamic playlist features. The Context View is one of the core features as well, commenting it out for the moment is OK as it needs to be rewritten in QML anyway, but removing it is out of the question. It is obvious we do not suit all use cases of music listeners, and we never meant to, that is normal and people have the choice to use what they want. That is after all the power of Free Software: giving users the choice. 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
