2014-06-24, 23:37
Any last issues do let me know, as I'd really like to try to get the request for an update on the repo in tomorrow, so I can finally take it easy for those few days I tried to last week 
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140
2014-06-25, 04:34
2014-06-25, 08:03
(2014-06-25, 04:34)Steveb Wrote: [ -> ]I seem to have found a issue with adding a playlist to the submenu, version="0.3.4". I've tried both skin & video playlists.
You have indeed. Fixed on git. Thanks for the bug report
2014-06-25, 12:06
(2014-06-24, 22:41)Unfledged Wrote: [ -> ]I had shelved it but, as you've asked, I've just pushed the code for item id's to git.Thanks for adding it, works fine for me.
Btw. in readme file in git repo is written that you will prefer include method over Gotham lists in future. Do you plan to add better some support for standalone (without relation to main menu) menus/list into include method part? Something like manage+list where you reference only group name without necessary link to mainmenuID like in buildxml. Same goes for Widgets, i would like to have possibility to access them independently from any menus/list, only by some widgetId or something like. Btw I'm using your script only for 2 days so please correct me if something written above is wrong
.2014-06-25, 12:35
(2014-06-25, 12:06)bambi73 Wrote: [ -> ](2014-06-24, 22:41)Unfledged Wrote: [ -> ]I had shelved it but, as you've asked, I've just pushed the code for item id's to git.Thanks for adding it, works fine for me.
Btw. in readme file in git repo is written that you will prefer include method over Gotham lists in future. Do you plan to add better some support for standalone (without relation to main menu) menus/list into include method part? Something like manage+list where you reference only group name without necessary link to mainmenuID like in buildxml. Same goes for Widgets, i would like to have possibility to access them independently from any menus/list, only by some widgetId or something like. Btw I'm using your script only for 2 days so please correct me if something written above is wrong
Support should already be there for standalone lists. You can manage any list you want by calling type=manage&group=[group].
Just throw in any old ID for the mainmenuID when building the main menu (that's an oversight that that's always required, but not a major one - seriously, use any random number for that property if you're not linking to a main menu), and list any groups you want built in the groups parameter, separated by a pipe (the | symbol).
Then you can include "skinshortcuts-group-[group] to just display that group without any visibility condition based on a main menu.
As a general rule, featurewise the includes method should be equal-or-better than the Gotham list filling method already, and is the prefered method to use
If there's something missing, though, do say! (And actually using it for both a main menu-based system, and a completely standalone menu won't work right now but should be easy enough to add)Not sure what you mean by widgets - the script just adds a widget property to menu items so that you as the skinner can display the relevant widget. Not sure how you'd access them independantly
Edit: Actually, building main menu and standalone menus is easy enough to add, and sensible enough, it's now on git - invoked by using mainmenu as the first group passed in the group parameter
group=mainmenu|mygroup1|mygroup2...
2014-06-25, 16:49
I'm currently using it same way how you described and have list completely unrelated to Home screen and its menu and it's working fine. But from generated include file and brief look into code I thought that mainmenuID is mandatory. If not then it's better for me .
About widgets, in my use-case I have custom Video hub window with list (filled by script) and up to 3 widgets. If I remember correctly (not at home now, so can't check it) widget property is filled to list items, but in my case I want to show same widget(s) aside from position in list. I can hardcode widgets to look for property at specific index but it'll make user configuration mess and can possibly cause problem with lists shorter than 3 items. I guess your approach is based on mainmenu + 1 widget per menu on Home screen point of view where it's logical, but it's bit limiting for other use-cases. My idea was to have possibility to save widget properties directly to Home window like script.skinshortcuts.[widgetID].widget or something similar. But maybe I'm over thinking things and there is some easy solution already available
.About widgets, in my use-case I have custom Video hub window with list (filled by script) and up to 3 widgets. If I remember correctly (not at home now, so can't check it) widget property is filled to list items, but in my case I want to show same widget(s) aside from position in list. I can hardcode widgets to look for property at specific index but it'll make user configuration mess and can possibly cause problem with lists shorter than 3 items. I guess your approach is based on mainmenu + 1 widget per menu on Home screen point of view where it's logical, but it's bit limiting for other use-cases. My idea was to have possibility to save widget properties directly to Home window like script.skinshortcuts.[widgetID].widget or something similar. But maybe I'm over thinking things and there is some easy solution already available
2014-06-25, 17:39
The code for widgets (and backgrounds) is designed only with the script providing menus in mind. In your situation, it sounds like the widgets aren't something you want to link to the items returned by the script at all, so the script isn't the place to be managing them There's lots of examples in lots of skins on using a custom window to set a skin string to manage things such as widgets.
There's lots of examples in lots of skins on using a custom window to set a skin string to manage things such as widgets.2014-06-25, 18:13
That's one thing I thought about myself actually - the ability to use this script for selecting a single custom shortcut as it would a much more efficient way to do to it.
ie Pass a parameter when running the script (eg shortcut1) and let the user choose it's type, name, etc and the script produces the relevant include file.
A lot easier than coding custom shortcuts.
ie Pass a parameter when running the script (eg shortcut1) and let the user choose it's type, name, etc and the script produces the relevant include file.
A lot easier than coding custom shortcuts.
2014-06-25, 18:17
There's the Just Select method - though I'm probably misunderstanding what you mean:
(where the properties are all optional skin strings to be set.) Doesn't create the includes file, though, it just passes the shortcut off to the skin to manage. (Reading back, I'm guessing I am misunderstanding)
PHP Code:
RunScript(script.skinshortcuts,type=shortcuts&custom=[True/False]&skinLabel=[skinLabel]&skinAction=[skinAction]&skinType=[skinType]&skinThumbnail=[skinThumbnail])
(where the properties are all optional skin strings to be set.) Doesn't create the includes file, though, it just passes the shortcut off to the skin to manage. (Reading back, I'm guessing I am misunderstanding
)2014-06-25, 18:28
2014-06-25, 18:37
2014-06-25, 18:49
Sorry, need to read the manual again. 
2014-06-25, 18:50
One of these days I'll spend some time making the doc's actually understandable
2014-06-26, 21:35
My idea was to let user have same configuration possibilities for all custom elements (lists, widgets, maybe backgrounds too) regardless where they are placed in skin. I already thought about workaround how to use shortcuts in my use-case so I only asked for change because it would make my situation much easier .
.2014-06-26, 22:05
If it was a simple code change, I'd be happy to do it. But it'd require re-writing the widget (and maybe backgrounds too ) code, including changing where the code is within the script. Too much work for something which still feels like its better handled skin-side.
You did say previously, though, that you'd looked at the code. If you want to try and re-write the widget code and send a pull request, it'd be very welcome (and I can provide pointers as to what changes would be needed.)
) code, including changing where the code is within the script. Too much work for something which still feels like its better handled skin-side.You did say previously, though, that you'd looked at the code. If you want to try and re-write the widget code and send a pull request, it'd be very welcome (and I can provide pointers as to what changes would be needed.)
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140