[boogiepop]

i was being sarcastic

[spoyser]

@phil65

How about this as a compromise, shame the git thread is now locked otherwise I could have added it there:

Leave what is currently there as it is (assuming not real bugs), but also allow a developer to add a callback that is invoked rather than Kodi showing a menu. This callback could utilise the xbmcgui.Dialog().contextmenu functionality to allow an addon to fully customise and handle its own context menu, whilst leaving the core context menu stuff untouched.

This callback could follow the current addon callback system, so an example syntax would be something like:

Code:

callback = 'plugin://plugin.super.favourites?mode=contextmenu&param1=x&param2=y' #etc
xbmcgui.ListItem.addContextMenuCallback(callback)

When the user then triggers what would normally display the context menu, the callback is invoked instead and the addon deals with how it see fit.

In fact the addon could actually do whatever it wants, it wouldn't even need to display a context menu if that wasn't appropriate, it could open up a whole new world of functionality within the addon based on the current context

[Torben]

+1 for a custom menu! Definitly!

(Hopefuly one that works on static lists from scrips as the whole plugin business appears to be the slow way to fill lists. ;-))

[ed_davidson]

Why not just replace favourites with super favourites. Imho this useful addon could be a huge step forward for Kodi.

I'm all for that. Super Favorites is far better than the Kodi Favorites Menu. My build relies completely on the Super Favorites Integration.

[sarbes]

I'm all for that. Super Favorites is far better than the Kodi Favorites Menu. My build relies completely on the Super Favorites Integration.

And I'm against it. I am happy with the normal favorites, I don't need a complex extension. An add-on approach like I described would be far better for everyone, don't you think?

[spoyser]

Please stop discussing favourites.

This thread is simply about the deprecation of functionality when creating context menu content.


Sent from my iPhone

[sarbes]

This thread is simply about the deprecation of functionality when creating context menu content.

Could you give me an example where else it is necessary to manipulate the existing menu items? I think it is better to offer the same items for every playable media source, to keep the UI uniform (additional entries are still welcome). If an existing function isn't working correctly, it should be fixed at the core.

[tknorris]

I don't think I can fully express how much I hate having a duplicate Mark As Watched menu item in my addons that won't work properly since the addon doesn't reflect Kodi's watched status...It's going to cause me no ends of user support problems.

I think if menu items are not going to be removable, they should at least allow callbacks so that they can be reused.

[Torben]

There is always the option to completely remove all context menus from your skin.

[ronie]

I don't think I can fully express how much I hate having a duplicate Mark As Watched menu item in my addons that won't work properly since the addon doesn't reflect Kodi's watched status...

i have not tested it, but i think the kodi 'mark as watched' item should reflect the 'playcount' infolabel the addon adds to it's listitems.
might be worth to give that i shot (if you haven't done so already).

[Wintermute0110]

I am developing an improved version of Advanced Launcher (AL), which is now unmaintained.

One of the annoyances of AL was that unnecessary context menu entries appear all the time when navigating Categories/Launchers/ROMs. Also, for AL it does not make sense to use Kodi Favourites since user can rename/change ROMs and that will break the URLs stored in Kodi favourites. I am implementing a custom Favourites within the addon to handle this BUT if Context Menu cannot be customised then my addon will be broken before it is finished!!!!

+1 for keeping the feature of changing the default context menu. I do not understand at all why developers want to remove something which is harmless and useful and force addon developers to use Kodi favourites even when it makes no sense for the particular addon

[sarbes]

One of the annoyances of AL was that unnecessary context menu entries appear all the time when navigating Categories/Launchers/ROMs. Also, for AL it does not make sense to use Kodi Favourites since user can rename/change ROMs and that will break the URLs stored in Kodi favourites. I am implementing a custom Favourites within the addon to handle this BUT if Context Menu cannot be customised then my addon will be broken before it is finished!!!!

I would argue that the favorite option for folders should be optional, based on the property. It doesn't make much sense to fav a "Search" folder - folders like "Snes" should be possible. Make the context more contextual.

+1 for keeping the feature of changing the default context menu. I do not understand at all why developers want to remove something which is harmless and useful and force addon developers to use Kodi favourites even when it makes no sense for the particular addon

It makes sense to make the UI uniform. I (and probably a lot of other users) don't like extra favorite menus for every add-on, each with different quirks and features. I agree that there is much room for improvements, but we should focus on a proper solution instead.

My proposals/ideas:
1. Move the favorites out of the core. Convert it to an add-on - this would spark real innovations.
2. Introduce an infolabel for a hard link. Prefer this path if the item is added to the favorites (not sure if this is necessary).
3. Make it possible for the add-on to adjust the entry if something changes (like the name or availability).
4. Add local favorites. This will allow the user to organize the entries by add-on.
5. Add an infolabel for a hard link to the newest episode/item in a folder (handy for things like news broadcasts).
6. Add an infolabel for the folder type. Possible values for non "fav-able" folders: "search", "major directory".
7. Before populating a folder, check if the items are favorites. Add a star if it is a fav (similar to browsers).
8. Put dedicated "Search" and "Favorites" icons/shortcuts in the skin. This gets rid of two very common add-on entries and cleans up the UI.

Currently, SLiX is writing a small add-on wich includes #4. We could also include #2, #5 and #6; aswell as support for #3 and #7. #7 and #8 need help from the skin to work.

[tknorris]

I don't think I can fully express how much I hate having a duplicate Mark As Watched menu item in my addons that won't work properly since the addon doesn't reflect Kodi's watched status...

i have not tested it, but i think the kodi 'mark as watched' item should reflect the 'playcount' infolabel the addon adds to it's listitems.
might be worth to give that i shot (if you haven't done so already).

Yep, I agree it does Ronie, but the problem is that I set the playcount in my addon based on the user's trakt watched status and I can't capture the Kodi version of Mark as (Un)Watched so it's just a useless menu item that user's will click that won't do anything. Either that, or they will pick it, and cause kodi to override the watched status I set and then their checkmark won't sync to trakt any more the way it should (and always has pre-Krypton).

[Wintermute0110]

One of the annoyances of AL was that unnecessary context menu entries appear all the time when navigating Categories/Launchers/ROMs. Also, for AL it does not make sense to use Kodi Favourites since user can rename/change ROMs and that will break the URLs stored in Kodi favourites. I am implementing a custom Favourites within the addon to handle this BUT if Context Menu cannot be customised then my addon will be broken before it is finished!!!!

I would argue that the favorite option for folders should be optional, based on the property. It doesn't make much sense to fav a "Search" folder - folders like "Snes" should be possible. Make the context more contextual.

I do not understand what you try to say. Can you please reword?

+1 for keeping the feature of changing the default context menu. I do not understand at all why developers want to remove something which is harmless and useful and force addon developers to use Kodi favourites even when it makes no sense for the particular addon

It makes sense to make the UI uniform. I (and probably a lot of other users) don't like extra favorite menus for every add-on, each with different quirks and features. I agree that there is much room for improvements, but we should focus on a proper solution instead.
...

In my opinion, addons were created to extend the functionality of Kodi, without changing the core. Now, core developers are trying to force addon developers to have "unified" default context menus, even if they are not relevant at all for that particular addon. If an user installs an addon is because that user wants to use the addon an all the functionalities it gives, not because the user wants a "unified UI" across all addons! Addons are optional, is that simple: I do not like the addon, I do not install it or remove it. Having mandatory stuff into something that is optinal does not make sense! (Let me explain: UI is quite uniform across addons because the views are all the same. However, if there is something that must be customizable is the context menu).

Main problem with Advanced (Emulator) Launcher is that the media is manages changes frequently (new MAME version, new ROMs...) and the addon should be able to deal with this changes in the list of favourite ROMs. Also, I am sure that most users do not want to mix their movie/music/stream favourites with their ROMs favourites.

In case core developers force the default context menu, is there a way I can retrieve Kodi's favourites, detect if they belong to AEL, and manipulate them everytime ROMs are updated

By the way, a little bit off-topic, but something really useful and that many people want is to increase the number of views for program addons.

[Martijn]

All i see here is complaining that you can't do things as they used to be. Well face it time changes. We are trying to clean up core and in that proces context menu also got cleaned up.

Start listing the EXACT positions things don't work instead of repeating the same stuff all over again. The way you guys are taking this on now will not change anything. With the correct problem listing you or our devs could see what places are wrong or not working. Perhaps extend the core hooks that things do work. Keep yelling that you want old behaviour back is certainly not working.

Kodi is moving forwards and not staying stuck in the past where the context menu was just a bunch of whatever was slapped into core.