Amarok 2.2.1 tagging

[Jakob Kummerow]

2009/11/5 Nikolaj Hald Nielsen <nhnfreespirit at gmail.com>:
>>> Basically, save() needs to be executed in a sensible place, which I
>>> have determined is probably not ~XSPFPlaylist() but that would be an
>>> easy fix right now. In longer term, the save function needs to be
>>> called from the provider or whatever has created the XSPFPlaylist
>>> object so the object can remain clueless about it's location on disk
>>> (i.e. no more m_url).
>>
>> Anyone working on this? Monday is getting close.

Should be fixed in rev. 11c9a3e. Please test.

And no, calling save() in ~XSPFPlaylist() did not have any effect at all.

Actually, I fixed two bugs to make it work:
(1) the default file name for playlists did not contain an extension
and was therefore rejected as unsupported.
(2) save() indeed had to be called, just not in the destructor, but
right away when creating the playlist.

Additionally, I implemented that when renaming the playlist, the
corresponding file gets renamed as well.

My approach has one minor limitation: The playlists will always be in
XSPF format. The reason is in the code... It boils down to the fact
that the only way I've found to save the file if the user just accepts
the default name is to *always* save it with the default name (and
perform renaming later, if appropriate). But that means that the
default file name's extension and therefore the playlist format must
be defined before the user has a choice to influence it.

Proposal: Scratch the playlist saving system in its current form, and
link the corresponding menu entry to the action already found as
"Playlist -> Export Playlist as..." in the main menu. Sure, it behaves
slightly differently, but it's more flexible, more powerful, and then
we only have to find and fix the bugs once instead of having two very
different implementations of two very similar features.

Cheers
Jakob