Unify context menus

[tamland]

This is a start at fixing current context menu code and move it to a global item based system (which will also support arbitrary nesting of menus). We already have this for addons, so this PR simply hooks up this system to allow non-addon menus to be added, and adds Interoperability with the old system.

Also adds context menu support to directory providers and ports a few menus as examples.

Next: port all current context menus to IContextMenuItem implementations and drop the old ones. Volunteers?:)

[Tolriq]

@tamland do you think that after this PR it will be possible to extend that so it can be accessed from JSON RPC ?

[razzeee]

Awesome, very good step into the right direction. I really hated all those add(menuItem) scattered everywhere.

[BigNoid]

Awesome indeed, this adds a wide range of possibilities.

[razzeee]

@tamland
please pick razzeee@6112c08

and consider razzeee@222ae61

[razzeee]

Pick 1d4a76f for the remaining musics info stuff

The bottom left menu part is missing for some reason, but might be skin related? @phil65

[phil65]

yes, skin related.
@tamland latest estuary master already contains homescreen preparations so that the infoscreens mostly look fine.
Thx for this! Really awesome work.

[Montellese]

Nice work (haven't looked at all the changes).

Personally I'd prefer the CTvShowInfo implementation example to be in its own class and part of the xbmc/video directory because that's where it belongs.

I'm also not a huge fan of having a huge list of "interface implementations" hardcoded in the manager initialization. Every implementation should be injected into the manager from some place where it belongs. But that's not easy to do (which is why I haven't solved it yet either in my media importing stuff).

[da-anda]

one thing to keep an eye on is that if users modify an item in the info views (like slecting a new poster), that the underlying window needs to be notified to update the info of this item as well or it will show the old artwork/name f.e.

[tamland]

@Montellese If it wasn't clear, the implementations here was just proof of concept. I don't intend to have them all in one huge header file! The final connection of implementation the manager however is by design done in a central place atm. This is to keep it simple and straight forward, and it's required to have complete control of ordering here.

@razzeee I've take the liberty of refactoring the info menus because that turned into way too much boilerplate too fast:) As @Montellese said we should try to find appropriate places to keep the implementations. Keep them coming!

[razzeee]

@tamland
did you miss 1d4a76f ? or should I refactor it accordingt to the new way?

[Montellese]

@tamland: Ah I didn't realize that order matters. Maybe this should be documented in a comment somewhere near the definition or initialization of m_items.

[razzeee]

@tamland
Pick razzeee@ad5df93

We will also need a xcode and vs sync when we're done with everything.

[tamland]

I've added a few more menus. I think I'll stop now, otherwise I'll never get done:)

Still looking for xcode. Anyone? @anaconda?

[razzeee]

Should I look at vs sync again if you say your done for now?

[tamland]

Shouldn't be necessary. I've done it manually

[anaconda]

@tamland Last 3 commits here add the new files to Xcode:
https://github.com/anaconda/xbmc/commits/9257-xcode

[tamland]

Thanks @anaconda!
jenkins build this please

[tamland]

jenkins build this please

[NedScott]

Is this all "under the hood" or does it need any changes to the wiki? (granted, the wiki isn't entirely up-to-date on context menu options as-is)

[tamland]

Mostly 'under the hood', yes, but there's a few smaller adjustments to the some of the current menus. There will likely be more changes before Krypton though, so I would wait with updating the wiki until it 'settle'.

[NedScott]

That sounds good. Those will probably be picked up as we start to take new screenshots for everything, due to the new skin :)