(2013-02-06, 19:29)da-anda Wrote: argh, tried to split your post, but it only would create a new topic. All I could do is to increase the max post length to fix it

edit: just increased the max length for posts, so you should be able to edit it again.

(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:
- "NextPage.png"
- "PreviousPage.png"
- "MoreItems.png"
- "Search.png"
- ...
Then add-on devs could trust on that such graphics exist on EVERY skin and could start using them for their pagination (and search).

(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:

Code:

'thumbnail': {
        'skin.confluence': 500,
        'skin.aeon.nox': 551,
        'skin.confluence-vertical': 500,
        'skin.jx720': 52,
        'skin.pm3-hd': 53,
        'skin.rapier': 50,
        'skin.simplicity': 500,
        'skin.slik': 53,
        'skin.touched': 500,
        'skin.transparency': 53,
        'skin.xeebo': 55,
    },

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.
Example:

PHP Code:

return xbmcplugin.endOfDirectory(success=True, default_view='thumbnail') 


(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.

(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
- Large
- Normal
- Small
- Very Small
....always the same sized, then addons would instantly be at least usable on other skins...

(2013-02-11, 17:43)pieh Wrote:

(2013-02-05, 18:23)sphere Wrote: 2.1 always included skin graphics

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-11, 17:43)pieh Wrote:

(2013-02-05, 18:23)sphere Wrote: 2.2 View-IDs

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-11, 17:43)pieh Wrote:

(2013-02-05, 18:23)sphere Wrote: 2.3 Big Text Dialog/Window

I think we should try to make standard Ok-Dialog auto-sizable instead to avoid adding yet another dialog that need maintaining

(2013-02-11, 18:42)sphere Wrote:

(2013-02-11, 17:43)pieh Wrote:

(2013-02-05, 18:23)sphere Wrote: 2.1 always included skin graphics

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)

Regarding images:
I also don't thing that forcing is needed, but the skin authors need to be informed about such a convention. I bet every skin author is interested in having plugin's look more unified to his skin.

(2013-02-11, 18:42)sphere Wrote:

(2013-02-11, 17:43)pieh Wrote:

(2013-02-05, 18:23)sphere Wrote: 2.2 View-IDs

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.

Sounds good Then only a method (and any kind of priorizing cause some skins provide multiple views for one view-type) is needed to get these IDs readable by add-ons.

(2013-02-11, 18:42)sphere Wrote:

(2013-02-11, 17:43)pieh Wrote:

(2013-02-05, 18:23)sphere Wrote: 2.3 Big Text Dialog/Window

I think we should try to make standard Ok-Dialog auto-sizable instead to avoid adding yet another dialog that need maintaining

auto-sizing sounds good but the ok-dialog needs three lines in the api. So we have to choices: 1. change the ok-dialog in gui and code (to accept one multiline-text argument) or 2. keep the ok-dialog in code and gui but add another dynamic sized (with auto close please) dialog.

(2013-02-11, 18:42)sphere Wrote: May I pin your name next to some topics? *g*

(2013-03-17, 15:16)Nuka1195 Wrote: I have a patch for 5.4 background progress dialog.