<br><br><div class="gmail_quote">On Dec 11, 2007 6:49 AM, Ian Monroe <<a href="mailto:ian@monroe.nu">ian@monroe.nu</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Dec 10, 2007 5:20 AM, Shane King <<a href="mailto:kde@dontletsstart.com">kde@dontletsstart.com</a>> wrote:<br>> * Embedded image and filesystem based image support, as currently only<br>> fetching from amazon is implemented for covers. Would really like to be
<br>> able to tag covers back to files too - not sure about license<br>> implications there though (even though other programs do this). From<br>> what I can tell, we may technically be violating the license even
<br>> caching the images to disk at all ...<br><br></div>Well we're not violating the spirit of the license and once we<br>re-enable the track refresher (which tries to redownload the album<br>every two months) and put in links to amazon in the context browser
<br>we're not violating the terms either.<br><br>Writing covers to the files has always seemed like bloat to me, I'm<br>not so worried about the amazon license issue though.<br><div class="Ih2E3d"><br>> Anyway, even if it's only reading from tags and
folder.jpg for now, it<br>> should be added back in.<br><br></div><div class="Ih2E3d">> * The collectionscanner still uses MetaBundle, which has a bunch of<br>> legacy stuff. Not sure what the eventual intention is here, use a
<br>> light-weight replacement, or something xesam related like the Meta::File<br>> seems to do?<br><br></div>Yea one idea is to switch to Xesam for our collection scans. I'm not<br>sure if this is actually doable or not within the
2.0 timeframe. Like<br>really no idea, it might be perfectly ready or it might not be working<br>at all. It seems likely that we'd end up in a hybrid solution, where<br>people who have a Xesam scanner Amarok will get the info from,
<br>otherwise we'll have to run our own collection scanner.<br><br>In other words, getting rid of legacy stuff in the collectionscanner<br>is likely productive.<br><br>Maybe Seb can poke Max K for us. :)</blockquote><div>
<br>A hybrid solution would be neat, but I don't think it's doable in the 2.0 timeframe. There's some code in sqlcollection which should be reusable when implementing a xesam scanner.<br>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.
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div class="Ih2E3d"><br>> * Writing back to tags is currently unimplemented. Probably needs the
<br>> above item cleaned up first, so we have a smaller, leaner "MetaBundle"<br>> class to do the writing.<br><br></div>It doesn't really, collectionscanner is a separate process that<br>communicates to Amarok via XML, so it how it does its internal stuff
<br>is pretty irrelevant to track writing. We already have the Meta::Track<br>system that we're using now. I'm not quite sure where in the API track<br>writing belongs. But this is certainly something needed.<br><br>
In my opinion the most orphaned code in Amarok is the playlist browser.<br><br>Also see <a href="http://amarok.kde.org/wiki/Amarok2_Progress" target="_blank">http://amarok.kde.org/wiki/Amarok2_Progress</a><br><div><div></div>
<div class="Wj3C7c">_______________________________________________<br>Amarok-devel mailing list<br><a href="mailto:Amarok-devel@kde.org">Amarok-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/amarok-devel" target="_blank">
https://mail.kde.org/mailman/listinfo/amarok-devel</a><br></div></div></blockquote></div><br>