Kodi Community Forum

(2015-09-28, 09:23)BobCratchett Wrote: [ -> ]I always love seeing the almost-ridiculously inventive things you skilled skinners come up with A way to access the ID will be added this afternoon, though I'll contact you to test if that's ok, so we can make sure it does what you need before it gets merged

Well, if failing to achieve something using the door, why not trying the window ? Sure will test Thanks again Bob

@Jayz2K, pr here - if you could test and let me know that it works and does what you need

It lets you pull the main menu items id into a property:-


which can then be used as any other template property.

(2015-09-28, 15:41)BobCratchett Wrote: [ -> ]@Jayz2K, pr here - if you could test and let me know that it works and does what you need

It lets you pull the main menu items id into a property:-

Code:

<property name="[propertyName]" tag="mainmenuid" />

which can then be used as any other template property.

Ahhhhh ... Of course it works Well done.
Thanks Bob !

I currently have this in my SkinSettings.xml:


But it's also in the <onload> in Home.xml. Is the one in SkinSettings.xml supposed to be there?

It was done in both places per the README, but it seems like it might cause a problem (calling the script twice when leaving Skin Settings dialog and returning to the main menu).

(2015-09-28, 16:33)Jayz2K Wrote: [ -> ]

(2015-09-28, 15:41)BobCratchett Wrote: [ -> ]@Jayz2K, pr here - if you could test and let me know that it works and does what you need

It lets you pull the main menu items id into a property:-

Code:

<property name="[propertyName]" tag="mainmenuid" />

which can then be used as any other template property.

Ahhhhh ... Of course it works Well done.
Thanks Bob !

You have more faith in my scripting skills than I Thanks for testing, I'll get it merged shortly.

(2015-09-28, 16:46)jingai Wrote: [ -> ]I currently have this in my SkinSettings.xml:

Code:

<onunload>RunScript(script.skinshortcuts,type=buildxml&amp;mainmenuID=9000&amp;levels=0)</onunload>

But it's also in the <onload> in Home.xml. Is the one in SkinSettings.xml supposed to be there?

It was done in both places per the README, but it seems like it might cause a problem (calling the script twice when leaving Skin Settings dialog and returning to the main menu).

Certainly its always been the recommendation to have it in both places - in skinsettings.xml so that the menu gets written asap when the user has made changes; and in home.xml so the script can always ensure the menu is up to date (after a skin upgrade, for example.) Of course it's always skinners choice at the end of the day but, if you do decide you only want one of them, I'd recommend keeping the home.xml one

It shouldn't cause any problems, having the two. The script knows if another instance is already writing the menu and won't even start checking whether it needs to.

I had no personal preference either way really, just wanted to make sure it wasn't going to cause any issues with the way I had it Thanks for the reply.

Wow, thanks again for submitting the PR with the skinshortcuts changes, I can only imagine how much work that was! I looked at how you did the custom properties for the InfoLines and used that to add a property for the widget icon aspect ratio (see screenshot). It works as expected, I'm just wondering if there is a way to get rid of the "None" item and make Poster the default if the user hasn't selected anything?



Here's what I have in my overrides (haven't localized yet):


And here's how I'm setting it from script-skinshortcuts.xml:

You're very welcome. It's a good job I like a challenge (for the record, it took about five hours - I wanted to give up after 3 but I'm a stubborn old bugger ). And actually, it's one of those weird situations where if it hadn't been a challenge, I wouldn't have done it. I'm in the middle of re-writing the documentation, and was curious if there was anything I could learn from a quick attempt to switch Mimic over. Once I got started, I was determined to finish!

Not possible with the repo version of the script. The git version has some changes to custom properties where you can at least remove the 'None' option.


There's no option (though there is a feature request open for it) to set a default to all menu items, but a little bit of skilled skinning (IsEmpty(widgetIcon) | StringCompare(widgetIcon,...) should let you approximate that behaviour.

(2015-09-29, 01:49)BobCratchett Wrote: [ -> ]You're very welcome. It's a good job I like a challenge (for the record, it took about five hours - I wanted to give up after 3 but I'm a stubborn old bugger ). And actually, it's one of those weird situations where if it hadn't been a challenge, I wouldn't have done it. I'm in the middle of re-writing the documentation, and was curious if there was anything I could learn from a quick attempt to switch Mimic over. Once I got started, I was determined to finish!

Not possible with the repo version of the script. The git version has some changes to custom properties where you can at least remove the 'None' option.

Code:

<propertySettings property="[Property]" buttonID="[buttonID]" title="[Dialog title]" showNone="[True/False]" imageBrowse="[True/False]" />

[Property] - The property of the shortcut that will be set
[buttonID] - [Optional] The ID of the button that will be used to set this property. If ommitted, you must use the window property 'chooseProperty' and send a click to 404
[Dialog title] - [Optional] The title of the dialog that will be shown to the user
[True/False] - [Optional] A boolean indicating whether a None option will be shown, and whether the user will be able to browse for an image or folder of images

There's no option (though there is a feature request open for it) to set a default to all menu items, but a little bit of skilled skinning (IsEmpty(widgetIcon) | StringCompare(widgetIcon,...) should let you approximate that behaviour.

Got it working, thanks! Should have checked the docs first.

(2015-09-29, 01:49)BobCratchett Wrote: [ -> ]I'm in the middle of re-writing the documentation

Awesome..I have to admit this script is so powerful but almost impossible to understand all of the numerous permutations that can be achieved. Looking forward to seeing the new documentation

request, would it be possible to allow widget titles/names to be renamed on the home screen?

reason for the request...

I'm using addon PleXBMC and I'd really like to remove the fact it's a PleXBMC widget from the title.

ie. instead of widget title...

'PleXBMC - Recently Added' being displayed

I'd really like it to edit it to be 'Recently Added'

I have been advised that this should be a script.skinshortcuts request rather than a skin request. (thanks @Bobcratchett)

you have revolutionised my Kodi PleXBMC experience with this script... thanks for all your hard work, it is appreciated.

Thanks stueeey.

I'm happy to add this, but not sure what the best way to go about it would be. Any feedback would be appreciated:-

* Fix the titles. Easy enough to remove the add-on name from the widget title, and if there are any other titles that can be improved... (the other request I have seen for this involved playlists)
* Add a new GUI button to edit the title. Means skins that want to implement the feature would have to support an extra button, though...
* Add a keyboard pop-up when the widget is selected to edit the title. Useless for skins that don't display the title, and an extra step for users, though...

Can the keyboard pop up be autofilled with the default label for the widget? If so then we could just have a setting in overrides to enable this if the skin supports widget titles. The only action the user would have to do is hit ok again if they want to keep the title. This would prevent button bloat with minimal extra intrusion.

Sure it can My instinct, though, is it should be an override to disable it, rather than enable it, just because most skins I see do display the widget titles, and best to work for the majority...?

I don't wish to impose my requirements on every user or pretend I understand everything you guys have just said...

so reading between the lines and coming from a strictly widget creation from addon point of view... simply being able to change a widget name at creation would be just fine for me (think that may be what Jurielmunkey was proposing, maybe wrong?).

ie. I don't necessarily need it to be renamed intuitively...

I would imagine moving fwd users shall start creating widgets from all manner of addons with titles that are irrelevant or ridiculously long as a title. a simple way to change the widget title at creation would be very beneficial.