Widgets select
Closed this issue · 53 comments
I've tested the latest commit and everything seems to working fine except one thing. I use this
<label2>$INFO[Container(211).ListItem.Property(widgetName)]</label2> in 312 button to show the name of the current selected widget. After the latest commits (i don't know when but it was after 0.5.1 BETA) the widget name has a $INFO prefix in front.
Example...
Widget name: Popular Movies
now it shows: $SKIN[31251]|skin.bello|Popular Movies (31251 is my skin string for "Popular Movies")
This is happening only with the skin strings. Kodi and script's strings are working fine. I remember i've read somewhere in the documentation that skin strings should have a ::LOCAL:: prefix but until now they were working fine without that.
I have also some requests if i may. We really need to find a way to determine the kind of "Sources" widgets. I mean when user selects a Source as a widget there is no way that the skin to know what kind of source is that (movies, tvshows, music etc) so to display the proper thumbs and info. Is it possible to add some question to the user about the type of the source content and then set that as widgetType ?. That will make things more easy to handle. If there is no way to determine (and add a property about that) the source type then i will remove them from my widgets list since there is no point to have them and not to be able to display them properly.
One last thing. Is possible to break the the library nodes in additional nodes ?.
What i mean is this... This will show all the Video Library nodes:
<node label="32030">
<content>video</content>
</node>
Now, is it possible to break this in additional nodes like this ?:
<node label="32030">
<content>movie</content>
<content>tvshow</content>
<content>files</content>
.
.
</node>
I've try the above code but is not working. This could help to group very well the library nodes widgets and the skin widgets.
EDIT: I forgot about this and i have no idea if is old but i just notice it. If you try to override the PVR Guide icon with the Kodi 22020 string you will end up with the DefaultAddon icon...
<icon labelID="22020">special://skin/extras/icons/Guide.png</icon>
Cheers
Nessus
How did you specify your widget's name in your overrides.xml ? It is enough to just set the numeric ID of the language string. No need to add $LOCALIZE[], so for example:
<widget label="31196" condition="true">popular movies</widget>should suffice.
Break up the library in additional/seperate nodes is not possible because of the simple fact that the user can customize the video nodes. That way you have no way to determine if there actually is a movies node etc.Oh well, it is possible by looping through all video nodes and determine the content but that's a lot overkill and will cause slower load times besides the fact that the proper content matching could be wrong. I hope you understand what I mean. If you really want it to be seperated you could code the nodes manually in your overrides offcourse..
I will take a quick look at the icon override for the PVR guide. You're sure that is the correct label ID ?
BTW: thanks for testing the latest Git version. Both me and @Ignoble61 are very curious if everything is working properly after so many code changes ;-)
If all is well things can be pushed to the repo soon.
How did you specify your widget's name in your overrides.xml ? It is enough to just set the numeric ID of the language string. No need to add $LOCALIZE[], so for example:
<widget label="31196" condition="true">popular movies</widget>
I use the <shortcut /> way in my widgets so to group them in nodes. This is the code that i use for the "Popular Movies"...
<shortcut label="31251" widget="PopularMovies" icon="DefaultMovies.png" widgetType="movies_online" condition="System.HasAddon(script.extendedinfo)">plugin://script.extendedinfo?info=popularmovies</shortcut>
About the separate nodes i knew that it will be difficult but i had to ask. I guess will have to do them all manually. Will see, thanks.
One more thing that i notice lately. If you assign as widget the "Recently Added Movies" or "Recently Added Episodes" from the video library nodes the list shows all the items watched and un-watched even if the un-watched toggle button is switched in MyVideoNav window. Is that a normal behavior ?
You're sure that is the correct label ID ?
I am sure... https://github.com/xbmc/xbmc/blob/5737b0c299400a285f33dfb4db964aea688ab1f2/addons/resource.language.en_gb/resources/strings.po#L12181
Also if you try to override the other two same strings (#19069 and #19222) then you get script's DefaultLiveTV icon.
One more... Is this property working: <property name="hasSubmenu">True</property> ?.
I am trying to use this as a condition to show some widgets if a main menu item has submenu but either "True" or "False" is not working...
StringCompare(Container(20).ListItem.Property(hasSubmenu),True)
One more, important one...
The "Movies", "TV Shows" and "Music Videos" video library nodes widgets they are not working in Greek language. When i try to go inside in one of those three folders the widgets select dialog closes without any script errors and i am back to management dialog. I've tested also with Italian and French but with those was working fine. It happens only in Greek (or in some other lang that i can't test it.)
Let me know if you need a full debug log.
EDIT: I don't know if matters but this one was tested under Isengard 15.1 although i didn't test it with 15.0.
I've tested the latest commit and everything seems to working fine except one thing. I use this
$INFO[Container(211).ListItem.Property(widgetName)] in 312 button to show the name of the current selected widget. After the latest commits (i don't know when but it was after 0.5.1 BETA) the widget name has a $INFO prefix in front.
Fixed in #53, and thanks for the bug report
The "Movies", "TV Shows" and "Music Videos" video library nodes widgets they are not working in Greek language
Fixed in #53, and thanks for the bug report
have also some requests if i may. We really need to find a way to determine the kind of "Sources" widgets. I mean when user selects a Source as a widget there is no way that the skin to know what kind of source is that (movies, tvshows, music etc) so to display the proper thumbs and info. Is it possible to add some question to the user about the type of the source content and then set that as widgetType ?. That will make things more easy to handle. If there is no way to determine (and add a property about that) the source type then i will remove them from my widgets list since there is no point to have them and not to be able to display them properly.
Personally I'd rather not start asking the user lots of additional questions, but I'm happy to be overriden on this. Alternatives are to set it as an additional property yourself, or remove the sources from the widget groupings.
EDIT: I forgot about this and i have no idea if is old but i just notice it. If you try to override the PVR Guide icon with the Kodi 22020 string you will end up with the DefaultAddon icon...
special://skin/extras/icons/Guide.png
I'll look into these icon issues this weekend if no-one beats me to it, but one thing to check is that you don't have other icon overrides which may be conflicting.
One more thing that i notice lately. If you assign as widget the "Recently Added Movies" or "Recently Added Episodes" from the video library nodes the list shows all the items watched and un-watched even if the un-watched toggle button is switched in MyVideoNav window. Is that a normal behavior ?
Probably, but that's entirely down to Kodi.
One more... Is this property working: True ?.
You tell us :) Is it being set properly in your script-skinshortcuts-includes.xml file?
BTW: thanks for testing the latest Git version. Both me and @Ignoble61 are very curious if everything is working properly after so many code changes ;-)
👍
Personally I'd rather not start asking the user lots of additional questions, but I'm happy to be overriden on this. Alternatives are to set it as an additional property yourself, or remove the sources from the widget groupings.
I agree with you about not asking users questions logic, but this issue cannot be resolved in any other way. "Sources" are users own files. There is no way that the skin can determine what kind/type of files are so to display them in a properly manner. Only the user can know that. Plus that this will eliminate the need for the users to create smart playlists just to point them to a specific folder (something that users ask often how can they do it).
It's up to you to decide how and if we should this. Me i am just asking so to know if i will keep the sources in widgets list. I have no problem with whatever you decide.
but one thing to check is that you don't have other icon overrides which may be conflicting.
I've already checked. That string it's used only there.
Probably, but that's entirely down to Kodi.
Kodi shows/hide un-watched items with a button (id=10) in MyVideoNav.xml file. Shouldn't this be taken under consideration by the script ?. I have no idea if what i am asking is dumb, just thinking out loud here.
You tell us :) Is it being set properly in your script-skinshortcuts-includes.xml file?
Both of them (True/False) they are set fine depending if the item has a submenu. The issue is that using any of them as a condition doesn't make any difference.
One last thing that i need ask is about the MusicVideos. When you choose MusicVideos as a widget from the MusicLibrary nodes (not from VideoLibrary nodes) the widgetTarget property is set to music. IMHO this is wrong and causes a little mess in music views if you go inside to music library from an item of that widget, since the MusicVideos path is videodb:// not musicdb://.
Am i wrong here ?
It's up to you to decide how and if we should this. Me i am just asking so to know if i will keep the sources in widgets list. I have no problem with whatever you decide.
Actually it's up to anyone who wants to code it :)
Kodi shows/hide un-watched items with a button (id=10) in MyVideoNav.xml file. Shouldn't this be taken under consideration by the script ?. I have no idea if what i am asking is dumb, just thinking out loud here
The script isn't actually providing the items in the list, though. It's just giving you something you can pass to Kodi in a <content> tag. It's up to Kodi to fill it, and to decide whether to show watched/unwatched within it.
Both of them (True/False) they are set fine depending if the item has a submenu. The issue is that using any of them as a condition doesn't make any difference.
It's not really designed to be, it's used internally by the script for helping out with single-list menu implementations. Indeed, to quote the docs...
Note, there is an additional property - Property(hasSubmenu) - which is used by the methods used for building all menus in a single list. It should not be relied upon to determine whether there are any visible items in a submenu, as it will still return True if all items within the submenu are invisible. Suggestion is to use Container.NumItems to determine this information instead.
But as long as its being set correctly, the script is doing its job :)
IMHO this is wrong and causes a little mess in music views if you go inside to music library from an item of that widget, since the MusicVideos path is videodb:// not musicdb://.
Am i wrong here ?
I don't have any music videos on any system here to test with, but when you access them through the music library (rather than through the widget), is the path still videodb://...?
Actually it's up to anyone who wants to code it :)
No problem then. I will remove the sources until then. Thanks
The script isn't actually providing the items in the list, though. It's just giving you something you can pass to Kodi in a tag. It's up to Kodi to fill it, and to decide whether to show watched/unwatched within it.
Then this is odd. Inside the video library it shows only the un-watched Recently Added items but in home widget it shows all the items and in both the path is the same videodb://recentlyaddedmovies/. If this is Kodi thing then i will have to keep my library data provider widgets.
It's not really designed to be, it's used internally by the script for helping out with single-list menu implementations. Indeed, to quote the docs...
I dint notice that part in the documentation... sorry. I am using the new templates way to build the subemnus. Is there any other way to check if a main menu item has a submenu ?. Container.NumItems will not work for me since the Container always has the same id and i want to use this visible condition in overrides.xml. This will do the job... <skinshortcuts>visibility</skinshortcuts> but i guess this is only for the templates.xml... right ?
I don't have any music videos on any system here to test with, but when you access them through the music library (rather than through the widget), is the path still videodb://...?
Yes. If you click in any MusicVideos item (either from video or music library) the path starts the same... videodb://. Only the root it starts with library:// and is different depending from where you open it...
VideoLibrary: library://video/musicvideos/
MusicLibrary: library://music/musicvideos/
I dint notice that part in the documentation... sorry. I am using the new templates way to build the subemnus. Is there any other way to check if a main menu item has a submenu ?. Container.NumItems will not work for me since the Container always has the same id and i want to use this visible condition in overrides.xml. This will do the job... visibility but i guess this is only for the templates.xml... right ?
No need to apologise, though I'm sorry there's no other way to do it (that I know about). BTW, <skinshortcuts>visibility</skinshortcuts> (which is template only) just gets replaced with the necessary visible tag to show the control at the right time - such as <visible>StringCompare(Container(9000).ListItem.Property(submenuVisibility),genres)</visible> - not something that could be used in an override.
Yes. If you click in any MusicVideos item (either from video or music library) the path starts the same...
In which case the script is doing things the same way as Kodi does it, so for me it's correct as-is.
In which case the script is doing things the same way as Kodi does it, so for me it's correct as-is.
You are right. I just realize that Kodi also does this in the wrong way. Opening videodb:// path inside the Music Library window IMO is completely wrong (and of course, again, skinner has to find a way to make all this to look properly !). So yes, the script is doing things the same way as Kodi does it.
No need to apologise, though I'm sorry there's no other way to do it (that I know about)
So, there is no way to know if a submenu it exists ?
BTW,
<skinshortcuts>visibility</skinshortcuts>(which is template only) just gets replaced with the necessary visible tag to show the control at the right time - such as<visible>StringCompare(Container(9000).ListItem.Property(submenuVisibility),genres)</visible>
What do you mean with this ?. Should i replace the <skinshortcuts>visibility</skinshortcuts> with string compares in templates.xml ?
So, there is no way to know if a submenu it exists ?
Not unless you can get your StringCompare working - just be aware that's not what the hasSubmenu property is designed for and may not be an accurate way to determine whether theres actually a submenu to display (if the items within it are all invisible). The script can't really provide this information as it can't determine when the menu is built what items will be visible/not be visible at any given time in the future.
What do you mean with this ?. Should i replace the visibility with string compares in templates.xml ?
No, no. Keep using the <skinshortcuts>visibility</skinshortcuts> - I was just pointing out what the script replaces those with when the menu is built.
@Nessus85100 To know whether a submenu is visible you can use IntegerGreaterThan(Container(xxx).Numitems,0)
@phil65 Thanks but that wont help because all submenus are under the same id.
@Ignoble61 Do you remember the <checkforshortcut /> tag that you added so to check if a main menu item is available ?. Do you think that we can do something similar for the subemenus also ?
From what I remember of <checkforshortcut /> it should check whether that shortcut appears within any menu the script builds - main, sub or additional. Are you wanting it to check if a shortcut specifically appears in a submenu?
Sort of. Can we check if the first item (<item id="1">) in include of each subemenu exists so to know if the submenu itself exists ?. I mean all my submenus are under container with id=23. So if the ... Container(23).ListItem(1).Label is empty (or is not visible ?) then the subemenu is empty (or is not visible ?). I've tried that as a condition in my overrides.xml widgets that i want to hide but it's not working. Maybe the script can make it work like the <checkforshortcut /> thing ...?... just thinking out loud here !.
The script can only check for things at build time - whether the item is present can be checked for, not whether it is visible as visibility can change at any time afterwards. Not sure why checking whether Container(23).ListItem(1).Label is empty is a better check (and will work when the following won't) than Container(23).NumItems...
Edit: whilst 'runtime'-esque things (such as checking whether a submenu has any visible items) aren't possible script-side with how Skin Shortcuts works. However, one of the things I have very broadly planned is a skinshortcuts.helper add-on which /might/ make this possible eventually. My primary idea at the moment is a context menu entry point so that menu items can be added/removed from the menu whilst using Kodi normally. Now, if this was implemented as a service (which actually isn't my ideal implementation - indeed, it may end up just being an extension to the current script though I like the idea of pulling some functionality out if for no other reason than not to bloat the current script any more - but you never know how it will end up having to be implemented in order to get the visibility of an "Add to home screen" and "Remove from home screen" context menu items correct) then such things could be done as the add-on would have to know what menu items the user has. Alternatively, depending how @marcelveldt feels about it, his skin helper service might be a good candidate for providing such extensions. Such things are for looking at after we're all happy the recent additions to skin shortcuts are all working correctly.
Now it's my turn to think out loud ... I wonder if what you want could be done with an extension to templates (though again, such things are for looking at after we're all happy with the recent additions). At present the main menu template is pretty much useless, included in code for completeness sake only. But as we know all the submenu items visibility conditions at build time (actually we don't when the main menu template is built at present, but it's a relatively minor change to fix that), it may be possible to include those visibilities into the main menu template. Something, very broadly, like the following:-
<layout>
<control type="group">
<skinshortcuts>hassubmenu</skinshortcuts>
<controls...
</control>
<control type="group">
<skinshortcuts>nosubmenu</skinshortcuts>
<controls...
</control>
</layout>
Where hassubmenu/nosubmenu get replaced with a <visible /> element with the submenu items visibility within it, so the correct group gets shown by Kodi dependant on whether there are submenu items or not taking into account the visibility conditions of any items within.
Realised this wouldn't work. sorry,
Solved it :) (I think!)
@Nessus85100 can you please try https://github.com/Ignoble61/script.skinshortcuts/tree/build-rewrite
This adds a new property - submenuCondition - to main menu items which you can use as the visibility condition for deciding what to display based on whether there's a submenu, taking into account the visibility conditions of any items within it. Within the list that is displaying the menu itself (the only way I've tested it), usage is <visible>ListItem.Property(submenuCondition)</visible> for what should be visible when there's submenu items, and !ListItem.Property(submenuCondition) for what needs to be visible when there isn't. (Container(x).ListItem.Property(submenuCondition) /should/ also work outside of the mainmenu list control!)
Sorry, but is not working (damn !!!). I want to use this in overrides.xml, so the Container(20).ListItem.Property(submenuCondition) is not working ("20" is my mainmenu id). The submenuCondition property is there in script-skinshortcuts-includes.xml ("true" if the item has subemenu, false if is not) but it makes no difference as a condition in overrides.xml. I've also tried... StringCompare(Container(20).ListItem.Property(submenuCondition),true) and SubString(Container(20).ListItem.Property(submenuCondition),true) with no luck.
I don't know if this matters but keep in mind that i am using templates only for subemenus and widgets. Not for the main menu.
Thanks for keep looking on this
Nessus
I think I'm getting myself confused over what you're wanting to do here - can you give me a copy of your overrides.xml as you would like to use it, so I can have a play and see if I can get it working :) (It'll probably be the weekend now before I can look, though...)
I've just send you all my shortcuts files in this mail...
Thanks
Nessus
Received thanks. Where in the overrides.xml is the example of where you're wanting to check for submenu?
It's the <node label="31209"> in <widget-groupings>
Ah, I think I understand what you're wanting - for your 'submenu' widget to only be visible in the widget selection dialog if the main menu item actually has a submenu...?
If I'm understanding correctly then this isn't possible. The management dialog has no understanding whether you're looking at a main menu, a submenu or an additional menu. Nor does it have any knowledge of what items are in any other menu. And this can't change without a major re-write of the management dialog.
Also, it probably wouldn't lead to a great UX if you \could\ hide those widgets if there are no submenu items - you'd be left with a widget that you can't select if you deleted all the submenu items, and there's no way to deal with whether the submenu items are visible or not, as we've no idea what their visibility will be when the user actually uses the main menu later on.
Ah, I think I understand what you're wanting - for your 'submenu' widget to only be visible in the widget selection dialog if the main menu item actually has a submenu...?
That's correct.
I could add a long visible condition in the <node /> if the user has deleted all the submenus so the entire node will be hidden. I use some of these submenus widgets for a couple weeks now and i find them very handy and useful plus it's a very easy way for custom widgets. It's a petty that we can check which of them are exists so to hide the non existing ones. I think i will let them there even if some of them will be visible but empty.
Is it possible to add this functionality to the script by default ?. I mean let the skinner the option by putting a line of code in overrides.xml to add all existing subemenus as widgets and the script will check internally which ones will be visible ?... Perhaps with the templates way ?... Thinking out loud again 😁
EDIT: By the way the submenuCondition property it will be useful for many other things so IMO we should keep it.
Can't change anything in the the widget selection dialog without major changes to the management dialog code. Within home.xml/your widget template, you can choose whether to actually \display\ the widget by checking the numitems of the submenu list (see examples earlier in thread - useful for just the currently selected main menu item) or with the code in the branch I linked to last night (useful if you want to change how the main menu item itself looks, whether or not it's actually the selected item - assuming that branch works as intended). But that's all skin xml side :)
To automatically set all main menu items widget to be the submenu widget (when the user first uses your skin/resets the menu items), look at widgetDefault or widgetNodeDefault in your overrides.xml.
or with the code in the branch I linked to last night (useful if you want to change how the main menu item itself looks, whether or not it's actually the selected item - assuming that branch works as intended).
That's what i said in my EDIT. We should merge that branch to master since that property (submenuCondition) could be useful for some other things like showing/or not an indicator if the item has submenu for skins that have the submenus hidden.
To automatically set all main menu items widget to be the submenu widget (when the user first uses your skin/resets the menu items), look at
widgetDefaultorwidgetNodeDefaultin your overrides.xml.
I am not saying that (and that's my fault and my poor English...sorry). I don't want to set any default widgets on first use or reset. I am talking about a native support where a skinner will be able to put a line of code in his overrides.xml that will make all the exisiting subemenus to be available as widgets in the widget selection dialog. I have no idea if this is possible or a lot of work to do it but like i say... thinking out loud here.
Sorry for my poor English and I hope now i am more clear about this.
We should merge that branch to master since that property (submenuCondition) could be useful for some other things like showing/or not an indicator if the item has submenu.
I need to do some more testing to see that it works properly - if it does (all my own menu items the value gets set to either true or false - it needs to be confirmed working properly with the more complex values that it could get set to) then I will definitely get it merged :)
I am not saying that (and that's my fault and my poor English...sorry). I don't want to set any default widgets on first use or reset. I am talking about a native support where a skinner will be able to put a line of code in his overrides.xml that will make all the exisiting subemenus to be available as widgets in the widget selection dialog
And let me apologise if my understanding isn't great at the moment - I volunteer with a special-needs-children charity's playscheme for one week each year and, after the last day (today) I'm always exhausted and slightly stressed. So if I don't understand fully or am a little short, please accept my apologies :)
I understand what you mean now. It should be entirely possible to have an option for a 'submenu' widget to appear automagically (via an enabling override, as obviously we don't want to force skinners to support this if they don't want to - indeed, the obvious implementation to me would be another <content /> in the skins overrides.xml <widget-groupings />) in the widget select dialog. What information would it be useful for it to provide, or is it enough that the user has selected a generic 'submenu' widget? (i.e. does it need to specify it's a 'movie' submenu widget for example, or any other identifying feature. And, if so, which of the 5 properties the widgets return - widget, widgetName, widgetType, widgetPath, widgetTarget - should that identifying info be returned in?)
I agree that another <content /> just for the subemenus will be the best choice. IMO the best way of what info should be available is to base this on the skin's DATA.xml files. I mean, get what submenus are set by default in the skin from DATA.xml files and use the info from those files (label, icon action etc) to create widgets which they will be available in the widget selection dialog if the skinner has added the <content /> widget node in overrides.xml.
Perhaps another tag in DATA.xml files like true will do the job ?
Still not sure how individual submenu widgets will be identified :)
widget - "submenu"?
widgetName - the name of the submenu?
widgetType - set via the overrides?/empty?
widgetPath - empty?
widgetTarget - empty?
Those seem to be the obvious values that would be returned for me. Now, if there was a single 'submenu' widget for every main menu item, then that's fine. But if there are separate submenu widgets for each main menu item - as you currently have in your overrides (and one issue that will crop up is what happens when a main menu item gets deleted, but a widget for that main menu item still exists) I'm not sure how you would identify (with just the 5 properties that are returned, and with automagically generated values, as widgetName probably can't be used - its for displaying to the user, and actually may not relate in any way to the 'internal' values of the main menu item) how the skinner is going to identify which one the user has selected? :)
What values do you want to see returned for those 5 properties?
Edit: I know I said I couldn't see any issue adding this - having thought about it a bit I can see one... The available shortcuts are loaded by library.py, which itself has no knowledge of what shortcuts are loaded in the management dialog (gui.py). To do this, and to keep code in the correct module, would require some thought about passing information between the two meaning this won't be something that can be added super-quickly in a good way. It's still very do-able, it just might take a little time.)
I think these will do...
widget = "submenu" (for use to assign the proper list layout)
widgetName = the name of the submenu
widgetPath = should this be the path of the selected subemenu (eg skinshortcuts-group-movies)
widgetType and widgetTarget IMO are not needed and can be empty.
(and one issue that will crop up is what happens when a main menu item gets deleted, but a widget for that main menu item still exists)
I was hoping that the script could check that and hide that spesific non-existing subemenu from the management dialog widgets list.
how the skinner is going to identify which one the user has selected?
I am not sure what you mean with this. Can you please explain little more ?
I was hoping that the script could check that and hide that spesific non-existing subemenu from the management dialog widgets list.
It can indeed hide them (actually, if it's auto-generating them, they won't even be created let alone need to be hidden - though the issue still exists that the management dialog will have no idea if there are actually any visible items within the submenu!).
I meant that once the user has selected a submenu widget, but then deletes the main menu item the widget refers to - e.g. (and I know it's an unlikely scenario, but one thing I've learnt is that users will do anything, especially if we don't expect them to!) the user has selected the 'Live TV' submenu widget for the 'Pictures' main menu item. They then delete the 'Live TV' main menu item (and so its submenu) - in this scenario, the 'Pictures' widget would still be the (now non-existant) 'Live TV' submenu.
One potential solution to this could be to only show the submenu widget for the main menu item that is selected. Though this is something that needs more thinking about :)
I am not sure what you mean with this. Can you please explain little more ?
The issue is as simple as taking the values that are returned, and having enough information to be able to accurately display the correct information on the skin .xml side - so (assuming templates) the correct template, and the correct content within that template.
If the widgetPath is, as you suggest, the path of the selected submenu this may not be an issue. At some point, though, there has to be a value that the skinner can use to decide whether or not to display the widget, and which widget (and, with templates, which content within the widget) is being displayed. With templates, the first isn't an issue - <skinshortcuts>visibility</skinshortcuts> will handle that.
The second is potentially more difficult - you have to actually choose which submenu's content you want to display. With the way you suggest, you can simply <include /> the path (or, with a template, $INCLUDE[]). Sounds like you've come up with a good solution (though I don't look forward to writing the docs to explain it to everyone who hasn't followed this thread ;))
This is something I'll probably look into implementing Sunday/early next week :)
This is something I'll probably look into implementing Sunday/early next week
Ok then. I will wait for a test branch. Since you know now what needs to be done i think the best way to do this is to have something that we can test and then we can move forward and solve any issues thru the testing.
If you need anything else from me, just ping.
Thanks again for taking the time to do this.
Cheers
Nessus
@Nessus85100 I've spent some time thinking this through and having a quick play with the code.
What's easily possible, and I can provide a test branch shortly if this is useful to you, is a single 'Submenu' widget which, when its value is used within a template as the <content /> tag, will be replaced by an include of the relevant skinshortcuts-group-[name] for the submenu of the main menu item the widget has been selected for. (Though it won't be ready to merge straightaway as I haven't thought through the behaviour in the traditional implementation as opposed to templates.)
What isn't easily possible is providing what you are currently trying in your overrides.xml, whereby the user can select any submenu as the widget for any main menu item. The big difficulty here, though by no means the only, is that at the time the widgets are selected we don't know what the labelID will be - this gets set whenever the menu is saved, and if menu items are changed around for example can change. We also can't rely on the defaultID as that is set for new menu items when the item is saved, so won't necessarily be available when the widget is set. (There are several other issues introduced when main menu items are changed/deleted)
Without something like this it's damn near impossible (without significant code changes) to be able to do this in a way that will work consistently. If it's a feature you really want it's something I'll look into, but I don't want to make major changes to the code (with a good chance of introducing breakages) whilst the script is in a beta stage. Once its been declared stable, such changes can begin to be looked into :)
First of all thank yo very much for taking the time to look at this. Secondly, this is by no means a feature that i really need. I just thought will be a nice addition. So, it can takes it's place in the to-do-list for whenever you think is doable.
The single 'Submenu' widget option is more than enough for now and i'll be happy to test it.
Thanks
Nessus
Test branch at https://github.com/Ignoble61/script.skinshortcuts/tree/submenu-widget
To use, add a new <shortcut /> to the widget-groupings, with $INCLUDE[::SUBMENU::] as the text, something like:-
<shortcut label="Whatever label you want (widgetName)" type="Whatever you want displayed in label2" widget="whatever widget value you want" widgetType="whatever widgetType value you want">$INCLUDE[::SUBMENU::]</shortcut>
(As said earlier, only useful with templates atm)
Great!. Will test it an get back to you tomorrow.
Thanks
Nessus
EDIT: I have an (irrelevant to this) question: I am using this code to include some smart playlists to my widgets list... <shortcut label="31263" type="32004" widget="::PLAYLIST::" icon="DefaultVideoPlaylists.png" widgetType="movies" condition="Library.HasContent(movies)">special://skin/extras/playlists/UnwatchedMovies.xsp</shortcut>
I put the same code to include these playlists and in the shortcuts list for my home menu. It's working fine without to add the ActivateWindow(videos,) and the script added that in the <onclick>. Is that the same way to do or it will cause any problems that i am not aware of ?
No immediate issues leap out at me, but it's not something I've thought about doing (and so thought through it all), so YMMV :)
Sorry but, as you may already notice, my English are very poor so i am not sure what you just said !!!.
Let's say that i am a 10years old child... lol !!!
My bad, I often forget I'm often not dealing with English-native speakers.
I can't think of any issues, but it isn't something I have thought through so whilst it will probably work be prepared that issues may come to light at a later time. (YMMV = Your mileage may vary)
(And your English is far better than my, well, any other language!)
Ok thanks. I better make them with the proper way to avoid any issues. Just wanted to ask if is something that you're aware of.
Thanks
Nessus
Test branch at https://github.com/Ignoble61/script.skinshortcuts/tree/submenu-widget
So, i've tested and it's working fine although i have some issues (and questions).
1, The subemenu widget is not visible when the main menu labelID is different than the defaultID.
Although all widget properties are present and the list's created in the skinshortcuts-template-widget include are there with the proper visible condition, the widget is not visible when you navigate in home main menu item. Example...
This is showing fine:
<label>$LOCALIZE[342]</label>
<label2>Common Shortcut</label2>
<icon>DefaultMovies.png</icon>
<thumb />
<property name="labelID">movies</property>
<property name="defaultID">movies</property>
<property name="widget">CurrentSubmenu</property>
<property name="widgetName">$LOCALIZE[31209]</property>
<property name="widgetType">submenu</property>
<property name="widgetTarget" />
<property name="widgetPath">$INCLUDE[::SUBMENU::]</property>
<property name="submenuVisibility">movies</property>
but this is not:
<label>$LOCALIZE[31002]</label>
<label2>Common Shortcut</label2>
<icon>DefaultTVShows.png</icon>
<thumb />
<property name="labelID">31002</property>
<property name="defaultID">tvshows</property>
<property name="widget">CurrentSubmenu</property>
<property name="widgetName">$LOCALIZE[31209]</property>
<property name="widgetType">submenu</property>
<property name="widgetTarget" />
<property name="widgetPath">$INCLUDE[::SUBMENU::]</property>
<property name="submenuVisibility">num-31002</property>
And this is how my created (by template) widget list's are looking:
<control id="25" type="fixedlist">
<include>HomeWidgetList_Square</include>
<visible>StringCompare(Container(20).ListItem.Property(submenuVisibility),movies)</visible>
<content>
<include>skinshortcuts-group-movies</include>
</content>
</control>
<control id="25" type="fixedlist">
<include>HomeWidgetList_Square</include>
<visible>StringCompare(Container(20).ListItem.Property(submenuVisibility),num-31002)</visible>
<content>
<include>skinshortcuts-group-num-31002</include>
</content>
</control>
2, The submenu widget option is visible in the widget selection dialog for all items of the main menu. Even for those that they don't have subemenu by default. IMHO that's wrong. The submenu widget option should be available only for items that have submenu which was the main reason for this way to assign subemenu as widget.
3, Is it possible for the script to automatically assign the widgetName in something like "[main menu item label] - Subemenu", so we can easily use it in the main management dialog and in the skin. ATM if we assign a label like "Use submenu as widget" then this is also appearing in the label2 of the button 312 and in the skin as the widget's name which is not looking good.
If i can move this a little further, what about if this option could be something similar like the "Create a shortcut here" option ?. I mean with a string provided by the script (eg "Use submenu as a widget") and when is selected the script automatically sets along all the rest and the name in form like "[main menu item label] - Submenu" (eg Movies - Submenu).
So the <shortcut /> to the widget-groupings could look like this...
<useSubemenusAsWidgets>True</useSubemenusAsWidgets>
Thanks
Nessus
The more we get into this, the more obvious it becomes that to do it well will require fairly major code changes, so will have to wait until the script is agreed stable before I start messing it up again ;)
The subemenu widget is not visible when the main menu labelID is different than the defaultID.
Although all widget properties are present and the list's created in the skinshortcuts-template-widget include are there with the proper visible condition, the widget is not visible when you navigate in home main menu item
Damn! I was trying to do it without passing any extra information into templates.py, so based it off of the visibility condition - clearly that doesn't always match the `skinshortcuts-group-[name]. Unfortunately the relevant info isn't actually available when the templates function is called, so this would need also some changes of xmlfunctions.py to have the info available at the right time.
The submenu widget option is visible in the widget selection dialog for all items of the main menu. Even for those that they don't have subemenu by default. IMHO that's wrong. The submenu widget option should be available only for items that have submenu which was the main reason for this way to assign subemenu as widget.
Same problem as earlier in the thread - the management dialog doesn't even know its editing a main menu item, let alone whether that item has any submenu items. This can't be done without major code changes.
Is it possible for the script to automatically assign the widgetName in something like "[main menu item label] - Subemenu", so we can easily use it in the main management dialog and in the skin. ATM if we assign a label like "Use submenu as widget" then this is also appearing in the label2 of the button 312 and in the skin as the widget's name which is not looking good.
Not without major code changes - at the moment library.py (which displays the available widgets) has no way of knowing what menu item is selected (guy.py), so there needs to be added communication between them. Also, the way that library.py shows selected items doesn't currently allow for anything dynamically generated (which it would have to be to show the correct menu name when displaying the submenu widget)
What I'll do is open an issue as a feature request (probably tomorrow), so this doesn't get forgotten about when the script is open to major changes again.
Ok then, no problem. As i said before, this is not something that necessarily needed. Just a nice addition.
Thanks
Nessus
As there's been no activity for several months, and Nessus has unfortunately stepped back from publicly released skins, I'm going to presume it's safe to close this.
I would like to keep this open if it's not a problem. I am still developing Bello and the use of subemenus as a widget will be nice feature to have.
Cheers
Nessus
Re-opened, as requested.
Reviewing this for the first time in a very long time.
The current state (of the current git version, where some changes have been made to a couple of properties that the script returns) appears to be that the current submenu, or any additional submenu can be accessed using something along the lines of:
<property name="submenuVisibility" tag="property" attribute="name|submenuVisibility" />
<include>skinshortcuts-group-$SKINSHORTCUTS[submenuVisibility]-1</include>
These two combined would show the first additional submenu for any given main menu item.
Using such should allow access to most submenu items linked to the currently selected main menu item. Either this will fulfil the original request, or the request is to be able to access any given submenu (which is a request unlikely to be fulfilled as there instantly becomes the possibility of selecting a submenu which will later be deleted and so unavailable - and getting into such situations has long been against the design aims of the script.)
Therefore, if the desire is other than is currently available, you really need to make it clear exactly what the wanted behaviour is. Also, whilst I fully appreciate and respect your reasons for now keeping Bello a non-public skin (and, indeed, consider your reasons valid for arguing that this script shouldn't be public), it's fair to say that my own personal time is given to additions that will be useful to skins that are generally available. Of course, others may be more than happy to lead code improvements inspired by non-public skins :)
Sorry for the delayed answer. I am busy as hell lately. I will test this asap although i am not sure how to do it. Can you elaborate a little more please ?. I mean, how can use this as visible condition so only the subemenus that they have at least one entry (meaning not all the subemenus entries are deleted by the user) to show up in choose widget management dialog ?
Also, whilst I fully appreciate and respect your reasons for now keeping Bello a non-public skin (and, indeed, consider your reasons valid for arguing that this script shouldn't be public), it's fair to say that my own personal time is given to additions that will be useful to skins that are generally available. Of course, others may be more than happy to lead code improvements inspired by non-public skins
I fully understand that and if there is any problem feel free to ignore my messages or just tell me that you wont do it due the above reasons. I am totally ok with this. No problem at all.
Cheers
Nessus
That was code for a template to display a given submenu. It remains impossible to list individual submenu's when choosing a widget within the management dialog - and, because the individual submenu's aren't loaded (which is a very expensive operation in terms of cpu), and therefore not processed to see whether each individual item is visible (which would only be valid for the very moment when they were processed), it remains impossible to know whether any given submenu has any visible items.
Thanks for the answer and clarification @Ignoble61 . if is like that I guess will have to stay with my current solution of showing all the submenus even if they are empty.
I think we can close this now.