2016-04-21, 12:56
It recently came to my attention that the replaceItems parameter in the xbmcgui.ListItem().addContextMenuItems method has been deprecated in Krypton, and that certain items (contextually decided by Kodi) will always appear on the menu (eg Add to favourites):
https://github.com/xbmc/xbmc/pull/9595/c...443c5486d4
I made a few comments on github regarding this, initially questioning whether this was a temporary deprecation whilst broken functionality was fixed (to which @martjn gave his customary flippant and utterly useless reply), and then when helpfully requested by @ronie I listed a few use cases where I described why I considered the deprecation a step backwards:
https://github.com/xbmc/xbmc/pull/9595#i...-212016267
Going off slightly on a tangent for a moment; you can see, I was ultimately shot down in flames, clearly @tamland doesn't think I should take this statement personally:
"What's broken here is the utter mess that is super favourites. If you actually expect anything in that addon to work from revision to revision, I cant help you... Instead of complaining that one of your many hacks and workarounds broke, you should try finding proper solutions to you problems." tamland
"spoyser you're taking this way too personal. It's not:\" tamland
If that ain't personal I don't know what is.
Anyway - back on track.
For the record - My opinion is quite clearly that it is a bad thing .
1) The built-in "Add to favourites" doesn't always work, eg sometime the item needs to be tweaked before adding, eg changing the visible text, modifying path, etc.
2) Queue item, Play, and Make default always seems to always appear for music items regardless of their playable status (maybe just a bug in the current implementation)
3) The auto-added items always appear after the addon-added items, this layout isn't always the most sensible layout.
I was wondering if any other addon developers have an opinion (either way) on whether deprecation of the replaceItems parameter and therefore the inability for an addon to fully define its own context menu is a good thing, bad thing, or neither here-nor-there?
https://github.com/xbmc/xbmc/pull/9595/c...443c5486d4
I made a few comments on github regarding this, initially questioning whether this was a temporary deprecation whilst broken functionality was fixed (to which @martjn gave his customary flippant and utterly useless reply), and then when helpfully requested by @ronie I listed a few use cases where I described why I considered the deprecation a step backwards:
https://github.com/xbmc/xbmc/pull/9595#i...-212016267
Going off slightly on a tangent for a moment; you can see, I was ultimately shot down in flames, clearly @tamland doesn't think I should take this statement personally:
"What's broken here is the utter mess that is super favourites. If you actually expect anything in that addon to work from revision to revision, I cant help you... Instead of complaining that one of your many hacks and workarounds broke, you should try finding proper solutions to you problems." tamland
"spoyser you're taking this way too personal. It's not:\" tamland
If that ain't personal I don't know what is.
Anyway - back on track.
For the record - My opinion is quite clearly that it is a bad thing .
1) The built-in "Add to favourites" doesn't always work, eg sometime the item needs to be tweaked before adding, eg changing the visible text, modifying path, etc.
2) Queue item, Play, and Make default always seems to always appear for music items regardless of their playable status (maybe just a bug in the current implementation)
3) The auto-added items always appear after the addon-added items, this layout isn't always the most sensible layout.
I was wondering if any other addon developers have an opinion (either way) on whether deprecation of the replaceItems parameter and therefore the inability for an addon to fully define its own context menu is a good thing, bad thing, or neither here-nor-there?