On 29 Oct 2014 13:06, "vedant agarwala" <vedant.k...@gmail.com> wrote: > > > > On Wed, Oct 29, 2014 at 4:53 AM, Nitul Datt <nitul1...@gmail.com> wrote: >> >> Hey! >> >> On 10/28/14, vedant agarwala <vedant.k...@gmail.com> wrote: >> > Hello Nitul, >> > >> > Seems like you forgot to "reply to all" (as amarok-devel was not in your >> > recipients). >> > >> > On Tue, Oct 28, 2014 at 12:37 AM, Nitul Datt <nitul1...@gmail.com> wrote: >> > >> >> On 10/27/14, vedant agarwala <vedant.k...@gmail.com> wrote: >> >> > Hello Nitul, >> >> > >> >> > I agree with all that Myriam has said. I should've waited for a >> >> > go-ahead >> >> > for a senior Amarok member; if you remember I had mentioned that I was >> >> > unable to get in touch with them. Sorry for rushing in and making you >> >> > do >> >> > some extra work. >> >> > >> >> >> >> That's quite alright. Although this leaves me with only a few days >> >> until October 31st, the student aplication deadline. >> >> >> >> > Take your time and pick a new project from the 2 mentioned. AFAIK there >> >> is >> >> > no "start" date for SoK but an end date (31st January). A proposal is >> >> > as >> >> > important as the coding itself so it is perfectly fine to spend time on >> >> it. >> >> > >> >> >> >> Well I checked and the only possibility left is implementing Cue sheet >> >> support. Vishesh Handa just clarified about the port from nepomuk to >> >> baloo on the buglist. His suggested solution will take one or two days >> >> maximum. >> >> I had just mailed the first draft of the proposal. I knew it required >> >> a lot of work. >> >> I just have one question, the SoK page mentions that the student >> >> application deadline is 31st October. Does one have to submit a >> >> proposal before then? The FAQ mentions that it is not necessary to >> >> submit a proposal before applying. >> >> >> > >> > If this is the case you should apply asap and work on your proposal. >> > >> >> As suggested previously I have had a look at the existing code for cue >> sheet support. I have also begun looking through the source for qmmp, >> a Qt based media player which supports cue sheets. Do you have any >> other suggestions? > > > I haven't done much research but you are going in the right direction- using existing code. >> >> >> >> >> >> As for implementing cue sheet support, I have no idea regarding this >> >> and would require a little bit of help from your side. >> >> >> > >> > I can help on how to go about it but a proposal has to made entirely by >> > you. See the bugs relevant to the idea and try to fix as many of them as >> > possible, if not all. (include references to them in your proposal). Come >> > up with an idea and google each step. If you have doubts in selecting a >> > particular path we can help as you are not yet fully familiar with Amarok's >> > coding guidelines. >> > Beware of not reinventing the wheel- if there is code that is relevant, >> > just copy it. If a library fits your needs we can include it during the >> > Amarok build (though try to minimize this). >> >> >> >> > Keep us in the loop through IRC and this mailing list. >> >> > >> >> > Also do the following things: >> >> > >> >> > 1. Register a bouncer for IRC (I think KDE's bouncer is called BNC. >> >> > Look >> >> > into it and send a registration request) >> >> Done >> >> >> > 2. Register for a developer account and set up a personal scratch git >> >> > repository (but even then you will have to upload code to reviewboard, >> >> > as >> >> > it is easier to review there) >> >> > >> >> >> >> Done. I should get access in a couple of days. >> >> >> I can only access freenode webchat from my university wifi. >> >> >> > >> > You did not get what I meant. With a frown I give you the links: >> > https://community.kde.org/Sysadmin/BNC, https://bnc.kde.org:7778/ >> > >> > >> >> Lastly, do proposals have to be submitted before the student >> application deadline ie 31st October? > > > ask this question on the kde-soc mailing list or IRC. I have no extra information.
According to Kde-soc, proposals must be submitted before the deadline. >> >> >> >> >> >> >> >> > Regards, >> >> > Vedant. >> >> > >> >> > On Mon, Oct 27, 2014 at 3:50 PM, Myriam Schweingruber < myr...@kde.org> >> >> > wrote: >> >> > >> >> >> 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) >> >> >> >> >> > >> >> >> >> >> >> -- >> >> Regards, >> >> Nitul Datt >> >> >> > >> > Break a leg. >> > >> > Regards, >> > Vedant. >> > >> >> >> -- >> Regards, >> Nitul Datt > > > Regards, > Vedant -- Regards, Nitul Datt
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
