Hi Mike Many thanks for your reply. It seems then that HandleTrackRemoved and similar handlers should check the Track field in addition to Tracks (for now the Track field is actually ignored, which break Library.Remove(LibraryTrackInfo) among others). I'll check whether this was already reported on bugzilla... > It's an efficiency thing. Instead of raising an event for each track > removed, the 'Tracks' field groups all tracks that were removed as the > result of the same operation. So in the case of say a UI or DB app, you > wouldn't have to update the display or write to the DB n-times. > Instead, you can handle the removal of all of the tracks at once and > then commit to the db / update the display only as many times as > absolutely necessary. Yes, I was actually wondering why there is Track in addition to Tracks... perhaps to avoid the overhead of creating a new collection in cases where there is only one track? BTW, I've already been looking for a way to pack additions and removals together but it does not seem that the current Library allows this. It would actually be very useful, to avoid display flickering in some basic cases like running a script which renames all .MP3 files into .mp3... for now it's visually awful ;-) Thanks again Jacob > _______________________________________________ > Banshee-list mailing list > Banshee-list gnome org > http://mail.gnome.org/mailman/listinfo/banshee-list ________________________________________________________________________ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
Attachment:
signature.asc
Description: This is a digitally signed message part