On 30. 4. 2013 vedant agarwala wrote: > On Tue, Apr 30, 2013 at 2:11 AM, Matěj Laitl <ma...@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 _______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
