Planning for 2.0

[Dan Meltzer]

On Monday 19 February 2007 5:35:43 pm Gábor Lehel wrote:

As a followup, not sure if you have had time to work on anything yet, but 
shash and I have been working in branches/work/amarok_uirefactor -- which may 
be a better place to try out the new playlist things?
> 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


-------------- 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/attachments/20070224/c1f831d1/attachment.sig>