[realcopacetic]

I'm trying to create a system where users can choose how to speed up my animations and window transitions. I know you can speed up animations in the addon.xml using the 'effectsslowdown' tag, but I think this is a bit of a hack and would be over-written every update anyway.

So I've created two speed profiles currently using two sets of Constants, one 'default' and one 'quick'. The transitions and animation times are all multipliers of a base time. What I'd like to do is change the 'quick' profile to a 'user-defined' profile by letting the user enter a value e.g. 200 and then that will be used as the base time and then the other constants would be calculated from that.

Is it considered bad form or inadvisable to do this by using a python script to overwrite the values in my Constants.xml file? I am assuming this would even be possible with something like ElementTree, although I've not actually looked into the specifics yet. Just wanted to get a sense of if this is a direction I want to go down?

[Hitcher]

Is it considered bad form or inadvisable to do this by using a python script to overwrite the values in my Constants.xml file?

I don't think it would be allowed in the official repo but I can't remember the exact rule right now.

[roidy]

I don't think it would be allowed in the official repo but I can't remember the exact rule right now.

Wouldn't this just be the same as how skinshortcuts works? That basically just writes and rewrites an xml file inside the skins directory.

[jjd-uk]

Regarding tbe repo rules, I believe addons are normally not allowed to modify the xml files of other addons in the background. I believe it might be allowed if there's some consent mechanism, and there might also be leeway if it's your addon modifying your skin e.g. skin dependency.

[Hitcher]

Wouldn't this just be the same as how skinshortcuts works?

But that specific XML is only used for skin shortcuts.

[roidy]

Wouldn't this just be the same as how skinshortcuts works?

But that specific XML is only used for skin shortcuts.

It isn't only used for skin shortcuts, it also builds entire groups of controls at run time for displaying widgets.

But fair enough... I guess then you could create an Include file with only your skin animations inside and modify that. That way you are only modifying your own animations file and not the skins Constants xml file.

[realcopacetic]

Wouldn't this just be the same as how skinshortcuts works?

But that specific XML is only used for skin shortcuts.

It isn't only used for skin shortcuts, it also builds entire groups of controls at run time for displaying widgets.

But fair enough... I guess then you could create an Include file with only your skin animations inside and modify that. That way you are only modifying your own animations file and not the skins Constants xml file.

so you mean it would be better to create a new include file like skinshortcuts does rather than editing an existing skin file? That might be more agreeable because there's no risk of the script changing things in the skin without the skinner's knowledge. It's just changing stuff in a file that's ignored unless the skinner's explicitly chosen to use it.

[roidy]

But that specific XML is only used for skin shortcuts.

It isn't only used for skin shortcuts, it also builds entire groups of controls at run time for displaying widgets.

But fair enough... I guess then you could create an Include file with only your skin animations inside and modify that. That way you are only modifying your own animations file and not the skins Constants xml file.

so you mean it would be better to create a new include file like skinshortcuts does rather than editing an existing skin file? That might be more agreeable because there's no risk of the script changing things in the skin without the skinner's knowledge. It's just changing stuff in a file that's ignored unless the skinner's explicitly chosen to use it.

Yes, pretty much. The Constants.xml file isn't anything special, it's just another include file, in fact it can be named anything you want and you can even have multiple constants files in your skin as long as they all get included in the main Includes.xml file so personally I see nothing wrong with letting an addon modify it, but it seems people may have an issue with that.

What I would do is have two constants files, your main unchanging one and then a runtime generated one for your animations that you rewrite when the user changes a value, and include them both:-

Main unchanging constants file:-

Constants.xml:
<?xml version="1.0" encoding="UTF-8"?>

<includes>

    <!-- All the unchanging constants go here -->



    <constant name="contentLeft">100</constant>

    <constant name="contentTop">240</constant>

    <constant name="contentWidth">1720</constant>

    <constant name="contentHeight">840</constant>

</includes>

Animation constants file that is generated and changed by your addon:-

Generated_Animation_Constants.xml:
<?xml version="1.0" encoding="UTF-8"?>

<includes>

    <!-- All the generated animation constants go here -->



    <constant name="slidetime">100</constant>

    <constant name="fadeTime">240</constant>

</includes>

Then just include both:-

Includes.xml:
<?xml version="1.0" encoding="UTF-8"?>

<includes>

    <include file="script-skinshortcuts-includes.xml" />

    <include file="Constants.xml" />

    <include file="Generated_Animation_Constants.xml" />



    ...........

    ...........

</includes>

This way you are only generating and changing the file with just the animation values in. Skinshortcuts has been generating xml files in Kodi skins for years and nobody had any issue with it, so I don't see why you shouldn't be able to generate a file containing a few constants that change the way your animations work.

[jurialmunkey]

You can do this with the newer versions of script.skinvariables to build an xmltemplate (on my repo and has a PR for official repo pending review). I still need to document all the features but this type of thing is simple

In shortcuts dir add a file to act as the template - e.g. shortcuts/myconstants.xmltemplate
Note the file extension must be .xmltemplate not .xml

xml:


<constant name="view_pad">$MATH[80 * {mod}]</constant>

Then you setup a JSON generator file in the same folder - e.g. shortcuts/skinvariables-generator-myconstants.json

json:


{

    "folder": "1080i",

    "output": "script-skinvariables-generator-myconstants-includes.xml",

    "header": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<includes>",

    "footer": "</includes>",

    "buildv": "0.0.1",

    "getnfo": {},

    "addnfo": {},

    "global": {},

    "genxml": [

        {

            "template": "myconstants.xmltemplate"

        }

    ]

}

Then you include the output file in your includes

xml:


<include file="script-skinvariables-generator-myconstants-includes.xml" />

Finally, add an onload command to your Home.xml to make sure the file will be generated (same process as SkinShortcuts).

xml:


<onload>RunScript(script.skinvariables,action=buildtemplate,template=myconstants,mod=2)</onload>

SkinVariables will then generate the output by passing the mod argument to the {mod} tags (and then doing the math inside $MATH). The file will be hashed so that the onload command will only rebuild it if the arguments change or file is missing (e.g. after an update) etc.

If you want to force it to build, add the "force" argument to the runscript - e.g. if you want a button somewhere to run it manually. You can also add the "no_reload=true" if you don't want the script to reload the skin after generating the file (generally you do though as you want includes to update after the file is made).

[realcopacetic]

You can do this with the newer versions of script.skinvariables to build an xmltemplate (on my repo and has a PR for official repo pending review). I still need to document all the features but this type of thing is simple

In shortcuts dir add a file to act as the template - e.g. shortcuts/myconstants.xmltemplate
Note the file extension must be .xmltemplate not .xml

xml:


<constant name="view_pad">$MATH[80 * {mod}]</constant>

Then you setup a JSON generator file in the same folder - e.g. shortcuts/skinvariables-generator-myconstants.json

json:


{

"folder": "1080i",

"output": "script-skinvariables-generator-myconstants-includes.xml",

"header": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<includes>",

"footer": "</includes>",

"buildv": "0.0.1",

"getnfo": {},

"addnfo": {},

"global": {},

"genxml": [

{

"template": "myconstants.xmltemplate"

}

]

}

Then you include the output file in your includes

xml:


<include file="script-skinvariables-generator-myconstants-includes.xml" />

Finally, add an onload command to your Home.xml to make sure the file will be generated (same process as SkinShortcuts).

xml:


<onload>RunScript(script.skinvariables,action=buildtemplate,template=myconstants,mod=2)</onload>

SkinVariables will then generate the output by passing the mod argument to the {mod} tags (and then doing the math inside $MATH). The file will be hashed so that the onload command will only rebuild it if the arguments change or file is missing (e.g. after an update) etc.

If you want to force it to build, add the "force" argument to the runscript - e.g. if you want a button somewhere to run it manually. You can also add the "no_reload=true" if you don't want the script to reload the skin after generating the file (generally you do though as you want includes to update after the file is made).

That sounds amazing. I feel like every time I have an issue, it's one that you've already solved with script.skinvariables. TBH, I've been a bit intimidated by it as I think to unlock it's potential would require a pretty extensive rewrite of my code, but this seems like a nice isolated use case to start testing it. Thanks as always @jurialmunkey.