Kodi Community Forum
Release script.skinshortcuts - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Skinning (https://forum.kodi.tv/forumdisplay.php?fid=12)
+---- Forum: Skin helper addons (https://forum.kodi.tv/forumdisplay.php?fid=300)
+---- Thread: Release script.skinshortcuts (/showthread.php?tid=178294)



RE: script.skinshortcuts - guido1138 - 2016-01-12

(2015-11-30, 01:06)Talguy Wrote:
(2015-11-23, 22:05)BobCratchett Wrote: 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.
Hi BobCratchett,
I found your post as I was trying to use both jurialmunkey's Eminence 2.0 and hitcher's fTV skins. I did have to fix some conflicts in Ignoble61's branch vs. master, but found that the "don't share menus between skins" feature works well.

Since script.skinshortcuts usage is becoming so common among skins now, this "don't share menus" feature seems almost a necessity these days. I'm wondering if you've received enough feedback yet. Could it be included in mainline?

Many thanks!


RE: script.skinshortcuts - BobCratchett - 2016-01-12

You're only the second person to feedback on it, but at least 100% of the feedback is positive Smile

My current plan is to pull it into my UX branch at some point (where I've been trying out various changes aimed at end users), then get that branch into shape for a PR. I'm busy with other projects at the moment though, so that won't happen straight away.

If you really like the feature and you've already solved the merge conflicts, you're welcome to make the PR yourself (bearing in mind the feature also requires some changes to the backup feature of marcelveldts Skin Helper Service).


RE: script.skinshortcuts - User 224999 - 2016-01-13

(2016-01-09, 04:27)BobCratchett Wrote: Having said all of that, there's already a bug fix for Isengard on Master. @marcelveldt, how do you feel about doing a fairly swift repo update to get that fix out there, coincidentally getting this template improvement out at the same time...?

Sorry, missed your post and a little late with my answer but there should be no issue in a new repo push.


RE: script.skinshortcuts - BobCratchett - 2016-01-13

Nothing you need to be sorry about Smile If I do an update to mark stable/create a tag (and I've got a note to myself here to remove xbmc.sleep() which should be a really quick job), are you happy to make the update request?


RE: script.skinshortcuts - sualfred - 2016-01-13

I was playing with the new 312 widget select dialog and lucky to have an custom widget name option. But this custom name is an unique property of the assigned menu item, not of the widget itself.
It would be helpful to have a override option to get this custom label directly in 312 as label2 for each predefined widget, independently of the main menu. Any chance to get this in the future?


RE: script.skinshortcuts - BobCratchett - 2016-01-13

There's already the option to use the widget name as the label for the assigned menu item (though it doesn't look like its documented):-

Code:
<button id="[custom id]>
    <onclick>SetProperty(useWidgetNameAsLabel,true)</onclick>
    <onclick>SendClick(312)</onclick>
</button>

Should be easy enough to extend that to label2, once the upcoming repo push is done.


RE: script.skinshortcuts - sualfred - 2016-01-13

Thanks, that's working but it's not what I meant Smile The main menu properties and items should be completely untouched.

Example:
- Default widget label: "Widget Group #1"
- Widget label set to "My Movies" after the 312 dialog
- Re-opening 312 -> The label is still "Widget Group #1"


RE: script.skinshortcuts - BobCratchett - 2016-01-13

I'm sorry I don't understand Blush Please don't be afraid to go into excruciating step-by-step detail of what you want to achieve - it's often the only way I get my head around these things Smile

(However, 312 always will change the main menu properties - the whole premise of it is to add the various widgetProperties to the main menu item...)


RE: script.skinshortcuts - sualfred - 2016-01-13

Sometimes I wish EN would be my mother language Tongue

More detailed example:
- I just use a predfined set of Widget Groups in overrides with "Widget Group 1", "Widget Group 2" ,...
- The user choose a Widget Group by 312
- The user changes the name to "My Movies" and adds some content to it by an custom dialog with the Just Select method
- The user wants to add this predefined Widget Group to another main menu item but doesn't remember which of the "Widget Group %i" he used and has to open each of them again because in 312 all of them are labeled by the label of the overrides files instead of the set custom label.

Got it? Tongue


RE: script.skinshortcuts - BobCratchett - 2016-01-13

Yep, got it - you want the users new name to override the name given in the widgetGroupings. No, that's not possible - the users choice of name just affects the widgetLabel property of the main menu item. And to be honest, I'm not even sure if its doable - if it is then it will be by setting the labels in the widgetGrouping to Skin.String's, and using Skin.SetString's to edit the labels...

(By the way, if you're not using 312 to set individual widgets but just to set to a group, it may be easier to do what you want via custom properties...)


RE: script.skinshortcuts - sualfred - 2016-01-13

Yep. That's how I do it atm. Got it working by using a custom select dialog to choose the widgets (customProperty -> 404). It has exactly the behaviour how I want it, but it makes it more complicated to add more widgets for this.

Nevertheless, I'm fine with the custom properties method Smile


RE: script.skinshortcuts - Mr. V - 2016-01-14

In a bit of a thinking mood regarding the templates.

As far as I understand skin shortcuts will write to the script-skinshortcuts-includes.xml like this;
Code:
<include name="skinshortcuts-template-widgetPanel2">
      ....stuff here
</include>

Could it be possible with some simple code changes to write to the xml like this?
Code:
<variable name="HomeWidgetArt">
      ....stuff here
</variable>

I am thinking about the insane amount of variables in madnox (even more after adding the mixed widget). Being around 4 variables for each image, label ect with the only difference being the container number.

If I could use a variable within the template I can then use $PARAM[Id]. Each and every widget would then have a unique id, it would greatly reduce the variables and animations between menu items would be much smoother. Just a hunch on the reported disappearing widget issue, I am suspecting it could be related to using the same panel id. (i cant replicate the issue though myself). I must say though along the road of coding the widgets the same panel id between menu items has caused many coding headaches and i have had to find ways around the issue.

EDIT: Not sure if this a viable idea though as this would certainly add a lot more string compares and bloat the code in the script-skinshortcuts-includes.xml if there were many widgets setup. I have been trying to figure out how to have separate panel ids for each widget for a while now and thinking it may not be possible.


RE: script.skinshortcuts - BobCratchett - 2016-01-14

It's an intriguing idea. It should just be a case of adding a modified version of the 'getInclude' method in template.py which gets a variable instead, and a way to determine which method should be called. I'll have a play with the code and see what can be done, though this probably won't be until next week now.


RE: script.skinshortcuts - Mr. V - 2016-01-14

(2016-01-14, 10:02)BobCratchett Wrote: It's an intriguing idea. It should just be a case of adding a modified version of the 'getInclude' method in template.py which gets a variable instead, and a way to determine which method should be called. I'll have a play with the code and see what can be done, though this probably won't be until next week now.

Thanks for considering this Bob. Smile No rush.

More thoughts after a good night sleep. Maybe have a new xml such as script-skinshortcuts-variables.xml. Then all the skinner needs to do is add it to includes.xml.


RE: script.skinshortcuts - Jayz2K - 2016-01-14

Mr. V Wrote:If I could use a variable within the template I can then use $PARAM[Id]. Each and every widget would then have a unique id, it would greatly reduce the variables and animations between menu items would be much smoother. Just a hunch on the reported disappearing widget issue, I am suspecting it could be related to using the same panel id. (i cant replicate the issue though myself). I must say though along the road of coding the widgets the same panel id between menu items has caused many coding headaches and i have had to find ways around the issue.

Do you just need to separate panels ID's or do you also need to add variables ?

If you need both, it's something I tried with including $PARM[ID] in variables values but doesn't work, so I used cascading $PARAMs.

And, you're right, the disappearing panel is because of the shared ID ...