Non-windows stuff to do

[Maximilian Kossick]

On Dec 11, 2007 6:49 AM, Ian Monroe <ian at monroe.nu> wrote:

> On Dec 10, 2007 5:20 AM, Shane King <kde at dontletsstart.com> wrote:
> > * Embedded image and filesystem based image support, as currently only
> > fetching from amazon is implemented for covers. Would really like to be
> > able to tag covers back to files too - not sure about license
> > implications there though (even though other programs do this). From
> > what I can tell, we may technically be violating the license even
> > caching the images to disk at all ...
>
> Well we're not violating the spirit of the license and once we
> re-enable the track refresher (which tries to redownload the album
> every two months) and put in links to amazon in the context browser
> we're not violating the terms either.
>
> Writing covers to the files has always seemed like bloat to me, I'm
> not so worried about the amazon license issue though.
>
> > Anyway, even if it's only reading from tags and folder.jpg for now, it
> > should be added back in.
>
> > * The collectionscanner still uses MetaBundle, which has a bunch of
> > legacy stuff. Not sure what the eventual intention is here, use a
> > light-weight replacement, or something xesam related like the Meta::File
> > seems to do?
>
> Yea one idea is to switch to Xesam for our collection scans. I'm not
> sure if this is actually doable or not within the 2.0 timeframe. Like
> really no idea, it might be perfectly ready or it might not be working
> at all. It seems likely that we'd end up in a hybrid solution, where
> people who have a Xesam scanner Amarok will get the info from,
> otherwise we'll have to run our own collection scanner.
>
> In other words, getting rid of legacy stuff in the collectionscanner
> is likely productive.
>
> Maybe Seb can poke Max K for us. :)


A hybrid solution would be neat, but I don't think it's doable in the
2.0timeframe. There's some code in sqlcollection which should be
reusable when
implementing a xesam scanner.
I agree with eean that getting rid of legacy stuff is a good idea, but i
think that collectionscanner should not be at the top of the list. It's fine
if we keep MetaBundle around for a while longer just to use it inside the
collectionscanner imo.

>
>
> > * Writing back to tags is currently unimplemented. Probably needs the
> > above item cleaned up first, so we have a smaller, leaner "MetaBundle"
> > class to do the writing.
>
> It doesn't really, collectionscanner is a separate process that
> communicates to Amarok via XML, so it how it does its internal stuff
> is pretty irrelevant to track writing. We already have the Meta::Track
> system that we're using now. I'm not quite sure where in the API track
> writing belongs. But this is certainly something needed.
>
> In my opinion the most orphaned code in Amarok is the playlist browser.
>
> Also see http://amarok.kde.org/wiki/Amarok2_Progress
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20071211/01d5b4f4/attachment.html