Planning for 2.0

[Gábor Lehel]

Guess who's back!

Thank you for /finally/ beginning the 2.0 port, and rekindling my
interest in this whole hacking-on-code thing. The past months have
been... interesting, I'll elaborate about it later. In the meantime,
what's been happening in amarokland? There's no way I'm capable of
reading through 6 months of kde-commits backlog, so an executive
summary would be appreciated here.

The first thing I'll probably work on once I get this whole thing set
up is porting the Playlist over to Interview; other things may or may
not follow later. (Right now I'm checking out qt-copy at some
incredibly slow pace -- it's been going for over 5 hours now -- from
anonsvn, because I had my account disabled a month or so ago because I
got a laptop and got it stolen and it had my svn auths on it, and it
hasn't been reenabled yet because I just sent the mail requesting it,
and cursing kubuntu for having a lower svn version than what the
downloadable snapshots use, and other such fun things... so... yeah).

Other thoughts.

- I agree with Alexandre about the whole objects-rather-than-strings
thingie, and just plain good coding practices in general.

- WRT qt3support, I don't think we should do a big directed purge of
it, as very large parts of the app will get refactored/rewritten
anyways -- just don't include it in any new code, and we'll see what's
still left afterwards.

- KDE vs. Qt libs -- I don't think outright dropping KDE as a
dependency is feasible in the near future, especially since it has
many nice things for us like Phonon and Solid, but we should probably
favour the Qt versions of things where we have a choice and the KDE
ones don't have any big advantages we want/need. Again, not a directed
purge, just a replace-them-as-we-go thing. My big objection to the
earlier Qt-only ideas was, "how do you replace KHTML?", but now that
we have WebKitQt, eventually we might be able to reduce the KDE code
to a Phonon engine, #ifdefs for Solid (or a plugin if that's
possible), and what else?

- Re: Database handling, in the above vein I'd prefer using QtSQL if
that's workable, but it seems like a considerable amount of work which
isn't necessarily high on my own list of priorities, so we'll see.

- I agree that most of amarok sitting in src/ isn't ideal, but how
could we organize it otherwise? There aren't enough files belonging to
individual components like the playlist and various browsers to make
that approach worthwhile. One idea could be separating it by QtCore
and QtGui dependency, maybe other things like QtSql or TagLib.

- Phononwise, I think we should write it as an engine, and make it
default, maybe even remove the option to configure it otherwise from
the GUI. In the code, though, this option is the least invasive, and
we wouldn't gain anything by replacing the whole engines system with
Phonon, just lose flexibility.

- I'm sceptical regarding plugins, but this might be because I've
never really done a plugin interface, and I have no clue how one might
look like in amarok's case. Some concrete ideas would go a long way in
letting me form an opinion about this. The Krita guys seem good with
plugin systems (they use a lot of them), but then a painting
application is a lot more modular in concept (tools, colorspaces,
filters, palettes, etc etc), than an audio player, as far as I can
tell.

- I think UI redesigns should invariably go in branches (unless we
have complete consensus, which is impossible), because people have
wildly varying tastes in these things, and giving them the new UI in
an unfinished state would only exacerbate it. Once the creator of the
new UI thinks it's about done, that's the point when it's worth
getting feedback, imho.

- Major refactorings should either be worked on in branches or
locally, either way breakage in trunk should be minimised, and it
should only see commits once they're in an "it works
as-far-as-I-can-tell" state.

That's what I can think of at the moment. I had a big list of stuff,
but it got lost, I'll see what I end up remembering.


On 2/18/07, Dan Meltzer <dwm2 at alfred.edu> wrote:
> Now that 2.0 runs It seems like a good time to start setting up plans for what and how things will be done.
>
>
> From What i've heard, the following things are/were planned:
>
> 1) Refactoring collectiondb
> 2) UI Redesign
> 3) Making amarok OS independant.
>
> I'm sure there are other things, but i don't recall what off the top of my head.
>
> My suggestion would be to do the first two in a branch (probably separate branches).  This allows trunk to be something we know works and a place to do 3) in as well as other fixes.  Are there other plans for 2.0?
>
>
> TO DEVELOPERS: Are there people who are planning on working in anything specific?
>
> TO USERS: What features do you think 2.0 should have that 1.4.5 doesn't?  This is probably the best opportunity to add features, as everything is changing anyways.  What do you think Amarok needs to continue to be the best media player availible?  Making suggestions is no guarantee they will be implemented, but its more likely than not making suggestions.
>
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok
>


-- 
Work is punishment for failing to procrastinate effectively.