GSoC draft application
Matěj Laitl
matej at laitl.cz
Thu May 2 00:31:52 UTC 2013
On 30. 4. 2013 vedant agarwala wrote:
> On Tue, Apr 30, 2013 at 2:11 AM, Matěj Laitl <matej at laitl.cz> wrote:
> > Vedant wrote:
> > > They will contain classes and one that will implement the Provider
> > > class. Data will be shared among the classes (in the TagGetter
> > > namespace) probably via QExplicitlySharedDataPointer.
> >
> > what data?
>
> 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.
Ah. I would say that "Providers would be memory-managed using Q...Pointers.
Also note that QExplicitlySharedDataPointer is virtually equivalent with
KSharedPtr and is prone to circular reference problem.
> > Hmmm, the original intent was to make the providers rather dumb and almost
> > invisible to the user. What do you think would be need to be configurable
> > by the user?
>
> 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 additional user changeable settings, since its
> best to keep working of plugins as abstracted from the user as possible.
Okay.
> 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.
>
> Hence, another Provider will be made (in the same directory).
^^ this isn't still clear to me that you understand the current situation, but
let's see it in the proposal.
> > > Chromaprint uses the standard C library[*]
<https://bitbucket.org/acoustid/chromaprint/src/master/src/chromaprint.h> so
> > > using this won’t be a problem.
> >
> > Eh? What is a connection between a project using a standard C library and
> > feasibility of its usage?
>
> Chromaprint uses the standard C
> library[*]<https://bitbucket.org/acoustid/chromaprint/src/master/src/chromap
> rint.h>so code can easily embedded.
No, we don't embed/bundle code of third party libraries. We declare them as
(optional) dependencies.
> > Vedant, I really think that implementing all the stuff you've outlined is
> > unachievable, at least not in a code quality we'd expect. Please take some
> > time to significantly reduce the amount of work you plan to do. Many of
> > the ideas you have on top of the idea (published by devs) simply don't
> > align with Amarok goals and/or are based on misunderstanding of how
> > current tag guessing works.
>
> I have corrected the above after running amarok with Alberto's patch and
> seen how current tag guessing works.
> I entirely removed the "better GUI" and "tag-getter wizard" points
> completely and hence other occurances of the same.
Good.
> > > Other Obligations: 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, one each in
> > > the afternoon (10am-1pm), evening (4pm-6pm) and at night (10pm-1am),
> > > with some hours less on weekends.
> >
> > Hehe, I don't think you need to be this detailed. :-)
>
> I thought i should mention times due to metor-student time zone
> difference. Anyway I have changed it to: 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.
Well, be prepared that most of the communication with the mentor will be non-
interactive and you are supposed to work quite independently.
Matěj
More information about the Amarok-devel
mailing list