Planning for 2.0

[Dan Meltzer]

On Monday 19 February 2007 5:35:43 pm Gábor Lehel wrote:
> Guess who's back!

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

Nothing really huge.  The biggest things to happen recently was daap support 
and dynamic collections, both of which are in some state of completeness.  UI 
Wise a magnatune store was added into Amarok, as well as a shoutcast 
stream "browser" Other than that a lot of work was done in multimedia device 
support, and of course lots of bugfixes.
>
> 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.

Nod, a lot of the recent commits have just been get rid of easy global things 
to fix, because no one wants to start anything big :)
>
> - 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?
>

Especially with kdelibs being close to building on windows, I don't think that 
this is really a big deal to remove kde support.
> - 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.
>

Another suggestion was litesql (http://litesql.sf.net)  which is still in a 
prerelease form but looks interesting.
> - 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.
>

maybe collection/ browsers/ engine/ for a start?
> - 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.
>

Would gain less code to maintain, especially if kdelibs builds on windows and 
a native windows engine is written for Phonon.  If nothing else I would like 
to see some of the engines that are grossly unmaintained removed. (mas and 
nmm)
> - 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.

The problem with this is keeping track of which branch is which, but it is 
probably the best to have a "stable" trunk.
>
> 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/20070219/85ee5ef1/attachment.sig>