Kodi Community Forum

Full Version: script.skinshortcuts
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
(2016-01-22, 18:47)BobCratchett Wrote: [ -> ]My bad. I forgot I needed to actually change what list it gets added to Blush Should now be working correctly.
Thanks Bob, I can confirm that m3u video playlists are working and showing up in the right place! Smile
Small feature request:
adding "icon" attribute to <background /> tag in the overrides.xml
for example:
Code:
<background label="400" icon="my/custom/icon/here.png">weather</background>
Can you please test the PR, @tomer953 Smile
(2016-01-23, 11:31)BobCratchett Wrote: [ -> ]Can you please test the PR, @tomer953 Smile

quick and accurate like always.
confirmed working. 10x.
(2016-01-21, 18:02)BobCratchett Wrote: [ -> ]@Mr. V - can you please test this branch for initial support of variables in templates.

It adds a new section to the 'Other' templates for your variables, within which you can use any $SKINSHORTCUTS properties you like:-

The full <variable /> element is required each time - Skin Shortcuts will take care of combining these across multiple templates. I don't really have a use-case for this myself and as such I've only done sanity checks, so can you please test not only that it works, but that it does what you need Wink

Cheers.

Hi Bob, Thanks for the addition.

In my template
Code:
<other include="widgetvars">
        <condition tag="property" attribute="name|widgetArt">FanArt</condition>
        <property name="id" tag="mainmenuid" />
        <controls>            
        </controls>
        <variables>
            <variable name="HomeWidget8011$SKINSHORTCUTS[id]FanArtVar">
                <value condition="!IsEmpty(Container(8011$SKINSHORTCUTS[id]).ListItem.Art(fanart))">$INFO[Container(8011$SKINSHORTCUTS[id]).ListItem.Art(fanart)]</value>
                <value>$INFO[Container(8011$SKINSHORTCUTS[id]).ListItem.Art(thumb)]</value>
            </variable>
        </variables>
    </other>

Written in the includes
Code:
<variable name="HomeWidget80111FanArtVar">
        <value condition="StringCompare(System.ProfileName,Master user) + [!IsEmpty(Container(80111).ListItem.Art(fanart))]">$INFO[Container(80111).ListItem.Art(fanart)]</value>
        <value condition="StringCompare(System.ProfileName,Master user)">$INFO[Container(80111).ListItem.Art(thumb)]</value>
    </variable>

A few things to report;

1. If I don't include <controls></controls> tags skinshort cuts will not build the menu. In the logs I get this
Code:
13:37:39 T:15128   DEBUG: script.skinshortcuts: Building menu for profile Master user
13:37:40 T:15128   DEBUG: script.skinshortcuts: Failed to write menu
13:37:40 T:15128   ERROR: Traceback (most recent call last):
13:37:40 T:15128   ERROR:   File "C:\Kodi\portable_data\addons\script.skinshortcuts\resources\lib\xmlfunctions.py", line 93, in buildMenu
13:37:40 T:15128   ERROR:     self.writexml( profilelist, mainmenuID, groups, numLevels, buildMode, progress, options, minitems )
13:37:40 T:15128   ERROR:   File "C:\Kodi\portable_data\addons\script.skinshortcuts\resources\lib\xmlfunctions.py", line 586, in writexml
13:37:40 T:15128   ERROR:     Template.parseItems( "mainmenu", 0, templateMainMenuItems, profile[ 2 ], profile[ 1 ], "", "", mainmenuID )
13:37:40 T:15128   ERROR:   File "C:\Kodi\portable_data\addons\script.skinshortcuts\resources\lib\template.py", line 104, in parseItems
13:37:40 T:15128   ERROR:     self.findOther( item, profile, profileVisibility, visibilityCondition )
13:37:40 T:15128   ERROR:   File "C:\Kodi\portable_data\addons\script.skinshortcuts\resources\lib\template.py", line 311, in findOther
13:37:40 T:15128   ERROR:     textVersion = xmltree.tostring( template.find( "controls" ), encoding='utf8' )
13:37:40 T:15128   ERROR:   File "C:\Kodi\system\python\Lib\xml\etree\ElementTree.py", line 1126, in tostring
13:37:40 T:15128   ERROR:     ElementTree(element).write(file, encoding, method=method)
13:37:40 T:15128   ERROR:   File "C:\Kodi\system\python\Lib\xml\etree\ElementTree.py", line 817, in write
13:37:40 T:15128   ERROR:     self._root, encoding, default_namespace
13:37:40 T:15128   ERROR:   File "C:\Kodi\system\python\Lib\xml\etree\ElementTree.py", line 876, in _namespaces
13:37:40 T:15128   ERROR:     iterate = elem.getiterator # cET compatibility
13:37:40 T:15128   ERROR: AttributeError: 'NoneType' object has no attribute 'getiterator'

2. The condition i have setup is to check for fanart. I have three menu items where the 'widgetArt' attribute is set to 'FanArt' It only writes the variable for the first one it finds.

3. I am not to keen on 'StringCompare(System.ProfileName,Master user)' being written in the condition. As my widget code is quite complex, if were to use this method of variables It would write hundreds of variables. Thats a lot of string compares and I would be concerned that it would impact performance on lower powered devices.

It seems like if any of the conditions change skin short cuts will re-code the include file, so I cant imagine that a variable needs to be specific to a user. Different user may have different widget setups but all that would mean is on change of the user, the template would be rewritten with slight variable changes.

4. I haven't tested this out yet but a potential issue could be the [..... ] added around the condition. If you had more complex conditions it may not play so nice.

I would like to be able to code it like this;
Code:
<other include="widgetvars">
        <condition tag="property" attribute="name|widgetArt">FanArt</condition>
        <property name="id" tag="mainmenuid" />
        <variables>
            <variable name="HomeWidget8011$SKINSHORTCUTS[id]FanArtVar">
                <value condition="!IsEmpty(Container(8011$SKINSHORTCUTS[id]).ListItem.Art(fanart))">$INFO[Container(8011$SKINSHORTCUTS[id]).ListItem.Art(fanart)]</value>
                <value>$INFO[Container(8011$SKINSHORTCUTS[id]).ListItem.Art(thumb)]</value>
            </variable>
        </variables>
    </other>

And say if I has 3 menu items with fanart it would output as so;
Code:
<variable name="HomeWidget80111FanArtVar">
        <value condition="!IsEmpty(Container(80111).ListItem.Art(fanart))]">$INFO[Container(80111).ListItem.Art(fanart)</value>
        <value>$INFO[Container(80111).ListItem.Art(thumb)]</value>
    </variable>
    <variable name="HomeWidget80112FanArtVar">
        <value condition="!IsEmpty(Container(80112).ListItem.Art(fanart))]">$INFO[Container(80112).ListItem.Art(fanart)</value>
        <value>$INFO[Container(80112).ListItem.Art(thumb)]</value>
    </variable>
    <variable name="HomeWidget80113FanArtVar">
        <value condition="!IsEmpty(Container(80113).ListItem.Art(fanart))]">$INFO[Container(80113).ListItem.Art(fanart)</value>
        <value>$INFO[Container(80113).ListItem.Art(thumb)]</value>
    </variable>

I must say great work though. Kodi reads the variable written in the includes without an issue.
@tomer953 - Thanks for testing, I'll get it merged into master at some point today

@Mr. V - Similarly, thanks for testing. In regards your points

(1) Should now be fixed on git

(2) I can't reproduce this - though if it was linked to (1), which is possible, that would make sense (which came down to an issue with the code that checks whether a template has already been built)

(3) I did say that profiles would be an issue with variables, as they were previously managed by the <include />'s Wink Whilst it may be possible to be smarter with matching up variables from different profiles so that the profile condition isn't written if the variable would be the same for multiple profiles (or in cases where this is only one profile), fundamentally the profiles need to be handled here - wherever possible the menu is built just once for each skin after settings changed and shouldn't be re-written just because the user has switched profiles (though there are some situations that can cause it, particularly with the UX branch this is based upon)

(4) The [....] means that any existing conditions will be evaluated separately (whilst retaining any 'grouping' of conditions you have) to the profile condition.
(2016-01-24, 07:56)BobCratchett Wrote: [ -> ]@tomer953 - Thanks for testing, I'll get it merged into master at some point today

@Mr. V - Similarly, thanks for testing. In regards your points

(1) Should now be fixed on git

(2) I can't reproduce this - though if it was linked to (1), which is possible, that would make sense (which came down to an issue with the code that checks whether a template has already been built)

(3) I did say that profiles would be an issue with variables, as they were previously managed by the <include />'s Wink Whilst it may be possible to be smarter with matching up variables from different profiles so that the profile condition isn't written if the variable would be the same for multiple profiles (or in cases where this is only one profile), fundamentally the profiles need to be handled here - wherever possible the menu is built just once for each skin after settings changed and shouldn't be re-written just because the user has switched profiles (though there are some situations that can cause it, particularly with the UX branch this is based upon)

(4) The [....] means that any existing conditions will be evaluated separately (whilst retaining any 'grouping' of conditions you have) to the profile condition.

I can confirm Issues with 1. and 2. are working ok now.

3. It wont matter from my end as I run an i7. Smarter matching would be great as it would not write the extra string compares. I'm going to have to code some variables in and hopefully some one with a lower spec machine can give it a whirl to see if any slow downs occur. What I imagine though it is possible on slower machines is the cpu usage may increase. But really I am just going off kodi team members suggestions as string compares are slow.

4. As I said I haven't tested this one. Its just a guess. Possibly it might mean being a bit smarter with the conditions for the variables and it may not be an issue at all. (possibly I haven't coded the conditions in the most efficient manner)

I'll do some more testing as I would like to hold off on the widget update a bit more if this will be added soon (at least to the GitHub branch). The addition will make my code a lot simpler to maintain. The complexity for the widgets for me is getting a bit out of hand (without the variables in Skin Shortcuts), with the addition of variable it will simplify everything. I have everything working without this addition, but maintaining the code is going to be a real headache. If I release this as is , the main menu will have to be set up all over again. If I incorporate the new variables the same thing will happen again. Really wanting to get one release done in one go with the new addition.

I'll make the changes to include the skin shortcut variables and PM you a copy and the madnox team (I'm pretty sure I am pushing the templates to there limits, so if there are any issues I'm sure it will break). Easy enough to do so hopefully within the next day or so.
I'll throw one more thing out there on fall backs if empty;

Code:
<propertyfallback property="widgetArt">FanArt</propertyfallback>

This can only be set to one value. I was wondering if you would consider adding a condition such as;

Code:
<propertyfallback tag="property" attribute="name|widgetType" value="movies">Poster</propertyfallback>
<propertyfallback tag="property" attribute="name|widgetType" value="music">Square Poster</propertyfallback>

So after selecting the widget, if a user has not selected an artwork type it will fall-back to specific artwork type. A plus side of this is if the evaluated attribute is not set it will not write anything to the includes. ATM the fallback values are written to each menu property and also a template is written for widgets that are not setup by the user. (although not visible on the main menu).


EDIT: Beyond this I would have no other feature requests. It would definitely complete the of my needs for the widgets.

Also on the plus side the widgets could be added to ANY skin using skinshortcuts for the main menu. It would mostly be a copy and paste, changing some co-ordinates and fonts in the template, updating textures if you like too. A few navigational changes and visibility conditions too. I have coded everything in such a way so this is possible. Really just a few hours or so work.
@Mr. V - an attempt to combine variables where appropriate (and so not have profile conditions in those instances) is now on git. I don't know if you use profiles or not - if not, I'll have to do more testing before I'll be happy to commit it Smile (And in general, I'll commit this all to master when I'm happy its working and doing what it needs to do. Between this, the UX branch and a couple of other things to go in there's a high chance of breakages, though, so this is all going to need some thorough user-testing before any repo push)

The conditions for property fallbacks is on my to-do list (was it you who requested it previously?) though a gentle reminder is always welcome Smile The thing that puts me off purely from a coding perspective is handling it in the management dialog, where I'm going to need to think through all the places where its going to need to be re-checked to see if the fallback value would have changed. But I will get to it sooner or later Smile
How to add a submenu to a submenu ?

I have test this :

Code:
<control type="button" id="405" description="Set Submenu">
                    <width>100%</width>
                    <label>Submenu</label>
                    <visible>stringcompare(Window.Property(groupname),mainmenu)</visible>
                    <include>Defs_OptionButton</include>
                </control>
                
                <control type="button" id="406" description="Set Submenu2">
                    <width>100%</width>
                    <label>Submenu</label>
                    <visible>!stringcompare(Window.Property(groupname),mainmenu)</visible>
                    <include>Defs_OptionButton</include>
                </control>

but <include>skinshortcuts-submenu-1</include> return nothing
If the script-skinshortcuts-includes.xml doesn't have the relevant include, chances are you haven't adjusted your build line to tell Skin Shortcuts to build additional submenus. See the docs for details.

However, 406 is for additional submenus for the main menu, not for submenus of submenus - there's no support for that in the script.
Thanks for your reply.

I have read the doc.

In my Home.xml et SkinSettings.xml, I have this :

Code:
<onload>RunScript(script.skinshortcuts,type=buildxml&amp;mainmenuID=9000&amp;group=mainmenu|x1101|x1102|x1103|x1104|x1105|x1106|x1107|x1108|x1109|powermenu)</onload>


So it's not possible to add submenu to a submenu ? Only additionnal submenu for mainmenu if I understand ?
You understand correctly - I can add it to the feature requests if you like, but it would likely be difficult to implement (re-write of generating labelID's, as all submenu items would have to be taken into account when generating; extension of build line to accept the submenu control id; rewrite of build to generate 2nd level submenus + generate visibility conditions and so forth) so there could be no promises on it actually being done.
(2016-01-24, 21:05)BobCratchett Wrote: [ -> ]You understand correctly - I can add it to the feature requests if you like, but it would likely be difficult to implement (re-write of generating labelID's, as all submenu items would have to be taken into account when generating; extension of build line to accept the submenu control id; rewrite of build to generate 2nd level submenus + generate visibility conditions and so forth) so there could be no promises on it actually being done.

If you can it will be wonderfull. Thanks.