[BobCratchett]

Ah, looks like the versions in the docs weren't updated when the actual version was (0.5.3 -> 0.6.0). Apologies for any confusion that's caused.

[tomer953]

You could probably do something really hacky (and not at all secure) by overriding all actions in a menu.

Code:

<override action="globaloverride" group="[menu id]">
    <condition>StringCompare(Skin.String(password),[mysecretpassword])</condition>
</override>
<override action="globaloverride" group="[menu id]">
    <condition>!StringCompare(Skin.String(password),[mysecretpassword])</condition>
    <action>Skin.SetString(password)</action>
</override>

(remembering to replace [menu id] with the actual group name of the menu, and of course setting [mysecretpassword] to something).

Maybe even combine it with a AlarmClock to reset the skin string after a few seconds. However, it would be very easily by-passable, and would be user specific (unless your skin builds an additional menu just for non-family-friendly shortcuts).

To be done properly would need someone with skinning and python experience, and the interest in parental controls, to think through exactly what changes would be needed (and all the different scenarios, to ensure it would work well). I can't personally think of a good way this could be done.

Thanks dude about your comment and help!

about the easy ways to pass this, there is always be a way to hack things, but its not the point...
sometimes users have little kids (3-4-5 years old, that using kodi to watch kids show) - and we want to prevent for them to enter some menu that they shouldnt. they should not know how to read overrides.xml at that age :]
so small option like you offered, could be great.
However, I tried your code:

Code:

    <override action="globaloverride" group="mainmenu">
        <condition>StringCompare(Skin.String(mypassword),1234)</condition>
    </override>
    <override action="globaloverride" group="mainmenu">
        <condition>!StringCompare(Skin.String(mypassword),1234)</condition>
        <action>Skin.SetString(mypassword)</action>
    </override>

and the script has crashed..
http://pastebin.com/99PRQgKj

any way, I think users will want the option to assign the password to a spesific menu, that they will create.. so it can make a little problem define it in the overrides file before they created it...
I hope Marcel will take this Idea into the Helper script.
Thanks.

[BobCratchett]

From a quick glance, it looks like I may have got the documentation wrong for that feature. Try adding <action>::ACTION::</action> to the first override.

If it's not that, I'll look properly into the problem (and correct the docs) this evening. Thanks for the bug report.

(Looked at it - it's both a bug and bad docs, so I've added the fix to my open PR, but adding the <action /> as above should work)

[tomer953]

Yeap, its working...
Still, a lot of problems with that method... I counted few of them before, and I can think of some more.. (what about the sub menu of the same item? the widget of the menu? I want to only show things that its not protected)
eyes goes to the Helper in that case.. :]

[User 224999]

Yeap, its working...
Still, a lot of problems with that method... I counted few of them before, and I can think of some more.. (what about the sub menu of the same item? the widget of the menu? I want to only show things that its not protected)
eyes goes to the Helper in that case.. :]

I can think of a few scenario's on this:

1. Set password/pincode protection on menu items. If you try to enter them it will ask for the password/pincode.

2. Hide items when parental mode is active.

I think option 2 is better done with kodi profiles, they're meant for that...

Option 1 is possible... I can create a validatePincode endpoint in the helperscript for that (or in skinshortcuts).
There should then be a condition added to the onclick. if parental control active (property on the shortcut), go through the validatePincode code or else just navigate to the action.

[tomer953]

Option 1 is better,

In my eyes this should be the best:
* in the skinshortcuts management dialog I will add radiobutton to "Protect this menu with password"
* in the main menu, Item that is protected, will ask for the password - if wrong - exit the dialog, if good- enter the menu
* the sub menu and widgets should be hidden untill the password for the main menu is entered, so here we need some thinking, maybe to set timer for it, from the moment you entered the password, they will be visible for X minutes...
for some extra options, I think youll also need to provide some visible condition that we can use, for example, to hide the path\label2 in the management dialog,
background of the menu also should be hidden, even the label of the menu, untill the password is entered...

Thanks for thinking about it.

[User 224999]

Even the label... Uhm, that wont be very practical. Isn't it just better to just hide it all and create one unlock button? This already exists I kodi and is called masterlock. Just add a visibility condition for that

[tomer953]

I meant, that with the visible condition youll provide, I can replace ListItem.Label with "Hidden" label or something... or even just to replace the icon\thumb to some key\lock icon... not removing it completly...
Masterlock is too general, AFAIK you can't assign the lock to a specific menu-item...

[mikeSiLVO]

I was looking over the new documentation and noticed the vertical menu section that says to add the following to the build line.

Code:

&mode=buildsingle

Does that mean the <onload> and <onunload> of Home.xml and SkinSettings.xml?
I added it like this

Code:

RunScript(script.skinshortcuts,type=buildxml&mainmenuID=9000&mode=buildsingle)

and I thought it would create a new skinshortcuts-allmenus include but it did not. Not sure if I am doing it correctly
Can anyone help point me in the right direction?

Thanks.

[BobCratchett]

Incorrect docs it should be `&amp;mode=single`

To be honest it's very possible that bit of the docs won't be complete - the function was added way back when for reFocus, but never documented until now. And even then, I've done it by looking at the reFocus code and already got it wrong once, so please let me know about any issues/ommissions you find with the vertical menu docs, and I'll do my best to work out what it should be

(BTW, wanted to thank you for your suggestion of restoring a shortcut - I've been playing with it and it's a really useful addition. PR is open on BigNoid's git if you want to try it yourself)

[mikeSiLVO]

Incorrect docs it should be `&amp;mode=single`

To be honest it's very possible that bit of the docs won't be complete - the function was added way back when for reFocus, but never documented until now. And even then, I've done it by looking at the reFocus code and already got it wrong once, so please let me know about any issues/ommissions you find with the vertical menu docs, and I'll do my best to work out what it should be

(BTW, wanted to thank you for your suggestion of restoring a shortcut - I've been playing with it and it's a really useful addition. PR is open on BigNoid's repo if you want to try it yourself)

Thank you once again Bob

New toys... I love new toys will definitely take a look.

I had one more question/possible suggestion... Is there any way to provide an upgrade path if a skin wanted to update to skin.shortcuts for the home menu but keep existing user customization? The properties would be named differently so I was thinking of an upgrade template with old to new properties to populate the shortcuts include after a first run/build of the new menu. Not sure if this is something that is doable or even worth it but I thought I would ask/mention it in case it is already possible or was a good idea.

[BobCratchett]

Not currently possible, no. Technically possible, definitely. Good idea... I'm split! I can understand the desire to make things easy for the user, and the improved UX for the user. My concerns would come purely from an implementation principal - it's potentially a lot of code to maintain for a one-time function for the users, with a lot of behaviours to think through before implementation - for example, what happens on a reset, and how does the script know the difference between shortcuts being reset and an upgrade. Plus there's the fact that maintaining upgrade code (from the old .shortcuts files to the current .DATA.xml files) has already proved difficult as the scripts functions evolved, and very problematic when the time came for it to be removed!

Either way, it's not something I'll get around to looking into properly any time soon (I'm concentrating my feature-adding time on other projects for a little while). If no-one else steps up to look into implementing it, though, feel free to open an issue on Git so it doesn't get forgotten about.

[avia]

I have to say something ..

I've been following this thread, I enjoy reading and see the Help @BobCratchett provides everyone.
Really well done.

[Jayz2K]

I have to say something ..

I've been following this thread, I enjoy reading and see the Help @BobCratchett provides everyone.
Really well done.

SkinShortcuts is having real breath of fresh air. Job made these days really push possibilities to another level. Many thanks to devs for that and yes, especially to Bob ...

@Bob : what the vertical menu is intended for / looks like ... I'm curious

[BobCratchett]

@Jayz2K - not that you don't have enough to do with all the customisations you're working on for the home screen, I'd love to see what you could do with it!