Support of script.skinvariables - Viewtype Builder in Kodi Skin

Is it possible to add support for script.skinvariables - Viewtype Builder:
https://github.com/jurialmunkey/script.skinvariables

https://github.com/jurialmunkey/script.skinvariables/wiki/Skin-Viewtype-Builder

It’s for possibility to set default Viewtype for plugins and views.
Currently (it’s kodi default behavour) it’s possible to change the viewtype but only for the first page. It’s not possible to save it in order to keep the viewtype on all pages. If I go to the second page, the viewtype is set to List.

I see there is setting: “Set default view for video addons”. I do not know what it does. It looks like it wants to do what I want to achieve but it does not. The default view type is not respected in plugins I use. It works with script.skinvariables - Viewtype Builder.

I’d have to dive into what has to be done to support something like this… I’ve read about it before, but couldn’t see what it might help us to do what we’ve not already been able to do, considering what we wanted to do with our skin.

We do indeed have a view type setting for video addons and it does work with addons that honor the Kodi addon guidelines: video addons have to set the content type to ‘videos’ when you have a list of videos in front of you. The issue now is: Would this only enable you to do what our setting already does for video addons that don’t honor these Kodi guidelines? If yes, then I’m not too inclined to do this - I’m already working around a lot of functionality restrictions and things e.g. the Kodi skin engine doesn’t offer per se or in a simple manner. Starting to work around addons not sticking to how content types are meant to be set is not really on my to-do list :see_no_evil:

Content type of addons I use is set e.g. to movies, tvshows, seasons, episodes (depends on category what I’m browsing). They are addons what offers movies and tv series so it looks it’s set correctly. I do not know if type: videos is some kind of parent for those types. But basically all custom views are very difficult to use without possibility to lock the default view. It’s not very user friendly to set the custom view for hundrets of pages.
I do not know if my issue is a matter of this skin or matter of my plugins but it works with skins like Amber, Aeon Nox Silvo, Arctic Zephyr, Arctic Horizon, etc. Based on their code I saw most of them use skin.variables.

Anyway I just wanted to ask if this is in future plan. If not then I have my answer :slight_smile: . I considered it as a usefull feature for other users as well.

I’ll have a look at the skin variables script and see whether this might be useful to us :+1:t3:

The view types you’re mentioning are indeed not allowed to be used by addons per Kodi addon guidelines. They’re reserved for actual library content. I’m aware, quite some addons out there don’t stick to the guidelines and this make things complicated for skinners: Do we try and make things look good on screen for these addons by ignoring reserved content types or do we stick to Kodi guidelines to make things more streamlined?

I understand. I didn’t know the Kodi addon guidelines.

I’d lean towards the latter.

So I’ve gone through some of what is being discussed here with the development of the Mezzmo Kodi addon for the very Kodi limitations mentioned, the inability to set a view type by content type. It has a view settings tab in the addon options.

In the Mezzmo case I have control over the content types, with video as the default, but don’t have control over the skins, since it supports all skins. This is partially what threw me off a little on the December UPnP troubleshooting issue.

Dealing with various skins is a bigger problem for me so I decided to support a certain number with a default. The view type numbers vary across skins. Here’s my mapping code.

Overall this works great for an addon and its content, especially dealing with lists of media. I set the view type mapping once and I am good for all matching content, even if Kodi tries to change it due to an individual saved setting. But I can see the challenge of supporting addons which leverage their own content types. It’s akin to me trying to manage all the different skins.

My 2 cents and experience in this space.

Jeff

The issue really is that skins have to decide what to obey and thus what to do: Obey the Kodi content type guidelines or deal with addons that either demand skins to not care about content types too much or to specifically support addons that circumvent these guidelines.

Both the latter approaches are somewhat problematic, if you’d like to achieve best compatability while having a skin that’s lightweight and independent. The content types are there for a good reason from the skinning side of things: E.g. it’s been mentioned in the UPnP thread that addons seem to be setting the “photos” content type while the MyVideoNav window is open. This makes absolutely no sense and either leads to issues when it comes to item visibility (as demonstrated in the thread) or it takes away any control from skinners as to how content types are best presented in certain windows. I understand that this is not always optimal for users who are using addons that basically ask skins to ignore content types altogether.
If we take the other approach and support addons helping to circumvent things, it’ll be a lot of maintance work required (addon changes have to be incorporated) and/or the skin becomes heavily dependent on said addon (either it only works, if the addon is installed as a dependency, or you have to maintain a default fallback that works without the addon present).

What does this mean: I’ll have a look at how we can add (back) a basic way of showing strange content type lists in windows where they don’t belong as to Kodi guidelines, but we will not be supporting any addons that are, amongst other rings, there to circumvent Kodi’s skin engine’s ‘shortcomings’ when it comes to content types (including the skin variables script). I hope that the thoughts outlined before make it clear why :blush:

1 Like

Yeah, I’d be happy if skins would agree on something as simple as common view type numbering standards. Even that would be a start. I’ve stopped adding new skins or trying to keep up with current skin changes I do support. I will add one if there is enough demand. I even added a view type remapping where some skins / content types may not have a view type that the user desires for a certain skin. So now they can remap a folder as a movie to get the additional views of a movie for a folder. It gets complicated real quick.

More skin standards would help and I concur with your thinking, let the addons handle their own view type handling.

To your UPnP pictures issues, I am traveling right now and can’t help much but I did look at my code and I map pictures to content type files.

Jeff

That would be Kodi’s job, honestly. But I don’t see a way how that’s going to work, if not by limiting the flexibility the skin engine provides to skinners.

What I can add here is that the content type ‘photos’ doesn’t exist in Kodi at all (only ‘images’ does). So, we have an even more serious situation here: Making up new content types that skins are not aware they should handle at all.
The only quite comprehensive content type list, although already a bit outdated, that also lists where the content types should be used, that I could find, is actually this: Heads-up: How to deal with content types / media types

Sry to say, but this must be a misunderstanding. I don’t think addons should do that - we see the results here. The addon rules Kodi has stipulated are very clear on this:

Plugins should not force certain skin viewtypes on their own. They should set the correct media content from which the correct skin view type is automatically provided. (https://kodi.wiki/view/Add-on_rules#Requirements_for_all_python_addons)

Within the system we’re currently working, this should be followed to the point, otherwise things get complicated real quick as you say. But the solution really isn’t to simply override things and then users wonder why things don’t always work as “expected”. I put expected in quotes as it’s frankly a wrong expectation… What I could agree on: Better documentation of content types is necessary for everyone involved - so skins can support all content types there are as well as so addons know which content types they can and should only use.

This is valid IMHO until we see an entire overhaul of the Kodi skinning system.

Yeah, I realize I am a bit out of step on this one but again given the state of skins it became necessity. I give users the option for the default or set the view type. So they can choose. so since I am not “forcing” then maybe I am not so out of step :slight_smile:

The Kodi guidance seems a conflicting in that they provide a mechanism for addons to set the view type yet their guidance is not to do so.

Thanks,

Jeff

I concur with the impression that the whole system is not fully aligned properly… As we see in the UPnP thread, Kodi’s own UPnP client is setting content types that shouldn’t exist at least per all documentation I can find. So, quite some things seem to be conflicting :see_no_evil: Really frustrating!

I understand that addons do not follow kodi guidelines, basically most of addons I use, do not follow that guidelines. Most of them use the same viewtypes (movies, tvshows, seasons, episodes). I do not think it’s a good idea to set all of those catergories as just ‘videos’ and have the same viewtype.

So for my use case where I don’t use Kodi library at all and just use addons providing streaming content with view types as I wrote, all view types other than list are not usable. It’s not possible to set all pages for all categories and every single tv show seasons/episodes list.

Anyway I feel this is more or less a lack of Kodi itself. I don’t understand why I cannot just set/force specific viewtype for specific content (of course a widely known viewtype) if I do not use library.

I agree, it is. Skins and addons are trying to work around this in different ways, but there’s no proper way to do it yet which leads to many, sometimes even conflicting approaches that result in dependencies and very much differering user experiences… Not optimal for anyone.

But from a skinner’s side, there’s obviously always a decision to make - we can’t support everything that would be nice to have.