Towards Amarok Mobile: Beginning separation

Maximilian Kossick maximilian.kossick at googlemail.com
Sat Mar 20 18:22:07 CET 2010


On Sat, Mar 20, 2010 at 5:26 PM, Jeff Mitchell <mitchell at kde.org> wrote:
> On 03/20/2010 05:00 AM, Maximilian Kossick wrote:
>> Moving all those classes into meta/ does not make a lot of sense imo.
>> They are not providing track metadata after all.
>
> Neither does a Playlist, but that's sitting in meta/. It seemed like
> meta was a location for general metadata, not track metadata specifically.

It is arguable whether Playlist should have been there in the first
place. Completely different issue though.

>> If you are planning
>> to do that refactoring, I suggest creating a "Core API" library
>> instead. Which could then continue to have the internal distinction
>> between meta/ and collection/.
>
> I could do that. That basically just means shuffling around directories
> to create e.g. core/meta/ instead of meta/. That would end up as a very
> large amount of busywork fixing build breakage, though.

Creating a core/meta and core/collection directory is probably going
to be less work as quite a few classes use "meta/Meta.h" or
"collection/QueryMaker.h" includes. Adding core or core/meta to the
include directories in a dozen or so cmakelists.txt is trivial
compared to some other refactoring tasks that will have to be done.
Decoupling all those core components (EngineController, StatusBar, and
so on) to allow component reuse on different devices (e.g. supplying a
different statusbar implementation on N900) is were the real fun
begins.

>> You did not mention QueryMaker, but
>> that would have to be moved as well.
>
> Yes.
>
> --Jeff
>
>
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
>


More information about the Amarok-devel mailing list