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?
Addon developers should have full control over context menus in their addons, period. IMO there are no sound reasons for depreciation of the parameter in question.
From my own perspective, there are times when I don't think it's helpful to be showing - at the very least - the add to favourites context menu item. In this example library node editor, for example...
... this isn't an item that it makes any sense to be able to add to favourites (clicking it launches the process to change the grouping of the given node - the added favourite gives that same behaviour, but without any of the context of doing it from within the editor). However, it doesn't cause any actual issues with the script...
+1 for freedom. Not judging any addons or devs here. Just not liking anything forced. Goes for lots of build in stuff too. Peace :-)
My personal preference would also be to keep that option. Some of the (quite creative) usecases mentioned just work better when plugin authors have full control over context menu.
@spoyser: I can understand that you might be a bit frustrated, but in all fairness, tamland wasnt insulting, there was nothing personal involved. He was harsh on your code (imo too harsh) but that's quite different from being insulting. So please dont blow things out off proportion. You have to understand that his POV is different than yours since he knows the core side of the python plugin API very very well. And also take into account that he was annoyed by my comments already, so you probably just popped up at the wrong time. ;D
EDIT:
also, just for context: The changes are related to the contextmenu rework in general. That rework should signifanctly reduce the need for that replaceItems option (contextmenu entries are now really contextual to the listitem), that's why there was a push to remove that option.
(2016-04-21, 15:46)phil65 Wrote: [ -> ]My personal preference would also be to keep that option. Some of the (quite creative) usecases mentioned just work better when plugin authors have full control over context menu.
@spoyser: I can understand that you might be a bit frustrated, but in all fairness, tamland wasnt insulting, there was nothing personal involved. He was harsh on your code (imo too harsh) but that's quite different from being insulting. So please dont blow things out off proportion. You have to understand that his POV is different than yours since he knows the core side of the python plugin API very very well. And also take into account that he was annoyed by my comments already, so you probably just popped up at the wrong time. ;D
EDIT:
also, just for context: The changes are related to the contextmenu rework in general. That rework should signifanctly reduce the need for that replaceItems option (contextmenu entries are now really contextual to the listitem), that's why there was a push to remove that option.
Not a problem.
Just to clarify, I started this thread for one reason and one reason alone. To promote an open discussion about this important area of Kodi
There used to be a limit of 10 items in a context menu. Will that limit still be in place for Krypton? If so, will the core menu items subtract from that limit?
There are a lot of cases in addons where Mark as Watched will not work properly. Showing it for all playable items seems like it will confuse alot of users.
The same goes for Add to Favourites. In some addons, items are playable depending on configuration. If you change that setting, then the list item changes as well so you can end up with duplicates in favourites and the default menu item behaves strangely because it shows "add to favs" for items that are already in favs.
IOW, there are good legitimate reason to hide the core menu-items: sometimes they don't work with how the addon works.
Why not just replace favourites with super favourites. Imho this useful addon could be a huge step forward for Kodi.
First, a huge thanks to all the hard work done by the core devs. In my humble opinion Kodi should provide the base framework for a gui, database, and metadatahandling. Nothing more. But excel in that and offer the rest in script unless it is faster through xml. I personally dislike all that is forcefully buuld in and not possible to use unless you follow certain id naming and other hidden conventions. Set it all free. Focus on core. The rest will be build by skinners and scripters.
(2016-04-21, 18:15)Torben Wrote: [ -> ]In my humble opinion Kodi should provide the base framework for a gui, database, and metadatahandling. Nothing more. But excel in that and offer the rest in script unless it is faster through xml.
I wouldn't want to code things like Favorites. I think that there should be the standard options just to keep the UI concistent. If the function behind the option is faulty, it should be fixed in the core.
On the other hand, I'd vote to convert the "Favorites" to an add-on. So it would be up to the user to install drop in alternatives, if the default one is too simple.
Please keep things ontopic
Gesendet von meinem D5803 mit Tapatalk
Sorry. I tend to ramble.. :-) ...aaand as long as whatever extra stuff in Kody isnt forced. People can have fun coding whatever they like ;-)
(2016-04-21, 18:07)butchabay Wrote: [ -> ]Why not just replace favourites with super favourites. Imho this useful addon could be a huge step forward for Kodi.
Yes I agree that Super Favourites brings to Kodi to a much higher level of usefulness, and I'm surprise the devs haven't purloined it yet. It's one of my must haves and a Kyrpton update without SF is something I wouldn't look forward to.
+1 on item 2 , some context menus are always there, it wasnt even working for music addons to replaceitems=true,
Also, in music again
Container.Content("songs", "artists", "albums", "movies")
Does not return even though content is set,
Again in player, infolabels are not parsed correctly to played item inside the player.
Since there are real issues with python api, i think even discussing removing context items is bizzare,
How about replacing python with javascript engine? So addon devs can parse nested dirs containing avi files at ease.
If you lock Kodi to superfavorites addon youll miss out on the next greatwst of the week addon regarding favorites. And now with tag support we can probably code alot of cool new stuff including favorite handling for the whole family or whatever. Tag:daddy favorite? I personally dont use favorites but i do mark items of interest tjat i stumple upon. More of a bookmark really.
Alao, python is awesome.