[Hitcher]

Worked perfectly, as expected, so now Conq can have a different home background for each menu item.

I'll hold off sending a pull request until this hits the official repo.

Thanks.

[removed151214]

I'll hold off sending a pull request until this hits the official repo.

Don't worry, I get the hint One piece of code to write, one bug to track down and one piece of feedback to receive on a feature, and pull request will be made.

[Hitcher]

Actually it doesn't break anything if you're not using the latest git version so I might go ahead anyway.

Pressure relieved.

[User 224999]

Hi Unfledged,

First of all, I really like your work with this addon.
I've spent the last few weeks on adopting your addon in my skin, it works beautifully for both home menu's, submenu's, widgets, backgrounds.

I do have one question however...

I noticed that the default for the script is to share the homemenu items across different skins.
Is it also possible to make this user-selectable ?
OR: skin selectable, so the skinner can provide it's default shortcuts ?

For example I support multiple libraries in my skins so I provide a good set of default shortcuts, submenu's and widgets with my skin.
As I released the beta yesterday from my skin with the skinshortcuts-integration I noticed that users don't get my defaults unless they reset to shortcut defaults in settings (if they used the script before for antother skin).
Basically I want to ask them if they like to receive the skin default shortcuts or just use the existing menu and if yes do the reset, is that even possible ?
If not I will just use the normal command for reset and the user gets 2 confirmation prompts..


Besides my question I have one small problem...

I have a few shortcut items that have visibility conditions based on a Home-window property...
Also the title gets read from a window property.

I suspect that the skinshortcuts-script doesn't actually parse those window-properties as it outputs $INFO[propertydescription...] as labels for those items instead of the actual title.
Also I'm not sure if the visibility conditions will be checked correctly with those window-properties. This behaviour is only in the settings dialog. In the actual home menu the shortcuts offcourse displays and works fine.

I also tried to use skin strings for this but noticed that also doesn't work :-)

Do you see any possibility to add a check in the code to replace the window-property with the actual value in the settings dialog ?
For now I temporary "fixed a hack" for it in DialogSelect to show "custom title" as the listitem's title instead of the nasty $INFO[blabla] string...

I provide a list with custom library entries (for mediabrowser addon) from where they can choose from but now they have to trial and error to get the right entry :-)
Offcourse I'd be happy to make the modification myself and provide you the merge request.

Really great addon! Thanks for your time/help in advance!

Regards,

Marcel

EDIT: now that I'm reading all the forumthread I see you just created an option to hide the warning... Will go that way than...
<onclick>RunScript(script.skinshortcuts,type=resetall,warning=false)</onclick>

Only the issue with the window properties remains...

[removed151214]

Hi Unfledged,

First of all, I really like your work with this addon.
I've spent the last few weeks on adopting your addon in my skin, it works beautifully for both home menu's, submenu's, widgets, backgrounds.

Glad you like it, and nice to see it used with MediaBrowser. TBH, I didn't expect to see it used with that backend.

I do have one question however...

I noticed that the default for the script is to share the homemenu items across different skins.
Is it also possible to make this user-selectable ?
OR: skin selectable, so the skinner can provide it's default shortcuts ?

For example I support multiple libraries in my skins so I provide a good set of default shortcuts, submenu's and widgets with my skin.
As I released the beta yesterday from my skin with the skinshortcuts-integration I noticed that users don't get my defaults unless they reset to shortcut defaults in settings (if they used the script before for antother skin).
Basically I want to ask them if they like to receive the skin default shortcuts or just use the existing menu and if yes do the reset, is that even possible ?
If not I will just use the normal command for reset and the user gets 2 confirmation prompts..

As you've already spotted, the ability to bypass the scripts own prompt has already been added. I honestly can't remember if that's on the repo version yet but, if not, it really shouldn't be long before it is.

It may well be possible to do something about this in the future but, largely after the posts in the early part of this thread, the script is based on the idea of the users menu carrying over between skins. I can actually see where this idea could fit into the code, so it's something I'll at least consider for a future version.

Besides my question I have one small problem...

I have a few shortcut items that have visibility conditions based on a Home-window property...
Also the title gets read from a window property.

I suspect that the skinshortcuts-script doesn't actually parse those window-properties as it outputs $INFO[propertydescription...] as labels for those items instead of the actual title.
Also I'm not sure if the visibility conditions will be checked correctly with those window-properties. This behaviour is only in the settings dialog. In the actual home menu the shortcuts offcourse displays and works fine.

I also tried to use skin strings for this but noticed that also doesn't work :-)

Do you see any possibility to add a check in the code to replace the window-property with the actual value in the settings dialog ?
For now I temporary "fixed a hack" for it in DialogSelect to show "custom title" as the listitem's title instead of the nasty $INFO[blabla] string...

I provide a list with custom library entries (for mediabrowser addon) from where they can choose from but now they have to trial and error to get the right entry :-)
Offcourse I'd be happy to make the modification myself and provide you the merge request.

Behaviour of default shortcuts (assuming you're referring to the default shortcuts?) with visibility properties should be much improved on the git version of the script - that's actually the feedback I'm waiting on that I reference a couple of posts back. If there's something there that isn't working, though, please let me know

As regards parsing the labels - no it doesn't. It's another of those cases - which seem to come up with every skinner who tries the script, and that I love! - where you're doing something I hadn't anticipated anyone trying to do I've added some quick code to git to actually retrieve the infolabel of any label beginning with a $ - so it should work for $INFO's (including skin strings) and $VAR's. If you could try it and let me know if that works for you.

If you did want to look at the specific code involved - the available shortcuts are all generated in the _create() function of library.py - starting line 371

[User 224999]

Wow! That's a fast action AND reaction, amazing!
Well I will try it out myself tonight when I get home. In the meanwhile I've asked my beta users to try out your fix too.

Yeah your script is also beiing used with MediaBrowser.
I added custom nodes and shortcuts for that, so users can select the entry they like.

Just another small issue I've seen myself and now also reported by another user:

If you go into the edit screen for the menu shortcuts (script-skinshortcuts.xml) and you select an existing tile and than replace the shortcut with another one (yeah I use the choose shortcut dialog instead of separate lists)... than some properties of the previous shortcut get copied, for example the widget and background. Don't know if you even heard about this behaviour before ? In the meanwhile I suggest users just to add a new menu item and than set the shortcut for it.

[removed151214]

For my mind, that's the expected behaviour. As the menu items are more than just a shortcut (they're also a menu position, a widget, a background, a submenu, custom properties), when I select a new action for a shortcut well, that's all I'm doing (OK, new label too...), not creating a new shortcut. I think it's preferable behaviour if, for example, I want to link my Movies menu item somewhere else (an alternative video node for example) - in that case I don't want to loose my chosen widget or background. I'd agree with your suggestion, if you want a new shortcut then create a new shortcut (Having said that, if you can make the case against I'm happy to consider it!)

[Hitcher]

Have to agree, you're basically editing a current item. Delete and add new to start from scratch.

[User 224999]

Yeah you're totally right with that behaviour. It's "by design" and I think a good design.
I'll add some help text in my skin settings screens to explain the behaviours.
Thanks again for the quick reply.

Oh, in the meanwhile I can confirm that your fix for the window-properties does work!
Also reported by a beta tester that it's okay now.

[User 224999]

Just one more thing... Is is possible to do the "windowproperties fix" also for the list 211 in script-skinshortcuts.xml ?

[removed151214]

Ah, I forgot to test that when re-loading the management dialog. Fix now on git.

[User 224999]

Ah, I forgot to test that when re-loading the management dialog. Fix now on git.

Wow, amazing. The fix works like a charm, really great and fast work.
Any vision on when this will be aprox. available in the stable repo ?

Thanks again for the great work

[removed151214]

It helps when the fix is a copy-paste

I'm now just waiting for feedback from someone developing a private skin on whether the changes to visibility handling of user-selected shortcuts works to their satisfaction. Assuming it does, I'll spend a few hours doing a few last-minute checks (the last version was the first time I hadn't left in a bug that I had to fix quick, and I'd love to repeat that!) and the pull request will be made.

Obviously then, it'll be a few days for the request to be processed and, assuming its accepted, a day or two more for it to propagate. So, if the skinner gets back to me in the next couple of days (and I don't need to make more changes), best case would probably be on the repo and fully propagated this weekend or early next week.

[User 224999]

It helps when the fix is a copy-paste

I'm now just waiting for feedback from someone developing a private skin on whether the changes to visibility handling of user-selected shortcuts works to their satisfaction. Assuming it does, I'll spend a few hours doing a few last-minute checks (the last version was the first time I hadn't left in a bug that I had to fix quick, and I'd love to repeat that!) and the pull request will be made.

Obviously then, it'll be a few days for the request to be processed and, assuming its accepted, a day or two more for it to propagate. So, if the skinner gets back to me in the next couple of days (and I don't need to make more changes), best case would probably be on the repo and fully propagated this weekend or early next week.

That would be really great. That way I also have some beta test time for my skin now that it has the support for your script.
I'll than publish to the repo when your plugin update is available.

Allready got lots of positive feedback from users from the integration so great stuff.

[User 224999]

One more small question of some behaviour I just spotted while investigating a users problem...
If you change the label of a shortcut the thumb/icon gets reset. Is that a problem or by design ?
Also I noticed that the labelID property gets set by the new name, while the icon assignments (overrides) check the labelID and not the defaultID (which stays the same).

So for example if you have a Movies tile with a movies thumb assigned to it and you change it name to Films, you loose the thumb.