[robwebset]

Hi All,

I have noticed a change in behaviour (Well, a user of the Sonos Addon has) between Frodo and Gotham in Confluence.

If you add an addon to the home screen via the "Shortcut" option in settings, then:

• In Frodo: it runs the script
  
• In Gotham: it runs the plugin
  

Is there any way to force it to run the script rather than the plugin (So make it all like it was in Frodo)?

Thanks

Rob

[jmarshall]

It comes down to the order of the add-ons in the addon.xml file in addition to the call made by the skin.

I'm not sure what Confluence is using, but if it's RunPlugin() then there's your answer.

[robwebset]

Thanks @jmarshall, the order in the addon.xml is (the same for both Frodo and Gotham):

Code:

    <extension point="xbmc.python.script" library="default.py">
        <provides>executable</provides>
    </extension>
    <extension point="xbmc.service" library="service.py" start="login">
        <provides>executable</provides>
    </extension>
    <extension point="xbmc.python.pluginsource" library="plugin.py">
        <provides>audio</provides>
    </extension>

So, it sounds like the script should be called first - so I wonder if confluence is calling RunPlugin() - is this something that would have changed from Frodo to Gotham?

Thanks

Rob

[robwebset]

OK, I have done some more testing, and this is definately a change in behaviour in Gotham (base code - not the skin - as that has not changed) for the following call in the Skin:

Code:

RunAddon

For Frodo, if there were multiple - it called the Script, for Gotham it calls the plugin.

The skin (Confluence in this case) can be changed to support both and work around this, so in the file IncludesHomeMenuItems.xml, in the include section HomeAddonItems[Videos|Music|Pictures|Programs], change the calls to look something like the following:

Code:

<item>
    <label>$INFO[system.addontitle(Skin.String(HomeMusicButton1))]</label>
    <onclick condition="!SubString(Skin.String(HomeMusicButton1),script,Left)">
        RunAddon($INFO[Skin.String(HomeMusicButton1)])</onclick>
    <onclick condition="SubString(Skin.String(HomeMusicButton1),script,Left)">
        RunScript($INFO[Skin.String(HomeMusicButton1)])</onclick>
    <icon>$INFO[system.addonicon(Skin.String(HomeMusicButton1))]</icon>
    <thumb>-</thumb>
    <visible>!IsEmpty(Skin.String(HomeMusicButton1))</visible>
</item>

This works on the theory, that if you called the plugin script.* then it's primary function is to be a script (the plugin bit is just an extra).

Thanks

Rob

[jmarshall]

RunAddon prioritises plugins, then scripts, yes.

RunScript runs the first thing it finds.

[robwebset]

RunAddon prioritises plugins, then scripts, yes.

RunScript runs the first thing it finds.

Thanks for the clarification jmarshall.

Any particular reason this was changed for Gotham?

Rob

[jmarshall]

Yeah - there was basically no real consistency between what was done when you executed an add-on, depending on where it was located in the XML etc.

Now we have a bit more consistency than what we had.

[robwebset]

RunAddon prioritises plugins, then scripts, yes.

RunScript runs the first thing it finds.

I have done a bit more testing with this. I don't think this will work as you expect.

The RunAddon, looks like it always runs as a plugin.

The RunScript will indeed run the first item in the list, if this is a script - then that is fine. But if it is a plugin it will fail as there is no arguments passes in, when an addon_handle would be expected:

http://wiki.xbmc.org/index.php?title=Aud...n_tutorial

So it is not possible to just switch uses of RunAddon to RunScript - there needs to be a check some-where to work out which one to run.

Thoughts?

Thanks

Rob

[robwebset]

FYI:

I have raised the following pull request for this one:

https://github.com/xbmc/xbmc/pull/4936

[jmarshall]

IMO the only correct way to fix this is for the caller to ask specifically for which type they wish to run.

An add-on can quite happily provide more than one entry point, and there's no way to properly distinguish "automatically" what the intent is without the caller providing that information.