<div dir="ltr">Matej,<div>Thank-you once again for your comments. I have drastically changed my proposal based on it. I didn't want you to read my entire application again so I just comment on some things that I have changed but I'm not so confident about.</div>
<div style>Regards,</div><div style>Vedant</div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 30, 2013 at 2:11 AM, Matěj Laitl <span dir="ltr"><<a href="mailto:matej@laitl.cz" target="_blank">matej@laitl.cz</a>></span> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)"> </span><br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"></div><div class="im">
> Each TagGetter::Provider will have its own directory under the TagGetter<br>
> directory. They will contain classes and one that will implement the<br>
> Provider class. Data will be shared among the classes (in the TagGetter<br>
> namespace) probably via QExplicitlySharedDataPointer.<br>
<br>
</div>what data?<br>
<div class="im"><br></div></blockquote><div><span style="font-family:Arial;line-height:17px;white-space:pre-wrap">I will share Provider pointers (and some other pointers) among different classes (like the classes handling GUI will require information from the provider) via the QExplicitlySharedDataPointer.</span></div>
<div><span style="font-family:Arial;line-height:17px;white-space:pre-wrap"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
<br>
> A AbstractSettings class will also<br>
> be present so that users can customize the settings of each Provider and<br>
> each Provider can store a small amount of data in the data using the<br>
> KGlobal::config(). This will also be beneficial for the programmer(s) who<br>
> add more Providers. It will also keep a consistent look and feel of all the<br>
> TagGetterProviders.<br>
<br>
</div>Hmmm, the original intent was to make the providers rather dumb and almost<br>
invisible to the user. What do you think would be need to be configurable by<br>
the user?</blockquote><div><span style="font-family:Arial;line-height:1.4625;white-space:pre-wrap">Each Provider can store a small amount of data in the data using the KGlobal::config(). A provider should add itself to the "plugins" section in Amarok Settings so that it can be enabled/disabled by the user. If badly required also provide some </span><span style="font-family:Arial;line-height:17px;white-space:pre-wrap">additional</span><span style="font-family:Arial;line-height:1.4625;white-space:pre-wrap"> user </span><span style="font-family:Arial;line-height:17px;white-space:pre-wrap">changeable</span><span style="font-family:Arial;line-height:1.4625;white-space:pre-wrap"> settings, since its best to keep working of plugins as </span><span style="font-family:Arial;line-height:17px;white-space:pre-wrap">abstracted</span><span style="font-family:Arial;line-height:1.4625;white-space:pre-wrap"> from the user as possible.</span><br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">> Other code will also be re-written but its work<br>
</div><div class="im">
> will mainly remain the same, except for one major difference. Currently,<br>
> libofa is used to create the MusicIP (PUID) that is sent to MusicBrainz.<br>
> MusicBrainz is phasing out PUIDs in favour of AcustIDs.<br>
><br>
> Hence, the MusicBrainzProvide will use<br>
</div>> Chromaprint<<a href="http://acoustid.org/chromaprint" target="_blank">http://acoustid.org/chromaprint</a>>to compute AcustIDs rather<br>
<div class="im">> than the MusicIP generated by libofa.<br>
<br>
</div>Oh beware! The musizbrainz and musicip are rather independent and were<br>
intended to be factored out into 2 separate providers! (one changing to<br>
acoustid)<br></blockquote><div><p dir="ltr" style="font-family:Arial;font-size:12px;line-height:1.4625;margin-top:0pt;margin-bottom:0pt"><span style="vertical-align:baseline;white-space:pre-wrap">The MusicBrainzFinder will become MusicIpProvider, implementing the abstract Provider class. Other code will also be re-written. Currently, libofa is used to create the MusicIP (PUID) that is sent to MusicBrainz. MusicBrainz is phasing out PUIDs in favour of AcustIDs.</span></p>
<p dir="ltr" style="font-family:Arial;font-size:12px;line-height:1.4625;margin-top:0pt;margin-bottom:0pt"><span style="vertical-align:baseline;white-space:pre-wrap">Hence, another Provider will be made (in the same directory).</span></p>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> Codecs will identified using ffmpeg.<br>
<br>
</div>What/why?<br></blockquote><div><br></div><div style><line deleted> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> Phonon will be used for decoding while Chromaprint will be used to generate<br>
> the AcoustID.<br>
<br>
</div>Have you checked this is possible? What Phonon methods will you use?<br>
<div class="im"><br></div></blockquote><div><span style="font-family:Arial;font-size:12px;line-height:17px;white-space:pre-wrap">Chromaprint will be used to generate the AcoustID. <rest deleted></span><br></div><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> Chromaprint uses the<br>
> standard C<br>
</div>> library[*]<<a href="https://bitbucket.org/acoustid/chromaprint/src/master/src/chroma" target="_blank">https://bitbucket.org/acoustid/chromaprint/src/master/src/chroma</a><br>
> print.h>so using this won’t be a problem.<br>
<br>
Eh? What is a connection between a project using a standard C library and<br>
feasibility of its usage?<br></blockquote><div><span style="font-family:Arial;font-size:12px;line-height:17px;white-space:pre-wrap">Chromaprint uses the standard C library</span><a href="https://bitbucket.org/acoustid/chromaprint/src/master/src/chromaprint.h" style="font-family:Arial;font-size:12px;line-height:17px;white-space:pre-wrap">[*]</a><span style="font-family:Arial;font-size:12px;line-height:17px;white-space:pre-wrap"> so code can easily embedded.</span></div>
<div><span style="font-family:Arial;font-size:12px;line-height:17px;white-space:pre-wrap"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div class="h5">
<br>
</div></div>Vedant, I really think that implementing all the stuff you've outlined is<br>
unachievable, at least not in a code quality we'd expect. Please take some<br>
time to significantly reduce the amount of work you plan to do. Many of the<br>
ideas you have on top of the idea (published by devs) simply don't align with<br>
Amarok goals and/or are based on misunderstanding of how current tag guessing<br>
works.<br></blockquote><div style>I have corrected the above after running amarok with Alberto's patch and seen how current tag guessing works.</div><div style>I entirely removed the "better GUI" and "tag-getter wizard" points completely and hence other occurances of the same.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> Other Obligations: I have no other obligations. I can easily spent about 50<br>
> hours a week: around 8 hrs a day in slots of 2 to 3 hrs, one each in the<br>
> afternoon (10am-1pm), evening (4pm-6pm) and at night (10pm-1am), with some<br>
> hours less on weekends.<br>
<br>
</div>Hehe, I don't think you need to be this detailed. :-)<br>
<div class="im"><br></div></blockquote><div style>I thought i should mention times due to metor-student time zone difference. Anyway I have changed it to: <span style="color:rgb(0,0,0);font-family:Arial;font-size:13px;line-height:19px;white-space:pre-wrap">I have no other obligations. I can easily spent about 50 hours a week: around 8 hrs a day in slots of 2 to 3 hrs.</span></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> Summer vacations will be going on till mid July.<br>
> Even after college starts, I will be following the same schedule for GSoC<br>
> coding. It is easily possible because very few classes are held in the<br>
> beginning of the semester and even if they do clash with my coding<br>
> time-period, the college teachers excuse GSoC students' absence from class.<br>
> Since I will have no other coursework obligations, I can continue to code<br>
> 50 hours a week (with a similar schedule) even up till September.<br>
><br>
> About Me: I am currently in my second undergraduate year in National<br>
> Institute of Technology, Durgapur, India, studying Computer Science and<br>
> Engineering. I have experience coding experience with C/C++, Java<br>
> (including Android and making GUI using Java swing) and web services. I<br>
> have submitted 3 patches (Junior Jobs, one each for<br>
</div>> Rekonq[1]<<a href="https://git.reviewboard.kde.org/r/107662/" target="_blank">https://git.reviewboard.kde.org/r/107662/</a>>and Amarok<br>
> [2] <<a href="https://git.reviewboard.kde.org/r/109283/" target="_blank">https://git.reviewboard.kde.org/r/109283/</a>> as well as a improved<br>
> formatting patch for Amarok[3] <<a href="https://git.reviewboard.kde.org/r/109295/" target="_blank">https://git.reviewboard.kde.org/r/109295/</a>>)<br>
<div class="im">> and 2 more are under review (both Junior Jobs for<br>
</div>> Amarok[4]<<a href="https://git.reviewboard.kde.org/r/110101/" target="_blank">https://git.reviewboard.kde.org/r/110101/</a>><br>
> [5] <<a href="https://git.reviewboard.kde.org/r/110082/" target="_blank">https://git.reviewboard.kde.org/r/110082/</a>>).<br>
<div class="im">><br>
> I love coding for open source. I’m sure working with a mentor who is<br>
> virtually present won’t be a problem. I have interacted (mainly with Matej<br>
> a.k.a. Strohel on IRC) over IRC, the amarok mailing list, reviewboard and<br>
> also the KDE bug tracking system. During the work period code can easily be<br>
> shared via GitHub.<br>
<br>
</div>We prefer personal scratch git repositories on KDE infrastructure for this.<br>
<div class="im"><br>
> If it is possible, meeting a mentor face to face will<br>
> obviously be much more helpful. I have worked with my college seniors in<br>
> this fashion who have introduced me to Linux and Open-Source. Countless<br>
> times I have been to their rooms for advice and to solve my problems.<br>
><br>
> After GSoC I plan to become an active developer for Amarok and also for<br>
> other projects of KDE.<br>
<br>
</div>As stated above, this looks to me like a way too much work to do. Perhaps you<br>
are trying to make the proposal more interesting, but I fear that the effect is<br>
the opposite - we'd actually appreciate if you wanted to implement much less<br>
things (ideally just what the initial idea was about), but make it interesting<br>
by level of insight, research and thought that has been put to it.<br>
<br>
Also please study/use the current tag guessing in Amarok more (and do have a<br>
look at Alberto's patch) to avoid a situation where you describe lack of<br>
Amarok feature while it is not the case.<br>
<br>
Regards,<br>
<div class=""><div class="h5"> Matěj<br>
_______________________________________________<br>
Amarok-devel mailing list<br>
<a href="mailto:Amarok-devel@kde.org">Amarok-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/amarok-devel" target="_blank">https://mail.kde.org/mailman/listinfo/amarok-devel</a><br>
</div></div></blockquote></div><br></div></div></div>