by popular request

[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. Addendum: The browsers do seem like a good candidate, however.

- 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.

Re Jeff: That all does sound interesting and sort of GStreamerish, but
I still don't grasp how it would work in practice. Would the entire
application be just a big collection of plugins, like various IDEs
(Eclipse)? Or would it be a core application + plugins, in which case,
which functionality would be in the core, and which in plugins?
Examples would be helpful, e.g. as many examples of particular plugins
we would have as you can think of.


-- 
Work is punishment for failing to procrastinate effectively.