[Amarok-devel] Initial discussion

[Maximilian Kossick]

On Sunday 18 February 2007, Alexandre Oliveira wrote:
> Just reposting here my mail to the other list
>
> There's a lot of things to discuss:
>
> 1) Proper objects to hold data, instead of strings.
> I mean Track, Artist, and Album objects, for example. No Strings with
> names or ints with ids traveling around. Having these objects will
> help keeping the code much cleaner, and will avoid repetion. For
> example, all the ", The" magic could be handled in proper methods
> hidden in the Artist class.
> These objects should have as much methods and as little properties as
> possible. They all inheriting a base object would be useful for some
> stuff as well.

I agree. We should replace MetaBundle completely. I'm not quite sure what you 
mean by "inheriting a base object". Do you already know a case where a common 
base class would be useful?
Another think we should think about is creating the objects on the heap 
instead of on the stack. That way we lose the automatic memory management, 
but gain a lot of flexibility. 

> 2) Database handling.
>  Are we going to use the Qt database stuff, some library out there, or
> just code the support ourselves?
> If we're going to code it, we need something that is done by plugins
> (to avoid the problems we had with mysql/postgresql running
> dependency), and we need something that returns objects to us (as I
> mentioned in #1), instead of the lists of strings we had in 1.4.
>
> 3) Reduce developers compiling time.
> I don't mean we should do any magic regarding this, I only mean we
> should split the amarok lib we have now, so stuff can depend only on
> what they really need, so we don't relink everything whenever
> something that doesn't matter changes.

We have a few classes which are used that much that a change to the header 
file basically requires recompiling all of amarok. How about adding 
d-pointers to classes like EngineController, CollectionDB or Playlist ( or 
their replacements) so that we can add members without having to change the 
header files?

> 4) Reorganise source files?
> Right now we have almost all source files in the src folder, shouldn't
> we take this chance to organise it in a better way?
>
> 5) Smaller methods.
> Let's avoid 5000 line methods this time, shall we? :-)

I don't think we have 5000 line methods,  but 500 line methods and 5000 line 
classes for sure. And neither is a good idea:)

[SNIP]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20070218/e1f74f1a/attachment.pgp