added: ability to open the smartplaylisteditor for a given playlist

[notspiff]

Requested in forums, ref http://forum.kodi.tv/showthread.php?tid=224034

[Montellese]

Maybe I'm missing something but why are you guessing for the type? If the XSP file exists it should also contain the type of the smartplaylist.

[akva2]

i'm guessing based on the folder names.

special://videoplaylists/blah.xsp
special://musicplaylists/blah.xsp

sure, we could open the xsp instead in principle. in any case the editor requires that we specify this up front for which controls are visible etc. not my invention.

reason i'm guessing is that we may be creating a new file. in that case, i cannot read it from a nonexistent xsp.

[Montellese]

Yes but for that you need to set m_mode which I don't see happening. And you load the playlist and then set the type even though you can already get it from the loaded playlist at that point.

[notspiff]

I dont do any of those things.

[notspiff]

As in read again and consider nonexistent files.

[Montellese]

OK for non-existing files that makes sense. But it still looks to me like you need to

• set m_mode (which in case of an existing smartplaylist and no type parameter could be determined from the type of the loaded smartplaylist)
• only change the playlist type if m_playlist.Load() fails

[notspiff]

rebased and fixed. can't get it less ugly.

[notspiff]

note that i removed the ability to open new files due to API issues (only a single string parameter is passed on from builtins/event server).

[Montellese]

Should be good now, thanks.

[Lunatixz]

Thanks for adding this feature.

[Lunatixz]

So will this make it into master in some form?

[NedScott]

Most likely, yes. Spiff doesn't want to handle the PRs himself, so he went and closed them, but we're still keeping track of them. We just have to wait for master to be un-feature frozen.

[Lunatixz]

Thanks 👍