[tknorris]

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

I have the same problem with favorites. There are configuration changes in some of my addons that change the plugin:// url that is built for the list item. All kind of bad things happen in Kodi favorites when this happens, like:

1. The favorited item no longer works properly because it has the wrong plugin url for the current addon configuration; (e.g. media vs window)
   
2. You can no longer remove the favorite from within the addon because the generated plugin url no longer matches the one in favorites.
   
3. You end up with duplicate list items in favorites because the pre- and post- configuration plugin:// urls don't match. So the user can add the same list item twice.
   

To top it all off, replaceMenuItems is called "deprecated" but deprecated doesn't mean "immediately removed", so there's not even a transition period. -1 for Project Management.

[tknorris]

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.

I've given real world examples of where things don't work, so saying "...All i see here is complaining that you can't do things as they used to be..." is just plain inaccurate.

[Martijn]

To top it all off, replaceMenuItems is called "deprecated" but deprecated doesn't mean "immediately removed", so there's not even a transition period. -1 for Project Management.

You have a deprecation time from v16 to v17 and that should be more than enough.

Also seeing what add-on you make i'm sure no one on the team give a crap what you think.

[tknorris]

To top it all off, replaceMenuItems is called "deprecated" but deprecated doesn't mean "immediately removed", so there's not even a transition period. -1 for Project Management.

You have a deprecation time from v16 to v17 and that should be more than enough.

Also seeing what add-on you make i'm sure no one on the team give a crap what you think.

Maybe it's a English translation thing, but that's not what "deprecate" means...I suppose it's irrelevant because it is what it is, but it just irks me that you guys are doing one thing and calling it something else. Maybe if it was "deprecated" though there would actually be time to put in a solution that actually works instead of just removing it all together. Personally, I would not have a problem w/ core menu items showing up if there was a way to attach a callback to each one so that the ones that you can use would be functional, and the ones that didn't work wouldn't cause erratic behaviour.

Edit: Yes, because you don't like what I write, my technical opinion has no merit...If you can't attack the argument, attack the person...Typical .org BS.

[Wintermute0110]

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.

Excuse me? Cleaning the core? I have see the patch in github and the thing you are doing is removing functionality. Before, some developer said "we want to keep and unified UI". That is a legitimate reason and we can argue about it. Now, you default to the universal "we are cleaning the core". That's not a reason, it is just "we want to do this and will do whatever you say".

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.

I have stated the reasons why Adanced Launcher needs a custom Favourites in their context menu. You can find them in the previous post, for your convenience, so please read them. Also, can you answer the question I asked there about managing Kodi's favourites in case we are forced to use them?

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.

OK, illuminate me and tell me how addons will work with "unified" context menus and very useful options like "Go to root" appearing always in the first positions.

[sarbes]

Guys, I know that this state is not perfect, but it should be fixed at the root.

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.

Would it be feasible to move the favorites to an add-on? I don't think that a python implementation would be that difficult.

[spoyser]

Would it be feasible to move the favorites to an add-on? I don't think that a python implementation would be that difficult.

You mean like

http://forum.kodi.tv/showthread.php?tid=192662

[sarbes]

You mean like

http://forum.kodi.tv/showthread.php?tid=192662

Exactly.

[Ned Scott]

I almost hate to ask, but did anything come of this? A new method that did the same thing or something along those lines?

[Wintermute0110]

I almost hate to ask, but did anything come of this? A new method that did the same thing or something along those lines?

For Advanced Emulator Launcher it's OK. In Krypton you cannot disable the default context menu, however it has improved a lot compared to Jarvis. For example, custom set context menu entries are always on top (in Jarvis Kodi default entries were always on top), the nonsense "Go to root" option has been removed, and the default Kodi context menu changes depending on if your are on a directory, playable item, etc. which is nice.

[bigretromike]

If I'm unable to use my own context menu inside my own plugin can I somehow overwrite items in current context menu?

User case:
My "mark as watched" work differently from kodi ones, when I mark something as watched it send the information out to 3rd party service so the status is marked there also I also do it when someone watch let say 80% of movie, but I would like to use context menu like before. Now I have two "Mark as watched" items in context menu and have to change name of mine to not confuse users.

I saw few plugins use they own context menu which have to be be trigger from normal context menu so that is not as great.

I understand that there was a cleaning etc, but is there a way to overwrite action of button or handle Mark as Watched/Unwatched by addon without using the build in ToggleWatchedStatus?

[da3dsoul]

To give a bit more info to @bigretromike's situation (https://github.com/bigretromike/nakamori), we work on an addon that is a front end for Kodi to play and display metadata for a library metadata manager for anime. Anime has always been a niche, and Kodi wasn't made to match the (different) conventions to naming and numbering files. We get around this by using a much better metadata manager and simply serving files and information to kodi (the point of an addon). There used to be an issue where we used Kodi's built in Mark as Watched system, and it would become desynced from the metadata manager, amongst other annoying problems. We remedied that by completely bypassing the built in system and refreshing the container (which has its own issues, but they aren't as annoying) so that the updated watched status in the metadata manager would update. Ideally, we could have a callback to override Add to Favorites, Mark as Watched/Unwatched, etc so that the addon can't completely remove 'core context menu items' like @tamland seems to be so against. This would need to be able to negate the built in behavior, because Kodi caches watched states, and once it does, the cache needs to be cleared in order to overwrite the watched status again (a bug maybe?).
If you need more 'use cases' in which you need to manage watched states separately from Kodi: anything that syncs watched states across devices.
We also could use (I wouldn't say need in this case) a way to at least determine where the items show up in the menu. I don't mean to say that we reorder the menu. In brm's example, most of our context menu items should go between Play/Play using... and Add to Favorites, but instead looks like:
More Info
Mark as Watched
Vote
Play
Play from here
Mark as watched
Add to Favorites

Ideally, it would be:
More Info
Play
Play from here
Mark as Watched
Vote
Add to Favorites

In our case, it goes with the core format, but we have duplicates because we have no way (that we know of) to hook into the Mark as watched item, and the menu looks weird, because Play is half way down the list instead of near the top or at the top.

[Wintermute0110]

@bigretromike @da3dsoul Your ARE ABLE to use your own context menu. The difference between Jarvis and Krypton is than in Krypton you will have some entries, at the bottom of the context menu, you cannot get rid off. However, this entries are useful, like "Add to Favourites", "Play", and change depending if the listitem object is a directory or a playable item.

[da3dsoul]

@Wintermute0110 We are aware we can add context menu items. The context sensitive context menu (redundant I know, after all these years some people forget why it's called a context menu) is a good idea. I'm not saying there is anything wrong with it. If anything, I would completely believe we are just doing something wrong.
Nakamori uses the following:
Main Menu - a list of directories containing various other directories
--Series view - holds either directories pertaining to episodes, creditless openings or endings, Specials, etc
--Episode view - contains items marked as playable, but fed plugin links with extra info like the episode id for scrobbling to the metadata manager
When an episode is clicked, it calls the plugin/addon and then separates the info, generates a link to a file or URL with a file stream, plays the file, uses setResolvedUrl to pass a valid listitem, watches the play status like the trakt addon, and marks it as watched after stopping playback on the server.

If that is not the appropriate way to handle the previous behavior, please let us know, because all of the docs and posts I've found show it done like that.

That was sort of on a tangent, but the point is that the context menu items are applied appropriately based on context. We even conform to the ideal of 'context menus' being contextual. What we don't like is that there is currently no way (that we've found) to use what is there in a way that works properly. I described why Mark as Watched doesn't work. I personally don't use favorites, so I can't give much input, but I've heard some plugins have issues with it on the forums. The other request I made was more of an aesthetic thing, it's not a huge deal, but looks odd. We should be able to place our items after play, but before Add to Favorites. I honestly think that's where all plugin context items should go for playable items, but I recognize that unless I start being a meaningful contributor to Team Kodi, my opinion on that matter, like most matters in regards to someone else's project, is moot.

Another way I can think of to make Mark as Watched work would be to have a callback to add additional functionality to Mark as Watched (scrobbling purposes), but also a way to forcibly set the cache's status instead of toggling with ToggleWatched. So rather than attempting to create the listitem, then immediately retrieve the data to make sure it matches the data we just set, and verify the cache isn't overwriting it, we can simply set it in the cache when creating the listitem and update it as needed.

I know that the next line from Team Kodi is likely to be something in regards to use cases, or more specifically, that they don't use it, and as such don't have a good reason to write it, which as a hobby developer, I understand all too well... Still, it'd be nice to have some decent support for scrobbling a file (and syncing the status back) without extremely hacky methods that likely rely on what the team would call bugs... please... I'm willing to help by looking into writing it myself, but I'd like to know what is thought about the idea before I bother wasting hours of testing scrobbling, which takes more time testing than writing.

[Wintermute0110]

@Wintermute0110 We are aware we can add context menu items. The context sensitive context menu (redundant I know, after all these years some people forget why it's called a context menu) is a good idea. I'm not saying there is anything wrong with it. If anything, I would completely believe we are just doing something wrong.
Nakamori uses the following:
Main Menu - a list of directories containing various other directories
--Series view - holds either directories pertaining to episodes, creditless openings or endings, Specials, etc
--Episode view - contains items marked as playable, but fed plugin links with extra info like the episode id for scrobbling to the metadata manager
When an episode is clicked, it calls the plugin/addon and then separates the info, generates a link to a file or URL with a file stream, plays the file, uses setResolvedUrl to pass a valid listitem, watches the play status like the trakt addon, and marks it as watched after stopping playback on the server.

If that is not the appropriate way to handle the previous behavior, please let us know, because all of the docs and posts I've found show it done like that.

I had never use setResolvedUrl() myself. Advanced Emulator Launcher is a launcher plugin, not a video provided plugin. Things is, there could be several ways to achieve something in the Kodi API. Most important thing, in my opinion, is that what you want to do works and does not produce ERRORS/WARNINGS in Kodi log. When testing I'm always looking at the Kodi log using 'tail -f'.

That was sort of on a tangent, but the point is that the context menu items are applied appropriately based on context. We even conform to the ideal of 'context menus' being contextual. What we don't like is that there is currently no way (that we've found) to use what is there in a way that works properly. I described why Mark as Watched doesn't work. I personally don't use favorites, so I can't give much input, but I've heard some plugins have issues with it on the forums. The other request I made was more of an aesthetic thing, it's not a huge deal, but looks odd. We should be able to place our items after play, but before Add to Favorites. I honestly think that's where all plugin context items should go for playable items, but I recognize that unless I start being a meaningful contributor to Team Kodi, my opinion on that matter, like most matters in regards to someone else's project, is moot.

To mark a listitem as watched you have to use the overlay as described here. Also, not all skins will show the item as watched, since displaying it is a skin feature.

Also, it is hard to me to understand what you really want to do... can you please give a more clear example? Maybe I would be able to help you better. Also, my knowledge of the Kodi API is limited and I'm not a skinner.