[Jeroen]

You don't want to use Container.Content conditions for Includes because they're only checked when the window is loaded (ie VideoLibrary). So if you used Container.Content(episodes) it wouldn't get loaded because when you first load VideoLibrary it will be at the TV Show level.

If you had a view that covered Music, Video, Pictures, etc you could use them based on the main window being visible.

ie

PHP Code:

<include condition="IsVisible(VideoLibrary)">Video_Layout</include>
<include condition="IsVisible(MusicLibrary)">Music_Layout</include>
<include condition="IsVisible(Pictures)">Pictures_Layout</include>
<include condition="!IsVisible(VideoLibrary) + !IsVisible(MusicLibrary) + !IsVisible(Pictures)">Default_Layout</include> 


I have been trying it out and I really like this, and through grouping by content type within the itemlayout as well this would allow me to reduce the amount of code a lot, but there's one big downside to this for me.

I want the itemlayout to have a different height when I'm either at the videolibrary root or the content node's root (so where you pick genre, year, etc). I've been pulling my hair out, but I doubt if there's a way to do that?

[Hitcher]

This returns empty when in the root -

PHP Code:

<visible>IsEmpty(Container.FolderPath)</visible> 


[jmarshall]

I can easily add Content(Root) or some more appropriate flag - note that there is more than just "root" here - eg with flatten off you also just get a bunch of nodes listed, which I suspect you'll want to use the same view type for.

I cannot (currently) add things for differing thumb sizes, and indeed, assuming that a particular content type corresponds with a particular thumb size is incorrect (though I suspect it's close enough that you need not worry about it).

Instead, you should use aspect keep with the thumb centered within the box where appropriate. That way, it will work well for those thumbs that are the size you are assuming, but will also ensure that those thumbs that aren't the size you are assuming don't get stretched incorrectly.

Cheers,
Jonathan

[Hitcher]

stringcompares in vis conditions (not include conditions) are slow as shit. Do not use them if you can possibly avoid it.

substrings is even worse its basically multiple string compare

More interesting info for me to digest.

Does adding 'Left' or 'Right' make any difference to a SubString control?

[Jeroen]

This returns empty when in the root -

I know, I was aiming more for a check in the including stage, but I realize it's not possible as it's only executed when the window loads.
I got around it by using the including method you posted, and then having two separate layouts with a visibility condition to check if I'm at the root. So, I'm still using a visibility condition, but at least I'm using it less.
I found some more ways to avoid them and the amount of code for my list view for example is less than 50% of what it was before

I can easily add Content(Root) or some more appropriate flag - note that there is more than just "root" here - eg with flatten off you also just get a bunch of nodes listed, which I suspect you'll want to use the same view type for.

Yeah I was thinking about that later too. Right now I'm using ![Container.Content(movies) | Container.Content(tvshows),etc] to separate those from the higher level nodes. So I guess I would still need to do that if Content(Root) was available.
If Content(Root) would apply to the files node too, it would be a good substitute for using stringcompare(Container.folderpath,sources://video/) though.
Let me think about it as I work on this, I wouldn't want you to spend time on it if there's not enough need for it.

edit:

One that I could definitely use would be a substitute for
stringcompare(Container.FolderPath,special://videoplaylists/)