(2016-01-14, 22:06)Jayz2K Wrote: [ -> ]Mr. V Wrote:If I could use a variable within the template I can then use $PARAM[Id]. Each and every widget would then have a unique id, it would greatly reduce the variables and animations between menu items would be much smoother. Just a hunch on the reported disappearing widget issue, I am suspecting it could be related to using the same panel id. (i cant replicate the issue though myself). I must say though along the road of coding the widgets the same panel id between menu items has caused many coding headaches and i have had to find ways around the issue.
Do you just need to separate panels ID's or do you also need to add variables ?
If you need both, it's something I tried with including $PARM[ID] in variables values but doesn't work, so I used cascading $PARAMs.
And, you're right, the disappearing panel is because of the shared ID ...
Hi Jayz2K
Adding separate panel ids is no issue. There is widget panel information artwork plot ect. that is displayed outside of the panel so variables are required for fall-backs and mixed widgets.
I'm not sure how to accomplish the cascading $PARAMs. Do you have an example? May be you could point me to an xml on your GitHub.
Sure ...
The main idea is that you can pass the $PARAM[Id] like this :
Code:
<!-- include call -->
<include name="level1">
<param name="Id" value="MyWidgetPanelId" />
</include>
<!--include def-->
<include name="level1>
<control type="group">
<!-- include call -->
<include name="level2 condition="MyCondition1">
<param name="Id" value="$PARAM[Id] /> <!-- Pass $PARAM[Id] from level1 to level2 -->
<param name="Var" value="ReplaceMyVarValue1" />
</include>
<!-- include call -->
<include name="level2 condition="MyCondition2">
<param name="Id" value="$PARAM[Id] />
<param name="Var" value="ReplaceMyVarValue2" />
</include>
...
</control>
</include>
This way you can use the Skinshortcut Id and pass it to different levels with conditions to build scenarios.
You can check my Home.xml and template.xml for passing the ID :
Home
Template
And the cascading here :
Home Viewtype (Most Interresting part starts at line 516)
Note : I mostly use a custom Property passed to param ($PARAM[CompPrefix]) to do that instead of just the Id but it depends the way you want to handle it.
Cheers Jay.
Think it will take a bit of time to wrap my head around your method and change how my variables work.
ATM I should get back to updating the widget code as this was something I really was going to look at in a couple of weeks Right now I'm just trying to collect ideas on how to accomplish the separate id. This may work but I need some time to think about it all.
Much appreciated.
One question / issue or whatever it can be called :p ...
I've been reported that setting the background for each item with user's picture path (the same for all items) makes the wallpaper to change at each item jump. Meaning it doesn't give a linear / smooth multiimage slideshow in this particular situation.
Not a huge issue IMO and this can be solved by setting an "Overall background override" in skin.settings but for consistency, there's maybe a way in the code to keep cycling the previous item Background property if the next is the same ?
Thanks, cheers.
@Mr. V - Highly unlikely to be done in a separate file. Skin Shortcuts got special dispensation to write an additional file to the skins directory (something plugins really shouldn't do). I don't know we'd get approval to write a second one. It would also add a lot of complexity to the script in terms of where to open/write the second file, working with different profiles in the second file, and so on (things that are already managed in the current file).. I'm hopeful I'll now have time to look into this over the weekend, but before I do I have to ask if you've tried with templates as-is. Whilst it probably won't work, something like...
Code:
<other include="variables">
<controls>
<variable name="variableOneWith$SKINSHORTCUTS[property]">
<value condition="...">...</value>
</variable>
<variable ...>
</controls>
</other>
(And when that doesn't work, if you can tell me why that gives me a good area to start looking at when I begin work on this
)
@
jayz - Potentially possible with templates. Certainly they were coded so that if two menu items generated the same template, the template would only be generated once but with visibility conditions so that both menu items would use it. So...
Code:
<other include="background">
<property="background" tag="property" attribute="name|background" />
<controls>
<control type="multiimage">
<skinshortcuts>visibility</skinshortcuts>
<include>multiimagelayout</include>
<texturepath>$SKINSHORTCUTS[background]</texturepath>
</control>
</controls>
</other>
... should create a single multi-age control for all menu items with the same background property (though obviously you'd have to handle other backgrounds - playlist backgrounds for example - separately).
Brilliant Bob ! Works ! Didn't know this was already implemented at template level ... Good to know
(2016-01-15, 16:41)BobCratchett Wrote: [ -> ]Code:
<other include="variables">
<controls>
<variable name="variableOneWith$SKINSHORTCUTS[property]">
<value condition="...">...</value>
</variable>
<variable ...>
</controls>
</other>
@Bob : Maybe without the <controls> tags or is this required ?
(2016-01-15, 16:41)BobCratchett Wrote: [ -> ]@Mr. V - Highly unlikely to be done in a separate file. Skin Shortcuts got special dispensation to write an additional file to the skins directory (something plugins really shouldn't do). I don't know we'd get approval to write a second one. It would also add a lot of complexity to the script in terms of where to open/write the second file, working with different profiles in the second file, and so on (things that are already managed in the current file).. I'm hopeful I'll now have time to look into this over the weekend, but before I do I have to ask if you've tried with templates as-is. Whilst it probably won't work, something like...
Code:
<other include="variables">
<controls>
<variable name="variableOneWith$SKINSHORTCUTS[property]">
<value condition="...">...</value>
</variable>
<variable ...>
</controls>
</other>
(And when that doesn't work, if you can tell me why that gives me a good area to start looking at when I begin work on this )
(2016-01-15, 18:49)Jayz2K Wrote: [ -> ]@Bob : Maybe without the <controls> tags or is this required ?
The Variable is written to the skinshortcuts_includes.xml without an issue. The <controls> tag is not written to this file and is required to make the template work.
Code:
<include name="skinshortcuts-template-variables-Master user">
<variable name="HomeWidgetPosterVar">
<value condition="!IsEmpty(ListItem.Art(poster))">$INFO[ListItem.Art(poster)]</value>
<value condition="!IsEmpty(ListItem.Art(tvshow.poster))">$INFO[ListItem.Art(tvshow.poster)]</value>
<value condition="!IsEmpty(ListItem.Icon)">$INFO[ListItem.Icon]</value>
<value>$INFO[ListItem.Art(thumb)]</value>
</variable>
</include>
The issue is the kodi cannot use a variable within an include tag. To test this, I deleted the include tags surrounding the variable, disabled skin shortcuts and refreshed the skin. It then worked.
The solution would be:
If a variable tag is used within the <controls> tag, skin shortcuts will not write the include tags either side of the variable.
Alternatively maybe a new template tag <variables> (similar to <controls>) . Something like this in the template;
Code:
<other include="widget">
<controls>
(label, image controls ect here)
</controls>
<variables>
<variable name="variableOneWith$SKINSHORTCUTS[property]">
<value condition="...">...</value>
</variable>
</variables>
</other>
Hi ...
One question (but I think I know the answer) ...
Is there a way to set a property in all main menu items outside the SkinShortcuts Dialog ?
Practical case would be to set the same background property to all items to have a single common background for Home ? But triggering that from skin settings' button ?
Thanks.
@Mr. V - The difficulty is that templates use the includes to manage the differences between profiles. Without the includes, that will have to be handled differently for variables, which obviously makes it more complex to code
@
Jayz2K - You're right, the answer is 'No'
(In fact, I don't think its even possible to set the background for all menu items from within the management dialog...) The UX branch, though, includes the very first bits of code that allow the menu to be changed from outside of the management dialog. It's possible that code could be built on in the future to allow such a feature. No time soon, though.
Hey Bob,
Just thinking about missing icons when switching skin.
I noticed that some skins use <icon> definitions in overrides while I'm using <thumbnail> definitions. Could this be an issue ? What if I declare both with the same target ?
<icon /> elements
override an icon (the original intention of this was to avoid the issue we now have with missing icons - so shortcuts would always use the
default icons, then skins could override them if they specifically needed something else. However skins are now setting icons directly to special:// paths in their default shortcuts, which then don't work when the user switches skin)
<thumbnail /> elements are
defining what thumbnail are available for the user to select from (normally through a 'Choose icon' button, though it actually selects the thumbnail not the icon...). It's not possible to override the thumbnail.
So, not sure where I get this for my overrides. But seems useless (while it has no sense in the code) and my icons should then be the default ones ... what is correct. Right ?
EDIT : So maybe settings all default icons to the extras folder could do the trick until a solution is found in the script ?
I'll have a fully working workaround in the UX branch by the end of the day, and hopefully in master within a week (the UX branch should already work in cases where the icon uses the special:// protocol - which is a lot of other skins. Where it doesn't I suspect I'll need to use the same method as is used for labels - store both the 'short form' (material/videocam.png) and the long form (/path/to/skin/media/material/videcam.png), then check whether the first is accessible when building the menu.)
The original intention was for your icons to be the default ones. If you went down that route now, you'd be one of the few skins that did so I wouldn't worry too much about it
All your <thumbnail /> elements are perfectly valid, by the way - they're what appear when the user selects 'Change Icon'.