(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 graphicsI 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)
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-IDsWe 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.
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.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 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/WindowI think we should try to make standard Ok-Dialog auto-sizable instead to avoid adding yet another dialog that need maintaining
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)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.
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: [ -> ]Regarding images:(2013-02-05, 18:23)sphere Wrote: [ -> ]2.1 always included skin graphicsI 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: [ -> ]Sounds good(2013-02-05, 18:23)sphere Wrote: [ -> ]2.2 View-IDsWe 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.
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, 17:43)pieh Wrote: [ -> ]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-05, 18:23)sphere Wrote: [ -> ]2.3 Big Text Dialog/WindowI 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: [ -> ]Ok, this can be taken to Skin Development forum and presented to skinners to comment on. I'm not sure if we already can say "try in skin's graphics and fallback to graphics provided by plugin" - this might be possible with thumb / icon stuff (I'm always a little confused about that(2013-02-11, 17:43)pieh Wrote: [ -> ]Regarding images:(2013-02-05, 18:23)sphere Wrote: [ -> ]2.1 always included skin graphicsI 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)
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.
). If not possible, I will see what's needed to do it.(2013-02-11, 18:42)sphere Wrote: [ -> ]I'll look into it. I'm thinking xbmcplugin.xbmcplugin.endOfDirectory(success=True, view_priority=['bigicon', 'icon', 'info']) (not all skins might include most desired viewtype, so we could define fallbacks and if none of defined views are there we just fallback to default list view). There might be one glitch: if we change from default view to something else we save it in ViewModesX.db database - so plugins that used workaround to pick thumbnail view will have already defined view id for given path - this means that this would have no effect (as we will want to use view that user defined and not one that is defined by plugin). We could clean saved views for plugins but I don't like this as it would remove view preferences of users(2013-02-11, 17:43)pieh Wrote: [ -> ]Sounds good(2013-02-05, 18:23)sphere Wrote: [ -> ]2.2 View-IDsWe 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, 18:42)sphere Wrote: [ -> ]I'm thinking that we could replace 3 labels with textbox control (skinning wise), leave current api methods to not break addons (we would just concatenate those 3 lines and put it in textbox) and add new api method that would take single text block. Autoclose could be added as optional named param to existing ok-dialog.(2013-02-11, 17:43)pieh Wrote: [ -> ]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-05, 18:23)sphere Wrote: [ -> ]2.3 Big Text Dialog/WindowI 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: [ -> ]May I pin your name next to some topics? *g*Sure, but I'd prefer seperate trac tickets
