[Martijn]

As discussed at last years devcon adding a <support> section in addon.xml for addons would solve the problem of people installing touch only skins without them having touch systems and get stuck. there's no way back besides removing the guisettings file or the skin itself.

this has some advantages.
* warn users that they are installing something that their system doesn't support
* show if skins support feature foo

So discus what's the best way to do this.
imo this is something that we should have in Gotham (if time permits ofcourse)

Possibilities:
Option1:

PHP Code:

<extension point="xbmc.addon.metadata">
  <support>
    <pvr>false</pvr>
    <input>
      <keyboard>false</keyboard>
      <mouse>true</mouse>
      <touch>true</touch>
    </input>
  </support>
</extension> 


Option2:

PHP Code:

<extension point="xbmc.addon.metadata">
    <support>mouse touched pvr</support>
</extension> 


Option3:

PHP Code:

<extension point="xbmc.addon.metadata">
  <supports>
    <support>pvr</support>
    <support>touch</support>
  </supports>
</extension> 


or if some one knows a better way......

[Montellese]

As already mentioned on github I don't really like the second option simply because it kind of defeats the purpose of XML. I know we use this approach already in addon.xml because it can easily be read by cpluff as a single tag/element and then parsed in some CAddon implementation. The disadvantage is that you can't really write a good XSD for it and it might not be obvious which "keywords" are available and valid.

Whatever approach is chosen I agree that this is something we need. It allows us to inform users about special or missing functionality in a skin before installing it. While we can't really know whether an installation only supports touch input or if there's also a keyboard attached we can tell the user before the activation of a skin that there might be a problem. Same goes for PVR support.

I will also needs something like this in plugins to be able to state if a plugin supports the import of plugin items into the local library.

Besides the question of how to write this in XML I'm also not sure about where to put it. The above examples only make sense for skins but not for scrapers, plugins etc. The stuff I'll need in the future for library import will only make sense for plugins but not for skins etc. So either it should go into the addon type specific extension point (which would allow the definition of very specific XSDs) or it goes into xmbc.addon.metadata and is just ignored for addon types where it doesn't make sense.

[Martijn]

in that case i'm pro for the addon type specific section.

[Montellese]

Yeah addon type specific would be better but I'll have to look into the code. A huge advantage of putting it into xbmc.addon.metadata could be that the parsing could happen in a single place and for every addon listed in the GUI. If it's in the addon type specific section, the parsing also needs to happen in the addon type specific implementation and I'm not sure if those are triggered when listing addons. I'm also not sure on how to expose addon type specific info to the GUI (list or info dialog).

[Martijn]

let's start simple and just warn a user. expansion on the gui can happen at later time.
atm the most important one it touch/no-touch support.

garbear said he is somewhat familiar now with the addon code so guess he could take a peak too.

[Montellese]

Well we want to get it right the first time as we shouldn't really change the format after we introduced it and if putting the info into the addon type specific part prevents us from properly accessing it then we need to consider that. But this kind of information probably doesn't make any sense anyway in the list item. It only makes sense in the info dialog where there's some space available to show this kind of information. And when opening the info dialog we access the full addon type specific information.