Req Suggestion: Include directive with parameters
#1
Don't know if something similar had been proposed before, but it would be nice if includes could accept parameters and be able to generate dynamic content based on them. I think this could clean up skin XMLs a bit while not being too difficult to implement (in fact I might do it when I find some time).

Say you want to include some complex control in various places in the skin (maybe even in the same window) but each time with a slight variation like different position, color, texture, etc. Say that control is composite, consisting of multiple nested controls, and that this slight change affects most of them. Also, let this variation not be based on any specific condition like player state, current window or such -- you just want slightly different instances in multiple places (e.g. keyboard dialog buttons).

AFAIK, currently you'd have to duplicate great deal of XML for the entire "outer shell" of the control (and do the same for all nested controls!), while possibly including just some tiny common bits here and there. So inclusion doesn't help much here.

Global variables are also not suitable because their value cannot be changed once defined, so they cannot simulate true parameters.

Possible syntax might be:

Code:
<!-- default parameter values are given here, others are mandatory -->
<include name="MyControl" PosX="120" PosY="120">
   <control ...>
     <posx>$PARAM[PosX]</posx>
     <posy>$PARAM[PosY]</posy>
     <control ...>
       ...
       <texture border="$PARAM[Border]">$PARAM[Background]</texture>
     </control>
     ...
     <include Color="$PARAM[Color]">MyControl2</include>
     ...
   </control>
   ...
</include>

Parameter names could be given in different case, with some prefix or such, to differentiate them from built-in attributes.

This would basically turn includes into "procedures" (when needed) and their "calls" into one-liners.

What do you think?
Reply
#2
Good suggestion, could indeed save a lot of code. I think we can consider adding something like this after Gotham is released.
Image
Reply
#3
+1 for this
I can see a bunch of ways this could be used to simplify blocks of xml skin code
Reply
#4
+1 on saving lines of code
-2 on readability
My skins:

Amber
Quartz

Reply
#5
I think any language construct can be misused, mistreat or abuse.

I feel this feature has more + than - though.
Reply
#6
I could definitely see many uses for this, using it sensibly goes for anything really.
Reply
#7
A huge +1 on this especially if we could get it worked into the defaults.xml file to allow custom controls. For example Hitchers code to duplicate a spincontrol is really great, but it involves coding two lists (over 100 lines of code) to show one spincontrol in a settings menu.

Sure the code in the defaults.xml file might be a bit messy, but the saving in code and debugging time for each time this custom control is used would be huge.

Wyrm (xTV-SAF)
If required a FULL debug log can now be submitted from the skin in settings->skin settings->support. Or follow instructions here if you can't access skin settings.

FAQ's located at :- http://kodi.wiki/view/Add-on:AppTV
Reply
#8
I want this, desperately. Not needing 100 lines to change one attribute would make my skins so much easier to read and maintain.
It would be nice to pass infolabels trough as well.
Image
Reply
#9
OK, if there are no objections, I'm thinking of implementing this one, but we should first agree on the exact syntax.

What do you think of syntax proposed above where:
  1. capitalized attributes denote custom parameters
  2. only default values for parameters are given within include tag
  3. $PARAM[] is resolved before everything else ($INFO labels etc.)
  4. $PARAM[] can be used inside of attributes (e.g. in nested include calls)
  5. when some argument is not passed and it has no default value, its occurrences in included body are replaced with empty strings (silently or with a warning?)
Of course, it should be possible to specify custom parameters with all combinations of standard include attributes, namely file, name and condition.

Regards,
R.
Reply
#10
It looks good to me.
Reply
#11
Git Pull Request: https://github.com/xbmc/xbmc/pull/4876
Reply
#12
Many thanks rahotep. I hope it will get accepted soon, eager to experiment with this Smile
Reply
#13
Good work, am also looking forward to playing with this.
Reply
#14
Have you received any feedback yet on this? Do you know if it will be accepted yet?
Reply
#15
If there's any feedback to it, I'm sure it will be in the pull request
Reply

Logout Mark Read Team Forum Stats Members Help
Suggestion: Include directive with parameters0