(2013-02-05 18:23)sphere Wrote: 2.1 always included skin graphics
It would beautify and unify the look of most plugin add-ons if skins would include (and this should be a requirement) reusable graphics (with a defined naming scheme) like:
Then add-on devs could trust on that such graphics exist on EVERY skin and could start using them for their pagination (and search).
I wouldn't force skins to include these graphics but rather make it suggestion. If skin wouldn't have such images we would fallback to graphics provided by plugin (we would need to add some mechanism to do it this way). This would be short term, long term I would like to add nice pagination handling in xbmc gui (maybe something like infinite scroll, so we stay in same list and items are being appended on demand) and same with search (so user could use global search that would search local library and addons that support searches and show results from different sources in same list)
(2013-02-05 18:23)sphere Wrote: 2.2 View-IDs
In some cases a Plugin view looks better (or even only makes sense) if the skin is forced to use a thumbnail-view (the default view in most skins is "list view").
At the moment you can do - but you need to know the view-id for the wanted "style" (thumb/list/...) for the skin the user is using.
Example, if you want to force any kind of thumbnail-like view you need to have a look to EVERY skin manually to find a matching view (and recheck on every update of the skin!) and hardcode it in the add-on code. Here is an example for the a "thumbnail"-view for some major skins:
One possible solution would be if skin authors would be able to (and pleased to do so *g*) define some "basic" view-IDs for plugin-usage by name in their addon.xml. And this defines should be accessable by plugins.
One simpler (at least I guess it is simpler...) solution would be to allow view-ids to be strings and add the convention that every skin needs to have some basic views defined.
return xbmcplugin.endOfDirectory(success=True, default_view='thumbnail')
We have <viewtype> that specify how given view look like (from wiki: "The type of view. Choices are list, icon, wide, wrap, biglist, bigicon, bigwide, bigwrap, info and biginfo."). I think this could be used by plugins to state what viewtype is prefered, "thumbnail" would be "icon" viewtype I guess.
(2013-02-05 18:23)sphere Wrote: 2.3 Big Text Dialog/Window
It would be a good addition for add-on developers if every skin would include one additional xml defined dialog: A "Big Text Dialog" Something like a huge OK-Dialog. Add-ons could open that dialog modal to show a changelog or a small how-to-use-this-addon-text on their own - but with matching the look of the current in use skin.
I think we should try to make standard Ok-Dialog auto-sizable instead to avoid adding yet another dialog that need maintaining
(2013-02-05 18:23)sphere Wrote: 2.4 Skin defined fonts and font sizes (thanks to bossanova808)
Some definition of standard fonts and font sizes - so that a WindowXML will at least somewhat across most skins without awful font overlaps etc. At the moment if you do a WindowXML of any complexity you basically need all the skinners to hop on board for it to be usable. If there were some standardised options:
- Very Large
- Very Small
....always the same sized, then addons would instantly be at least usable on other skins...
Something like this is obviously needed, WindowXML has great potential but because of lack of some standards it usually looks awful on non-confluence skins. I think that we need more than just font sizes here - at very least we need to describe what font styles (font family + font size + font weight/italics + upper/lower case + color) are used for in skin - some dialog headings might use same font size as button labels but mixing it will still make WindowXML look not as nice as it could.