Hi Nitul, Thanks for your proposal, but I have some doubts about this.
On Mon, Oct 27, 2014 at 8:47 AM, Nitul Datt <nitul1...@gmail.com> wrote: > Hi! One thing which springs to mind is, suppose a user > wants to store a custom cover. Should that also be stored in the > filesystem mentioned in the specification or should it be stored at > the album location itself? It already does so, why would you change that? Custom covers should always be stored locally. Changing what is already there is rarely a good idea without a major reason. Don't forget, you want to add a feature, not remove one :) On the other hand: why would this specification be needed? AFAICS this is a Gnome library, so it would add another dependency, and not a Qt one either. I am sure there are far better suited tasks for a SoK project than implementing an external specification. I would need a very compelling reason to implement this, as it is only used by Banshee which is hardly a major player. Is it used by other media players, specifically Qt-based ones? If not, this is really not worth to spend time on IMHO, I would consider this feature request a very minor one for the above mentioned reasons. Also: this is a Junior Job, which is something doable within a week, hardly a SoK-worthy task .. I would expect any SoK applicant to actually first solve a Junior Job to show their ability to code and tackle a larger project like SoK or GSoC. Junior Jobs are classically something that can be done within a day or two, a week at most, so https://bugs.kde.org/show_bug.cgi?id=296049 is clearly not suitable for SoK at all. There are currently two things I would see good SoK tasks: 1. What is far more needed since quite some time, and what should be a high priority to implement is the CUE sheet support. You can easily judge that from the number of open bugs and the high number of votes for this feature. It is partially implemented, and there is already some work lying around IIRC. Mind you, the implementation of proper CUE sheet support for files in the collection (CUE sheets already do work more or less for tracks not in the collection currently) would solve all the existing bugs at once, or at least most of them. I suggest some digging in other Qt-based players who already do implement CUE sheet support which will certainly yield some insight on what is done wrong in our code. 2. Another very much needed feature is porting the current Nepomuk support to Baloo: https://bugs.kde.org/show_bug.cgi?id=336380 There are links to previous bugs with more information, and the Baloo specifications are also very helpful in that regard And finally: please do not copy-paste bug report wording in your proposal, but write your own one! A good proposal would show that you have really put some thought into it, not just a tentative timeline to something you haven't event really looked at at all. Research is starting before you do a proposal, and the results should show in the proposal. 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
