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? >> >> 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? >> >> >> > 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 _______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
