digitalhigh Wrote:http://xbmc-media-art-proposal.wikidot.com/skin-considerations

Aight...my end is there. If anybody else familiar with the skinning engine could review this and offer a critique, it would be much appreciated.

xexe Wrote:I had a quick pass at the spec.

HasBeenPlayed
'Watched', but a more generic term to cover Audio and even Images

is problematic since XBMC is multi-user and this item does not cater for that. I cannot suggest a solution for this yet as there is no easy way to know which user the tag is for if you cater for art in several lcoations.

Also can i throw something in for consideration.

Instead of fanart, cover etc etc why not just list the resolution. From the resolution you know what the art is and you have the added advantage of having that info available via the filename rather than reading file contents.

Gangsta Wrote:could the skinning engine not just accept

ListItem.Image(".fanart<n>.portrait")

to maintain the design breif of being extensible. if you use the ListItem.Image(thumb,n,orientation) style of it, won't that require coding to support any new artwork types?

xexe Wrote:Ahh that makes alot more sense. you should update the wiki to refelct that as it isnt obvious what hasbeen played means

Using TVDB artwork as a reference each different type has a different resolution. Maybe that cant be relied on though I am in two minds but right now unless I am missing something it would work.

I am still concerned about the multiuser thing though as over time XBMC will evolve to be more multiuser centric not less and right now we are designing the next generation of naming that is not compatible with that philosophy.

MaxNL Wrote:@digitalhigh:
It is not clear to me that part of your skin suggestions:

ListItem.Image(thumb,n,orientation)

I know that there's currently a listitem.thumb property, and that every skin in existence probably uses it. But I just figured that if we're aiming for consistency, maybe this should be transitioned to, and start depreciating infolabels like Listitem.Thumb/Listitem.Icon/Listitem.Property(Fanart_Image).

This would be the "cover" or "poster" or "banner", depending on the media being used. As with fanart, n could be used to have multiple images available, and the orientation would determine whether a banner or poster is displayed.

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

I mean, how is it going to decide between banner poster or thumb?

Regards
Max

Gangsta Wrote:could the skinning engine not just accept

ListItem.Image(".fanart<n>.portrait")

to maintain the design breif of being extensible. if you use the ListItem.Image(thumb,n,orientation) style of it, won't that require coding to support any new artwork types?

AnalogKid Wrote:Multiuser will never be an issue...
It's no different than the media files and artwork today.

AnalogKid Wrote:Multiuser will never be an issue...
...If you have a movie.avi and a movie.jpg, all users get the same art. They can override that art by choosing a new image, and in the same way, a user can override the art in our schema.

AnalogKid Wrote:Multiuser will never be an issue...
...
However, IF the user actually stores their art in one big flat folder, it can even improve user profiles (in theory), with every user having their own artwork folder (if they wanted to). But this is totally down to XBMC to manage.

xexe Wrote:All that really says is "the current way is lacking". This we know.



So user 1 can use the new scheme and user 2 has to rely on XBMC manual choices via the GUI. Not especially flexible when you get to a family of 4 or a dorm of 10.



Agreed but this fundamentally breaks one key design goal of "3) Is placeable ANYWHERE in the filesystem" and as such is not appropriate.

Trying to dealw ith this might be too much for this project but if a solution can be derived that is logical and easy to implement you have one more reason why the devs might implement it.

AnalogKid Wrote:I agree with all of the above.

But, no OS in the world manages this today. Let alone a media center.

There's only a couple of ways to go with profiles:
a) Either ALL user data (the entire DB and artwork) has to be duplicated for every profile

b) Some aspects of the data are shared.

Consider windows for example. "Folder.jpg" in a given folder will be picked up by ALL profiles. You can't have a different folder.jpg per profile in a given folder. So it's a shared artwork. This is how XBMC is working too, but with the added ability to override that art with your own.

I did have a think about this and thought of the following

<user>.<moviename>.fanart.........

Where user is a profile name, OR "default" which means all profiles use it unless overridden, eg

david.starwars.fanart
susan.starwars.fanart
default.starwars.fanartid

or could be done like this

david\
--- starwars.fanart
susan\
--- starwars.fanart
default\
--- starwars.fanart

So user David has his own art
user Susan has her own art
user Andrew doesn't have any art so gets 'default'

This would work and could even incorporate user groups, but this is way off scope for this thread I feel. And probably overkill for all XBMC. At the moment, it's hard enough to get small improvements made (in some areas).
I did say originally that this schema neither improves upon profiles or makes it any worse. But with my comment on how the user COULD store their art in one flat folder (or in profile subdirs), then this would be a solution... (but imposes a rule on the user to store their art in a specific way.

For the future I think... when profiles get THIS powerful, you have to impose restrictions, every OS does!. You just cant write profile specific data into shared folders without issues.

digitalhigh Wrote:I think we should just focus on getting a working schema and someone to implement it. Once we have a model, then start taking considerations for profiles and such.

But, yes, I think the easiest way would be to just have a folder for individual users where all their specific artwork is kept. Or maybe have a root folder, and then a user-specific folder where any extraneous artwork found would override what's in the root.

Still, I think we should work on walking first, then go for the run after we get that down.

o_dog Wrote:not to piss anyone off or anything but what exactly is the problem with the way it's designed today? It works just fine here, multiuser with diffrent art? How many people would actually use that one?