[topfs2]

What exactly is holding back a true solution for this anyway? All this is just fighting symptoms instead of getting to the root of the problem, and possibly pushing that even further because the "solution" is "good enough". If this is such a problem for script developers then surely it should get prioritised as such?

What is the true solution though
I'm sure we could code something up if we have that.

At work we generally isolate components, so that the "apps" doesn't' need to skin those. They can just use checkmark, buttons and headers and paragraphs and in general control the layout. Usually its blocked out but thats something our skinning engine is bad at.

If the problem is just the components then I think the macro stuff would work _now_ obviously if it helps we could perhaps move some of those ideas to core and force every skinner to create the components?

[pecinko]

What we probably need is a few more default controls to stick in the defaults.xml (ie fullscreen texture, dialog texture, header label, etc) and then hopefully everything will look correct in all skins.

Let's take a few examples - global search, previous subtitle download script & lyrics. Looking at how different those are, do we really think there can be a one-size-fits all solution? We can even go into such a nuances as how does the skin solve window or dialog backgrounds, different sizes for controls and such. Lyrics has player controls, subtitle downloader had 2 dialogs of different size etc.

Only real solution may be that essential ones get moved to a core and we live with a fact that the other ones are Confluence like skinned but with a possibility for a skinner to incorporate them in a skin if he finds them useful enough for larger audience.

<offtopic>

IMAO, some of the script have no place in KODI at all - you *can* make a script that would control your smart refrigerator but that *does not mean* we should have it KODI. Cool, have your own fun with it just don't expect me to skin it.

</offtopic>

[Jeroen]

What exactly is holding back a true solution for this anyway? All this is just fighting symptoms instead of getting to the root of the problem, and possibly pushing that even further because the "solution" is "good enough". If this is such a problem for script developers then surely it should get prioritised as such?

What is the true solution though
I'm sure we could code something up if we have that.

At work we generally isolate components, so that the "apps" doesn't' need to skin those. They can just use checkmark, buttons and headers and paragraphs and in general control the layout. Usually its blocked out but thats something our skinning engine is bad at.

If the problem is just the components then I think the macro stuff would work _now_ obviously if it helps we could perhaps move some of those ideas to core and force every skinner to create the components?

My knowledge about Kodi core is in no way sufficient enough to provide a solution. But letting add-ons include their own fontsets seems ideal to me. They can include their own skin xmls too after all. But apparently that solution is being held back by something, otherwise it would have been done already. Hence my question what is holding it back.

In general I am just a big fan of separating UI and content completely / as much as possible. Add-ons IMO should provide content and use the plugin views and controls available and not be concerned with the UI in any way.

If an add-on author so desperately wants / needs to deviate from that, they should write / be facilitated to write their own completely custom UI and don't force skinners to provide support for them. I don't think the solution for this will be found / should be sought after on the skin side.

[ruuk]

What exactly is holding back a true solution for this anyway? All this is just fighting symptoms instead of getting to the root of the problem, and possibly pushing that even further because the "solution" is "good enough". If this is such a problem for script developers then surely it should get prioritised as such?

What is the true solution though
I'm sure we could code something up if we have that.

At work we generally isolate components, so that the "apps" doesn't' need to skin those. They can just use checkmark, buttons and headers and paragraphs and in general control the layout. Usually its blocked out but thats something our skinning engine is bad at.

If the problem is just the components then I think the macro stuff would work _now_ obviously if it helps we could perhaps move some of those ideas to core and force every skinner to create the components?

My knowledge about Kodi core is in no way sufficient enough to provide a solution.

In general I am just a big fan of separating UI and content completely / as much as possible. Add-ons IMO should provide content and use the plugin views and controls available and not be concerned with the UI in any way.

You are talking about plugin addons, which are not really relavant to this discussion, which is about addons that have their own skin.

If an add-on author so desperately wants / needs to deviate from that, they should write / be facilitated to write their own completely custom UI and don't force skinners to provide support for them. I don't think the solution for this will be found / should be sought after on the skin side.

This is not about skinners supporting something specific addons want to do. Addons that have their own skins are meant to extend Kodi by providing their own new windows and dialogs. Unfortunately the skinning engine for addons is incomplete. We cannot define our own fonts (among other things) and so are stuck making a skin that only works well when Confluence is the skin or just accepting that we get one random font size for all of our controls.

The point of this thread was to suggest a workaround until someone takes up the job of writing the code to fix this situation, which is not a trivial task.

[ruuk]

What exactly is holding back a true solution for this anyway? All this is just fighting symptoms instead of getting to the root of the problem, and possibly pushing that even further because the "solution" is "good enough". If this is such a problem for script developers then surely it should get prioritised as such?

What is the true solution though
I'm sure we could code something up if we have that.

At work we generally isolate components, so that the "apps" doesn't' need to skin those. They can just use checkmark, buttons and headers and paragraphs and in general control the layout. Usually its blocked out but thats something our skinning engine is bad at.

If the problem is just the components then I think the macro stuff would work _now_ obviously if it helps we could perhaps move some of those ideas to core and force every skinner to create the components?

While what you suggest would improve the skinning engine, it is not necessarily relavant to solving the problem at hand, which is actually fixing the portion of the skinning engine that applies to addon skins. Addon skins currently have zero control over what fonts they use while the Kodi skins do, and I can't see how the right solution is not to first make addon skins function at least as well as Kodi skins.

[Jeroen]

You are talking about plugin addons, which are not really relavant to this discussion, which is about addons that have their own skin.

I understand that, which I made the distinction that followed (even though for example plugin add-ons can force font colors independent from the skin, clearly no separation there)

This is not about skinners supporting something specific addons want to do. Addons that have their own skins are meant to extend Kodi by providing their own new windows and dialogs. Unfortunately the skinning engine for addons is incomplete. We cannot define our own fonts (among other things) and so are stuck making a skin that only works well when Confluence is the skin or just accepting that we get one random font size for all of our controls.

The point of this thread was to suggest a workaround until someone takes up the job of writing the code to fix this situation, which is not a trivial task.

Which is why I feel this is a matter of keeping the same problem, but placing the solution / workaround at the skinning side of it all. Like I mentioned, putting a couple of fontsets in my fonts.xml is no effort at all, but I truly believe it solves nothing. What benefit does this bring over simply including Confluence's fontset in third-party skins?

And like stated before, as there is no relative sizing it doesn't guarantee anything looking good. Sure, individual skinners could specify what the font size for a heading will be, but if the script author has a much bigger font in mind for it, the actual space designated to that header could be way too big in one skin or too small in another. That's just one example.

[topfs2]

I think I've missunderstood the problem. I thought it was about addon creators wanting to make windows which feels similar to the rest of the skin, but I guess its about being able to create windows which looks the same no matter the skin?

I actually didn't know that scripts couldn't provide their own fonts.xml and I wonder if its hard to add, I'll need to go through the code a bit to see if I can answer why this hasn't been added, if there is in fact a technical problem with having it.

[Martijn]

Montellese has a PR for that now iirc (fonts.xml)

[ruuk]

Montellese has a PR for that now iirc (fonts.xml)

Unless I'm missing something, it looks like the pull request is from Jonathan Marshall in May of 2014, and Montellese came across that PR/branch when going through some of his unfinished work. This is mentioned earlier in this thread.

[bossanova808]

What's happened to Jonathan anyway? Is it just 'real life'? Hope he is ok, he has always been such an amazing contributor and level head for the project...

[Martijn]

What's happened to Jonathan anyway? Is it just 'real life'? Hope he is ok, he has always been such an amazing contributor and level head for the project...

Jep real life and decided to take step back. He still lurks around and gives awesome advice
Who know one day he finds his way back.

[bossanova808]

Fingers crossed! But the time commitment for even casual contributions is pretty huge so hardly surprising!

[ruuk]

(even though for example plugin add-ons can force font colors independent from the skin, clearly no separation there)

I don't think that is allowed in the official repo, and I'm not aware of any there that do this, but they shouldn't. Outside official they do all kinds of crazy stupid stuff.

[ronie]

thanx for all the input everyone!

reading back through all the responses, i conclude the opinion of the average skinner is somewhat along these lines:
"i will add it if i really have to, but i don't believe it will really help"

since there's no majority that believes the suggestion i made would be really beneficial to addon developers,
i'm not going to add this to our list of required skin changes for I****.

[Razze]

Just to keep this complete, here is a real world example
http://forum.kodi.tv/showthread.php?tid=...pid1942037