[Amarok-devel] Initial discussion

Alexandre Oliveira aleprjlists at gmail.com
Sun Feb 18 21:11:15 CET 2007


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.

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.

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? :-)

6) Plugins
It's been suggested to let everything be done by plugins, but Amarok
has never been about extreme configurability. Are we taking this path
now?
Some stuff definitely should be handled by plugins, like the database
stuff, stores, maybe the browsers, or maybe only part of them. I'm not
confortable with the idea of Amarok changing from a application to a
kind of framework for plugins, as some seem to suggest.

7) Phonon, engines and all.
It's seems the obvious move is to complete our phonon engine, keeping
the whole engine structure in Amarok. But if phonon is so nice as it
seems to be, is it worth?

8) Interface
Here, I think we should try out some ideas. Mockups are welcome.


And also:

9) Database Framework
Are we going to use litesql or something similar? Maybe we should just
stick to sqlite and forget about mysql/postresql support?

10) Database Schemma
Time for the wild necessary changes.


More information about the Amarok-devel mailing list