Login at Kodi Home

**Martijn** · (This post was last modified: 2012-07-18, 11:15 by Martijn.)

(2012-07-18, 11:06)jmarshall Wrote: And yes, in some senses, I like the idea of moving away from the general "thumb". The disadvantage is you can't re-use the same view for different things as easy.

Cheers,
Jonathan

It would be as easy as making another image control in the same XML with a visibility condition on the container() for such items.

**Hitcher** · 2012-07-18, 12:40

(2012-07-16, 11:54)`Black Wrote: Yes, select dialog would be best. But we should somehow be able to add extra options for logo, clearart etc.

This could be determined in the skin's addon.xml couldn't it?

**pecinko** · (This post was last modified: 2012-07-18, 20:34 by pecinko.)

(2012-07-18, 01:32)jmarshall Wrote: ** Would the thumb would be exported using the existing folder.jpg/movie_name.tbn, or perhaps thumb.jpg/movie_name-thumb.jpg? Changing folder.jpg might have implications for folder thumbs, though I guess there's nothing stopping us reading thumb.jpg before folder.jpg...

Well, if ListItem.Thumb(icon) is to be kept and always mapped to default art type for given content type than exporting to thumb.jpg makes sense. If folder.jpg is used than it will be usefull when browsing in windows explorer as well.

OTOH, if you opt to drop ListItem.Thumb and "force" ListItem.Art(foo) than, maybe, exporting to movie_name-foo.jpg makes probably more sense.

jmarshall · 2012-07-19, 00:14

IMO dropping ListItem.Thumb (or rather ListItem.Art(thumb)) doesn't really make all that much sense - there's a bunch of cases where there'll really only be one thumb type anyway (eg posters, album covers, artist thumbs) so having genericity keeps things simple for the skin where it makes sense to keep things simple. Special-casing the current "thumb" stuff is already done anyway, so exports can keep using folder.jpg for unknown image types.

So I think we have a reasonable plan. I'll make some changes so that basically any image type can be supported + add in the support for pulling + exporting local thumbs so you can all test out the functionality a bit further.

Cheers,
Jonathan

phil65 · 2012-07-19, 00:31

(2012-07-19, 00:14)jmarshall Wrote: IMO dropping ListItem.Thumb (or rather ListItem.Art(thumb)) doesn't really make all that much sense - there's a bunch of cases where there'll really only be one thumb type anyway (eg posters, album covers, artist thumbs) so having genericity keeps things simple for the skin where it makes sense to keep things simple. Special-casing the current "thumb" stuff is already done anyway, so exports can keep using folder.jpg for unknown image types.

So I think we have a reasonable plan. I'll make some changes so that basically any image type can be supported + add in the support for pulling + exporting local thumbs so you can all test out the functionality a bit further.

Cheers,
Jonathan

although it doesn´t seem that straightforward to me to handle some images with a "generic" .thumb/Art(Thumb) property and some others with an "explicit" property i can imagine that it makes it easier for us skinners to re-use code (album view for addonbrowser for example) without adding extra lines, so i think that´s a good way.
really excited how this turns out, will be the best improvement for skinners since the introduction of variables Cool

phil65 · 2012-07-19, 00:45

another thing, slightly offtopic, don´t know if it is related to this or probably to parsing:
i cannot use $INFO[Skin.String(ArtistsLogosPath)]$INFO[ListItem.Artist,,/logo.png] inside a container.
when displaying that whole string in a label control (also placed in the container) it just displays the $INFO[] part, rest gets lost.
outside of containers it works.

jmarshall · 2012-07-19, 01:25

Containers can use only ListItem.* in info (i.e. the info must come from the item).

phil65 · (This post was last modified: 2012-07-19, 01:36 by phil65.)

(2012-07-19, 01:25)jmarshall Wrote: Containers can use only ListItem.* in info (i.e. the info must come from the item).

same applies when using <texture> / <label> instead of <info>?
would be really nice to change that since logos are a good replacement for the normal labels IMO.
would allow us to use the logos in the same way as tvshow logos for example (there we can put the "logo.png" into the $INFO[ListItem.Path] tag, that way works)

jmarshall · 2012-07-19, 01:46

You won't have to do these silly hacks when these changes are in. But yes, it also applies to texture, info and label.

phil65 · (This post was last modified: 2012-07-19, 02:04 by phil65.)

(2012-07-19, 01:46)jmarshall Wrote: You won't have to do these silly hacks when these changes are in. But yes, it also applies to texture, info and label.

ok, thx. will be much better then indeed. just askin because music area always seemed a bit different in terms how to deal with additional artwork.

sorry to annoy again, another question Smile

will this also cover dealing with extrafanart?

nessus · 2012-09-29, 12:45

bump

Any news/plans/progress for this ?... or at least do we know if it will included in Frodo.

Cheers
Nessus

MassIV · 2012-09-30, 00:50

Hands... Itching... Need...

...to start on viewtypes.

jmarshall · 2012-09-30, 02:23

It all depends on time. I'm certainly hopeful that it'll be in Frodo, but it'll mean a couple of things might be dropped:

1. I'm not sure how complete I'll be able to get the "thumb" thing handled.
2. extrafanart/thumbs is probably going to be a no-go this time around (reason is there's no obvious and complete way to handle folders in the current art stuff

Cheers,
Jonathan

MassIV · 2012-09-30, 10:58

Personally, being able to differentiate between posters and banners is the most vital of these vital changes.

nessus · 2012-09-30, 22:16

(2012-09-30, 10:58)MassIV Wrote: Personally, being able to differentiate between posters and banners is the most vital of these vital changes.

+100