Gamester17 Wrote:Nitpicking; "colour" should be "color", no? The rest of XBMC strings uses American English

jmarshall Wrote:Off topic, but the strings should use British English. There's an English (American) directory for a reason.

Quote:<audioformat>.mediainfo.audio.mono
<audioformat>.mediainfo.audio.color
<videoformat>.mediainfo.video.mono
<videoformat>.mediainfo.video.color
<resolution>.mediainfo.resolution.mono
<resolution>.mediainfo.resolution.color
<studio>.mediainfo.studio.mono
<studio>.mediainfo.studio.color
<source>.mediainfo.source.mono
<source>.mediainfo.source.color
<played>.mediainfo.HasBeenPlayed.mono
<played>.mediainfo.HasBeenPlayed.color
<lang>.mediainfo.subtitle.mono
<lang>.mediainfo.subtitle.color

Ex: Listitem.Image(thumb01,landscape) - would display the first banner.
ListItem.Image(thumb03,portrait) -would display the third poster.
ListItem.Image(thumb) - whatever people decide on. I'm just trying to get a rough idea going.

AnalogKid Wrote:You made my head hurt and I read this three times!
The <n> option, I had envisaged more for constantly changing image... fanart and moviegrabs is an obvious one. For the large part, most users wouldn't have <n>, but if they did... a skin 'could' cycle through them all, if it had the right control and way to signal that the control should cycle.

Quote:As for deprecating the use of 'thumb'. I'd guess for the moment... thumb would equate to cover.front. That would be a direct one to one mapping. So any request for a thumb would retrieve the cover.front

Quote:For the mediainfo artwork... slightly confused about that. I know that XBMC now has them natively supported, so no need to bastardise the Studio tag in NFO... but it still has to render the icons right? the scheme was just meant to have a uniform way of picking up those icons (via name). However... I've thought of a stange dilemma: It could be argued that the skin look after it's own mediaflag icons, so no need to have a naming convention. That said, there are so many new codecs and studios appearing, isn't it better to have the icons apart from the skin?... so that the user only needs one icon set for all skins? I can see an argument for both cases here. Tricky!

Quote:Also for <n> images... I'd figured the following

Starwars.fanart.landscape <--- the default fanart
Starward.fanart.landscape.<n> <--- an additional fanart for skins that want the 'cycle' through fanart

So, a skin that just wanted a still fanart, would omit any index number

I can't see a reason for a skin to request a specific index number (except perhaps when displaying more than one at the same time) in which case it still be movieframe<n> and movieframe <n+1>. I'm not sure how image cycling works in a skin... does the skin request a new image based on a timer, or as I suspect, it gives XBMC a root folder and gets XBMC to cycle through images in that folder. If the latter?

digitalhigh Wrote:Right, and we have a <multimage> control, which is typically pointed at a directory, and then displays that directory's contents in a slideshow-type format. I failed to include the idea that using just putting "
"ListItem.Image(type,orientation)", would then make a Multimage display all available images.



The usage of "thumb" was actually just to differentiate from "front.cover", which (in my mind) would be a scan of the actual DVD cover, whilst the majority of movie collections use posters for the main display. I thought about calling it "poster", but then that screws up people who would want to use a banner.

Else...just call them poster, banner, and frontcover respectively.



I agree that it would be quite convenient to have ONE set for everything...I can bet you that some skinner is going to want stylized icons, at which point, there becomes a problem. It's really up to whoever decides to be kind enough to put this into code as to how much work they want to put into that aspect.



Again, as I mentioned earlier...static and "slideshow" images are defined differently via the <image> or <multimage> controls. So, using multimage, just putting Listitem.Image(type,orientation) would make all show, while using the same tag in a static image (without <n>) would show the first image.

If, however, say you wanted to show two or three different posters, it would be beneficial to be able to have ListItem.Image(foo1), Listitem.Image(foo2), and ListItem.Image(foo3) all available at the same time. I don't know why you'd want to do it, but somebody may.

AnalogKid Wrote:That said, there are so many new codecs and studios appearing, isn't it better to have the icons apart from the skin?... so that the user only needs one icon set for all skins? I can see an argument for both cases here. Tricky!

bidossessi Wrote:very true, and there's a thread in the forum where folks are build what could be called the most complete studio tag collection under the sun (i think positive and negatives are covered as well for dark/light skins).
if a consensus can be reached as to naming schema for studio tags, then this ongoing work could be the starting point.

AnalogKid Wrote:You've just raised an interesting point regarding 'Posters'. I thought folks only used posters as a substitute for Front Covers... and had to make do with the additional 'coming soon' etc text. That said, they ARE technically different... so I'm going to add Poster art to.

AnalogKid Wrote:Cool, and if like DigitalHigh has suggest, a skinner really insists / wants a themed icon set for their skin.... they can supply one for the end user to use (leaving the choice up to the end user).

The critical thing here is that the naming convention is highly consistent and well considered *hint* *hint*, that way, it doesn't need revisiting every 2 weeks. Although say in 2 years, it may need a revamp and new ideas come to fruition, and no scheme is entirely future proof.

It would be very helpful if the guys coming up with the naming convention took a look at this thread and offered their ideas... I'm happy to mention this work in their threat too... see if we can agree on something

digitalhigh Wrote:Or even better, <texture>listitem.image(studio,mono)</texture> if this were somehow incorporated into an image database...

AnalogKid Wrote:This is the right way to go.... this way the skin doesn't "interpret" the mediainfo... it's completely agnostic. Then is new studios appear, the skin will still work with no knowledge of the studio name.

This (in my opinion) is how it should work for the codecs too.

Infact, the skins shouldn't even be referring to the filename directly, just as you say "poster,<n>,portrait", and XBMC will map that to the correct filename.