Looks like their's a bug with showNone/custom where the string "True" or "False" isn't being translated into a Python boolean True/False - I'll push a fix for this to the repo shortly. (And thanks for highlighting the issue before we did a repo push
) edit - should now be fixed on Git.
The big issue here is the <grouping />, which is working correctly for me. Can you please post a copy of your overrides.xml - with the <mygroupings-groupings /> shown, and again post the exact <onclick /> you're now using, so I can test with as-close-as-possible-to-your-settings-as-possible
Code:
<mygroupings-groupings>
<content>video</content>
</mygroupings-groupings>
Note the 's' at the end of groupings
oh dear.... smh
Never mind me. Yep its working now...
Fantastic
And thanks again for the showNone/custom bug!
Also, the Helper Service entries are showing up in both Choose Shortcut and Select Widget menus even though I haven't included anything in my overrides files to show them...
In Choose Shortcut I get a "Smart Shortcuts" entry at the top and in Widgets I get a "Default Widgets" entry.
Here's a log:
http://pastebin.com/N0VWzTNm
Overrides:
http://pastebin.com/uRfUgT3u
They're in the scripts own overrides.xml -
https://github.com/BigNoid/script.skinsh...rrides.xml
If you want to remove them/change where they appear in the choose shortcut or widget dialog/change what and where anything else appears in said dialogs you can copy/paste the <groupings /> or the <widget-groupings /> into your skins overrides and customise to your hearts content (accepting that the <content /> tags that aren't included by default with the widgets won't actually work for widgets...)
Awesome. Is there anyway to make my own <content> sections?
I have 9 customisable hub items in Eminence2 and I really want to put them in their own section rather than dumping them all in common shortcuts...
Nope, no custom <content /> sections, though it's not a bad idea. If it's just 9 items, using <shortcut /> tags within your <groupings /> may be an acceptable solution:-
Code:
<shortcut label="Display label/widgetName" type="Display label2" icon="Display icon" widget="value of widget property" widgetType="value of widgetType property" widgetTarget="value of widgetTarget property">path/WidgetPath</shortcut>
Obviously the various widget properties only make sense within the <widget-groupings /> and can be omitted in other cases
Ah fantastic. Works perfectly! Didn't realise you could do that
I'm sure I'm missing something obvious again, but is there a way to hide a grouping node based upon whether or not the user is customising a submenu / mainmenu / other? I really only want to display the hub items for the main menu
Now that's an interesting question and, honestly, I'm not sure...
In theory, it could be done by using a StringCompare in a <node />'s condition based on the windows groupname property. Whether it would work in practice - particularly when multiple script-skinshortcuts.xml windows are open (editing a submenu from a main menu, for example, launches a whole new instance of the gui) - would need some testing.
Code:
<node label="my label" condition="StringCompare(Window(id-of-script-skinshortcuts.xml).Property(groupname),mainmenu)">
Alternatively, if that doesn't work, something similar should work to display a different custom groupings (one which includes your hub items, one which doesn't) based on the same property purely within the GUI xml code.
@
tomer953 - you requested (in the skin helper service) the ability to select program plugins such as super favourites as widgets. I've opened a PR with this feature but, as its your request, it would be great if you could test it out and confirm it works for you before it gets merged -
https://github.com/BigNoid/script.skinshortcuts/pull/67
(It's also worth noting that, whilst this should be quick to get onto Git, it will still be a while before the changes reach the repo)
Cheers
0.6.0 seems to have a problem, 0.5.3 works fine. I had to kick the 0.5.3 version up to 99.5.3 to stop it from pulling the 0.6.0 one that doesn't work right.
0.6.0 is throwing this in the kodi.log on a Windows machine running 16 a2
Code:
22:07:48 T:9932 ERROR: File "C:\Users\User\AppData\Roaming\Kodi\addons\script.skinshortcuts\resources\lib\xmlfunctions.py", line 196, in shouldwerun
22:07:48 T:9932 ERROR: hashes = ast.literal_eval( xbmcvfs.File( os.path.join( __masterpath__ , xbmc.getSkinDir() + ".hash" ) ).read() )
22:07:48 T:9932 ERROR: File "C:\Program Files (x86)\Kodi-16\system\python\Lib\ast.py", line 49, in literal_eval
22:07:48 T:9932 ERROR: node_or_string = parse(node_or_string, mode='eval')
22:07:48 T:9932 ERROR: File "C:\Program Files (x86)\Kodi-16\system\python\Lib\ast.py", line 37, in parse
22:07:48 T:9932 ERROR: return compile(source, filename, mode, PyCF_ONLY_AST)
22:07:48 T:9932 ERROR: File "<unknown>", line 0
Is it maybe from using it on Kodi 16?
This script is now deeply imbedded in many skins, and when it breaks, it can take the whole skin down. Maybe you can fork it into two flavors? skin.shortcuts-safe & skin.shortcuts-bleeding-edge?
Thanks for the work on it, without it soooooo many skins would have sad non-configurable menus.