[phil65]

I would also be fine with "include id". Keep in mind though that changing the syntax of the references is definitely more work for skinners than changing the syntax of the include definitions.

Should I prepare that change then when I find some time? Any objections?

Sorry to BobCratchett for being a bit to quick with pushing for changes.

The endresult will be

<include definition="blabla">
</include>

and

<include id="blabla">
<param name="blah" value="blah"/>
</include>

right ?

Nope.
The favourite seems to be:

Definition:
<include name="blabla">
</include>

and

Reference:
<include id="blabla">
<param name="blah" value="blah"/>
</include>

[User 224999]

ah! I get it. Sounds good to me and makes sense

[Hitcher]

ID is even shorter so yes.

[jurialmunkey]

+1 for keeping def as <include name="xxxx"> in order to maintain consistency with VARs

-1 for using id="xxxx" as it is inconsistent with how id= is used elsewhere (particular with reference to integers).

For calling includes I would prefer something along the lines of

PHP Code:

<include content="xxxx"> 


[phil65]

+1 for keeping def as <include name="xxxx"> in order to maintain consistency with VARs

-1 for using id="xxxx" as it is inconsistent with other controls using only integers.

For calling includes I would prefer something along the lines of
<include content="xxxx">

I agree with all points, and "content" sounds fine to me. Perhaps that´s something we can all agree on?

[BobCratchett]

+1 for using 'name' as attrib for definition, maintaining consistency (afaik) with current alpha-numeric definitions - fonts sprint to mind.

-1 for using 'name' as attrib for definition, just because Phil seemed so sure it was going to be 'definition', and pushed for the changes to the Skin Shortcuts script

[phil65]

-1 for using 'name' as attrib for definition, just because Phil seemed so such it was going to be 'definition', and pushed for the changes to the Skin Shortcuts script

Sorry, I was a bit too quick there. Reason is that I really want to get this change in quickly. Much better to do all those breaking changes in one go IMO, and all the (ongoing) xml merges seem to make this a good time for this.

[BobCratchett]

Hope the indicated my comment was in jest. Genuinely, its nice for Skin Shortcuts to be considered a legitimate enough part of Kodi to get a heads up that we might need to make changes (My +1 was genuine, though...)

[Hitcher]

+1 for keeping def as <include name="xxxx"> in order to maintain consistency with VARs

-1 for using id="xxxx" as it is inconsistent with other controls using only integers.

For calling includes I would prefer something along the lines of
<include content="xxxx">

I agree with all points, and "content" sounds fine to me. Perhaps that´s something we can all agree on?

[ronie]

fine with me as well, though kodi devs seem to have a strong preference for changing the tag name instead of the attribute name.

[`Black]

Well, I'd have to go with jmarshallnz suggestion here. Use a different tag name for definitions plus also change the way it's included.

I.e.

PHP Code:

<definitions>
<definition name="foo"></definition>
</definitions>

<include definition="foo"></include>

#or use template
<templates>
<template name="foo"></template>
</templates>

<include template="foo"></include> 


It sure would require massive code changes in existing skins but it would clearly differentiate between defining some template code and including it somewhere.

[BigNoid]

I like the template aproach. Skin breakage will occur no matter what we do here so I am not to worried about that.

[Jayz2K]

I'm still in favor not changing the definitions.
I was about to say the same thing than BigNoid and Jurial about id="" but sounded not such a huge deal finally. Content="" is fine for me.

@Black : there's certainly good reasons for this proposal but that's no more tags changes ? This is a complete rewrite of the include function and I admit being a bit lost with this.

Off topic : This has nothing to do with def / call discussion but since an includes rewrite is on the go, it's maybe the good time to place it again. So mind to reconsider adding conditions to params ? I know this was a long discussion and wasn't retained because of vars but vars are not universal. It could avoid us writing dozen separate Includes with their own params and also finally get some dynamic values where vars are not supported (width / height / idletime, ...).

[Hitcher]

I'm still in favor not changing the definitions.
I was about to say the same thing than BigNoid and Jurial about id="" but sounded not such a huge deal finally. Content="" is fine for me.

Me too, at least this way the only changes we need to make are when using parameters.

[Gade]

I'm still in favor not changing the definitions.
I was about to say the same thing than BigNoid and Jurial about id="" but sounded not such a huge deal finally. Content="" is fine for me.

Me too, at least this way the only changes we need to make are when using parameters.

I'm in favor of this as well.

+1 from me on this.