Mixed aspect ratio artwork selection for square widgets

[MoojMidge]

I use a widget that shows all my in-progress and next up movies and episodes, and have elected to use the square layout for this widget, as I thought this would be the best compromise between the poster artwork used for the movies, and the thumbnails used for the episodes, in combination with the fanart as the widget background.

While I can set the artwork used for the widget listitem to be whatever I want it to be (e.g. using tvshow or season fanart as the episode listitem fanart), there appears to be a problem when setting the thumbnail artwork using the ListItem.setArt method - the set thumbnail artwork is never used in the square widget layout.

This is because the artwork used for the square layout uses ListItem.Icon as the default artwork. I believe the icon property is set when the ListItem is being constructed, as part of the creation of the underlying CFileItem object. The subsequent use of setArt changes the artwork for the ListItem, but does not change the icon property.

This is especially problematic when showing a movie in the square layout, because the icon property falls back to the thumbnail artwork for the CFileItem. Because Kodi does not scrape thumbnails for movies by default, the thumbnail will most likely be blank or an auto-extracted thumbnail. When the thumbnail for the listitem is changed using setArt, the icon property is not updated, meaning that the original thumbnail fallback will always be used for the listitem in the square layout.

This PR allows movies to show poster artwork whilst maintaining the original AR in a square widget, while showing landscape artwork for everything else (which is effectively the same thing as the previously used icon property artwork, for all the other content types that I can think of).

Before:

After:

[jurialmunkey]

Square is primarily intended for Music and PVR. There is a reason square is not available inside the Movies or Episodes media windows as a viewtype. It is not intended to display poster or landscape artwork types.

Why not just use landscape for your mixed widgets?

[MoojMidge]

I get that the square layout may not be primarily intended for movies or episodes, but the same problem with the ListItem.Icon fallback will also occur for the music widgets, where the thumbnail set using ListItem.setArt({'thumb': 'blah'}) will not be used if the underlying library entry already has associated thumbnail artwork.

This behaviour changed somewhat in Matrix due to the removal of the iconimage and thumbnailimage parameters in the ListItem constructor and the changes to the setArt method, but it required fixes in Estuary and Chorus to suit the changes.

Why not just use landscape for your mixed widgets?

It just looked weirder to me.

Landscape/fanart/clearart for movies can be difficult to initially identify a movie in a listing or widget, and overriding the fanart for movies using ListItem.setArt({'fanart': 'poster.jpg'}) doesn't work too well because the fanart is already displayed in the background of the listing/widget.

For episodes the landscape layout works well because the episode fanart is different to the tvshow fanart, but for movies it is just a double up with too much blank space. Square was the most visually appealing compromise.

[jurialmunkey]

Listitem.thumb was depreciated not icon.

But that's beside the point. The square widget style is intended for square artwork types - eg album artwork and artist thumbs. It is not intended to hold poster or landscape aspect artwork.

Some leniency is given to PVR icons as there is a lot of variability - but that's more a necessary evil due to Kodi's PVR not enforcing proper reliable artwork types rather than a specific design choice.

[MoojMidge]

What I was trying to say was that this no longer works:
xbmcgui.ListItem(iconImage='icon.jpg', thumbnailImage='thumbnail.jpg')

Instead you need to do this
listitem.setArt({'icon': 'icon.jpg', 'thumb': 'thumbnail.jpg'})

However when a ListItem is created, a CFileItem object is created first, which the new ListItem points to. The CFileItem has an icon property which can be accessed via the ListItem.Icon infotag.

The icon property looks for any existing icon artwork, and falls back to any existing thumbnail. Prior to Kodi 19, it used to fall back to fanart and poster artwork as well, and this behaviour has been retained in Estuary and Chorus by using skin variables to perform the fallbacks instead.

When setArt() is used, the new artwork can be accessed using ListItem.Art(icon) or ListItem.Art(thumb), however ListItem.Icon does not get updated. I am not sure if this is a bug in Kodi or not, but given the deprecations and workarounds in Estuary, I guess it is expected behaviour.

The problem with AH2 is that it only uses ListItem.Icon for square layouts, without using the same type of fallbacks used in Estuary.

This means that any thumbnail or icon set using setArt() will not get used, only the initial icon property that was set, prior to setArt() being called, as part of the initial creation of the ListItem.

It also means that AH2 has different, and more limited, artwork selections compared to Estuary, which does allow poster and fanart in square layouts as per the Kodi behaviour prior to Kodi 19.

Regarding the intent of square layouts, I can understand your perspective, but I would argue that having the option to show poster and fanart in square layouts, as per this PR, aligns with long standing Kodi behaviour, doesn't look too bad, and doesn't interfere with other uses of the square layout.

In my opinion it looks better than the current display of movies and episodes in square layouts (which admittedly not many people would use), while also fixing a bug with the use of ListItem.Icon.

But if this doesn't fit with your design choices for the skin, that is fine.

[jurialmunkey]

When setArt() is used, the new artwork can be accessed using ListItem.Art(icon) or ListItem.Art(thumb), however ListItem.Icon does not get updated.

I cannot replicate this behaviour. In TMDbHelper, whatever I set to setArt({'icon': 'myicon'}) is available in ListItem.Icon regardless of whether the item already exists or has a dbid or thumb etc.

This sounds like a problem with the addon not the skin.

It also means that AH2 has different, and more limited, artwork selections compared to Estuary, which does allow poster and fanart in square layouts as per the Kodi behaviour prior to Kodi 19.

My issue isn't with the type of artwork being used. The problem is using keep aspectratio in the square view.

AH2 is not Estuary. The two skins have very different design specs. Estuary's use of space is very loose and haphazard to allow for keep aspectratio items. Estuary lacks consistent spacing between elements, which, imho, looks ugly.

The design spec in AH2 specifies scale aspectratio is used to provide consistent spacing. The is an allowance granted to PVR items but that is only done as a necessary evil due to the complete lack of artwork rules for PVR icons.

I'm happy to allow square to fallback to a different artwork if icon isn't available but that's not what this PR is doing. This PR is adding a bespoke design spec for a single viewtype. I dislike bespoke designs for single viewtypes. The lack of consistency between Estuary's viewtypes is one of the things I most dislike about that skin.

[MoojMidge]

I cannot replicate this behaviour. In TMDbHelper, whatever I set to setArt({'icon': 'myicon'}) is available in ListItem.Icon regardless of whether the item already exists or has a dbid or thumb etc.

Yeah you are mostly right. The icon getter calls GetArt. It was the previous, now removed, implementation where the getters did different things.

The problem I am seeing only appears to occur when there is local artwork or autogenerated thumbnails that are saved to the library. For library items that don't have a local thumbnail or an autogenerated thumbnail, everything works as expected, but if I add a thumbnail.jpg and refresh the library entry or enable thumbnail extraction then that thumbnail is always displayed by ListItem.Icon.

VideoThumbLoader must be doing something - I can see references to caching local artwork, maybe that is what is overriding the artwork map.

I'm happy to allow square to fallback to a different artwork if icon isn't available but that's not what this PR is doing. This PR is adding a bespoke design spec for a single viewtype. I dislike bespoke designs for single viewtypes. The lack of consistency between Estuary's viewtypes is one of the things I most dislike about that skin.

Well, to be fair this PR does both, but I get your point. The only reason I mention Estuary/Estouchy and Chorus is because I access my library from a few different devices and the difference in the artwork was noticeable. Would you have a better suggestion for how mixed widgets could be displayed?

Using a fanart widget with flixart works well for episodes, where episode artwork is shown in the foreground and the tvshow artwork is shown in the background, but for movies you just end up with the same landscape artwork in the foreground and background.

On the other hand poster widgets with flixart shows the movies poster in the foreground and movie fanart in the background, but for episodes it shows the tvshow poster in the foreground and the tvshow fanart in the background, without any episode specific artwork.

One option I can think of is to have the keep AR poster displayed over the scale AR poster, in the square view, to fill up the padding around the poster artwork. This way the square view for mixed content would be more visually consistent, with consistent spacing between the artwork elements, but it does mean that the bespoke viewtype becomes even more customised.

[MoojMidge]

Changing to draft until I can figure out a better way to make this work.