[BobCratchett]

OK, I know what I just said, but I've just written the code so that entire menu's aren't shared between skins if the user chooses to enable this option in the scripts settings (turns out there's a way to do this with very little code). I recognise there's a desire for this, so if this is something that you (or your skins users) have asked for please test the branch here - https://github.com/Ignoble61/script.skin...hare-menus - and please also note I'm not going to PR this unless and until its been thoroughly tested and I've got positive feedback on it

As the menu's are no longer shared when this option is enabled, obviously menus will reset to the skin default and need to be customised again. There may well be bugs (or, more likely, areas I've overlooked that need to be update). And it will probably also break the skin helpers backup functions (which will be updated alongside any PR of this code)

[Talguy]

I'm a user of @jurialmunkey's skins, Artic Zephyr and Eminence 2. I absolutely love these skins and how he integrated this script into them for greater customization. One issue I've been discussing with him and others is that the home screen settings of one skin gets copied over to the other skins I may have installed. For some parts I want this feature as it make setting up a new skin based on this script really easy. However, I also do not like this feature as certain skins have a different style to them and I prefer to set them up differently or I'm experimenting with a different layout of my home screen in a different skin. I would really love to see a feature built into this script asking the user if they'd like to import the settings from another skin that uses this script and saves each skins settings separately as there is a very good chance where I could screw up the settings in one skin that could then end up screwing up my settings in another skin I way switch to in the future.

[BobCratchett]

Well, the post right above yours would be the first step to this... With that, menu's aren't shared (if the user so chooses). To add an import function on top of that would be fairly easy (though maybe not so easy to decide how and where to expose that functionality to the user.) First stage, though, is getting the above in - so if it's a feature you want (or will lead to one ) please test and leave feedback on it (It's not a feature I'll personally use, so it really does need lots of good testing by those who will use it so that it's stable to begin with and unlikely to break as the script evolves.)

Unless I'm misunderstanding what you don't want to carry between skins...?

[Talguy]

Nope you're spot on. Its at least step 1 of 3 of what I'm requesting. I'll try to test it later on my test install of Kodi, not sure how extensive of a test I'll be able to perform

[BobCratchett]

Any testing you can do is appreciated. And step 2 is now in there - via the 'Reset shortcuts' button in the management dialog (note, any skin you want to import the menu from must have had its menu built with this script version). Step 3 - which I assume is a dialog popping up when the skin is first used - is a lot harder (in terms of where in the Skin Shortcuts code it would make sense to implement such - I can't think of anywhere obvious where it wouldn't have the potential to prove to be difficult or annoying...)

[Talguy]

my 0.02 as a user about step 3 would be to have it as an extra option that skin developers could implement in their settings section. It will force the user to perform the import versus the software determining if this was the first time the skin was used or not. I would say it would be a dedicated function invoked.

[BobCratchett]

It could additionally be implemented as a function with a little bit of code re-arranging (though I quite like it under the 'Reset shortcuts' option, so I'd prefer to keep it there as well). It would be dependant on skinners showing some interest in using that function, though... (No point adding extra code to maintain if its not going to be used!)

[BobCratchett]

Thought I'd already posted asking for feedback on this, but apparently not

For those who have requested being able to set a default for a custom property (for when the user hasn't selected a particular value), can you please test https://github.com/BigNoid/script.skinsh...s/pull/105. We're looking at doing a repo push with Jarvis changes sooner rather than later, so for this to go into the next version, feedback would be needed fairly quickly (Otherwise, it'll be merged straight after the repo push.) Thanks in advance.

[Jayz2K]

Thought I'd already posted asking for feedback on this, but apparently not

For those who have requested being able to set a default for a custom property (for when the user hasn't selected a particular value), can you please test https://github.com/BigNoid/script.skinsh...s/pull/105. We're looking at doing a repo push with Jarvis changes sooner rather than later, so for this to go into the next version, feedback would be needed fairly quickly (Otherwise, it'll be merged straight after the repo push.) Thanks in advance.

Yes Bob, got a notification for this. Thanks for this and sorry for not having replied yet. I was a bit focused on another part of code but will try to dig into this next week if it's still time to

[BobCratchett]

Nothing to be sorry about Any testing you can do is hugely appreciated.

Not quite sure on the exact timings - the first thing is to get confirmation that it actually works for skinners (no point merging something that doesn't do what you guys need). Then to get it into users hands via the Emby beta repo, to confirm it doesn't break anything in general usage (though a big part of the next version is code changes to make the script less susceptible to breakages - I'm really hoping to not break Nox 5 this time around ). The challenge is getting all that done before we have to do a repo push for Jarvis (we have important changes to the music library shortcuts to get in). Worst comes to the worst, it goes in the next version

[Talguy]

Any testing you can do is appreciated. And step 2 is now in there - via the 'Reset shortcuts' button in the management dialog (note, any skin you want to import the menu from must have had its menu built with this script version). Step 3 - which I assume is a dialog popping up when the skin is first used - is a lot harder (in terms of where in the Skin Shortcuts code it would make sense to implement such - I can't think of anywhere obvious where it wouldn't have the potential to prove to be difficult or annoying...)

Just tested the "Dont share menus between skins" feature and it seems to be working. I'm able to set up my two skins based on this add-on independently of each other.

[Jeroen]

Sorry if this had been answered before or if it's completely obvious.

I have this label on my homescreen:

PHP Code:

<label>$INFO[Container(9000).ListItem.Property(widgetName)]</label> 


If I understand the docs correctly this should display the property widgetName, set in overrides.xml. So I have this for example:

PHP Code:

<shortcut label="342" type="32099" widgetName="Movies Watchlist" icon="DefaultIconWatchlist.png" widget="Addon" widgetType="movies" widgetTarget="video" condition="System.HasAddon(script.watchlist)">plugin://service.library.data.provider?type=recommendedmovies&amp;reload=$INFO[Window(10000).Property(watchlistmovies)]</shortcut> 


However this is displaying the "label" instead of the "widgetName".

In short, I want the label used to name the widget in the management dialog to be different from the one in the homescreen's label.

[BobCratchett]

Just tested the "Dont share menus between skins" feature and it seems to be working. I'm able to set up my two skins based on this add-on independently of each other.

Thanks for the feedback

Sorry if this had been answered before or if it's completely obvious.

I have this label on my homescreen:

PHP Code:

<label>$INFO[Container(9000).ListItem.Property(widgetName)]</label> 


If I understand the docs correctly this should display the property widgetName, set in overrides.xml. So I have this for example:

PHP Code:

<shortcut label="342" type="32099" widgetName="Movies Watchlist" icon="DefaultIconWatchlist.png" widget="Addon" widgetType="movies" widgetTarget="video" condition="System.HasAddon(script.watchlist)">plugin://service.library.data.provider?type=recommendedmovies&amp;reload=$INFO[Window(10000).Property(watchlistmovies)]</shortcut> 


However this is displaying the "label" instead of the "widgetName".

In short, I want the label used to name the widget in the management dialog to be different from the one in the homescreen's label.

There's currently no 'widgetName' attribute for the <shortcut /> element - as you've discovered it sets the widgetName to the label Should be an easy change to add it, though - I'll take a look this evening. (Just for the record - the attributes available for <shortcut /> elements for widgets)

[Jeroen]

Cheers Bob

I have to admit though at the moment I am behind on recent(ish) developments and as a result a bit confused about the difference between using <shortcut> elements for widgets and defining them as <widget>

I am currently defining then as shortcut in a custom grouping and everything works as intended, but I am unsure if this is the advised way.

[BobCratchett]

Cheers Bob

I have to admit though at the moment I am behind on recent(ish) developments and as a result a bit confused about the difference between using <shortcut> elements for widgets and defining them as <widget>

I am currently defining then as shortcut in a custom grouping and everything works as intended, but I am unsure if this is the advised way.

Can you please test https://github.com/BigNoid/script.skinsh...s/pull/115 - Cheers

I think its fair to say that the <shortcuts /> were really added for the scripts own use but skinners have found them useful as they allow far more customisation of where their widgets appear. I don't think one is particularly recommended over the other - defining widgets the classic way is a little easier (especially for setting defaults), doing it via <shortcuts /> is more customisable - use whichever works for you