Tomahawk, KDE, and other stuff
Updated ATF Info
ATF, or Advanced Tag Features, will hopefully enable a whole range of really cool features in amaroK. I’ve updated the Wiki with new information that reflects the changes that have gone on. Fortunately none have been in the API, just under-the-hood changes. Regardless, as it’s still so new and untested, I doubt anyone’s turned it on except for me anyways. Heh.
RSS
email
Print
PDF
Add to favorites
Identi.ca
Twitter
Google Buzz
Facebook
del.icio.us
Google Bookmarks
Reddit
Technorati
Slashdot
Digg
sounds very promising!
Wow, sounds very nice.
It doesn’t sound as this feature will be in the 1.4 series – 1.5 maybe? Or 2.0.
Well, it doesn’t really matter to me, because I use amaroK SVN :]
The feature will be there in 1.4 — it’s already in SVN, although I don’t currently recommend turning it on as there are some broken parts I need to fix. The logic is ready, but the code doesn’t seem to be
Probably this will be a “hidden” feature that people can try out as we make other parts of the program ATF-aware (personally, I’d like to see playlists become ATF-aware first). I’m guessing it won’t be trumpeted in 1.4.0, but as more code makes use of it, it’ll gently be unleashed early on or midway through the 1.4 series. Again, just my guess.
Also, remember that we have to assume that most people will not be using ATF. So ATF will be a secondary characteristic. For instance, take playlists. Although there could be a playlist manager with a slots connected to the ATF signal, there will be times when it will not be possible to send a signal out, i.e. if we have a new location for a file but did not know it moved. (This could happen during a full rescan, for instance).
So the signals are nice, but they may even go away because there might be a more useful paradigm. Here’s some psuedocode to illustrate the point:
if( !stat( playlist_track ) )
{
if( playlist_track.hasUniqueId() )
{
updatePlaylist( playlist_track.getURLFromID() )
}
else
{
behave_as_currently
}
}
I think the most useful thing to do is not to rely on signals, but rather to detect when expected files are missing (say, through a stat, which is not too expensive, especially when done once every couple of minutes), and use the unique ID value to find out where the file’s moved to, and then update the entry in the playlist (or whatever other feature).
I think I’ll post this info on the wiki…good stuff for other devs to know
Pleae note, within the Wiki article, which ID3v2 tag it uses. This could be useful to authors of other music managers and players.
It uses the ID3v2 tag that was designed for this use! Check the standard at http://www.id3.org/id3v2.4.0-frames.txt and I think it’ll be quite clear.
Cool!
One question – what about files on a read-only medium (r/o network resource, NTFS etc etc)?
They’ll have to be treated the way most files are right now (no ATF features
). If at some point the files are made writeable, ATF tags could be written to them. They could then be made read-only again. This would only be a problem if you copied one file to another location, and then made both read-only before the scanner finds them and the new ATF tag is dished out. 
As an aside, the ATF stuff is mostly done, except for some debugging. It will have to wait unfortunately, until some other things are taken care of for 1.4 release (ATF will not be enabled really until later in the Fast Forward series).