(2016-03-11, 22:33)ronie Wrote: (2016-03-11, 12:09)phate89 Wrote: The problem with library nodes is that there is no guarantee that there is a movie node. If someone wants it can strip the movie node out and then the skin points to a not existing path
yup, i'm aware and this is the main/only reason we never added it to confluence.
but i think it's time to tackle that situation somehow.
we allow users to customize the nodes, but it's odd (and very confusing) they don't see the result
when using the main menu on the home screen.
Probably one of those cases where I'm speaking out of turn or in the wrong place, but as no conversation with skinners has been started in the Skinning forum that I'm aware of I have to presume this thread represents the current public discussion of this issue...
I have to agree that the current situation - that a node is edited but changes aren't reflected from links from the home screen with the default skin - is confusing. Equally, I accept that the obvious alternative - by which default menu items are linked to nodes which would break should the relevant node be deleted would be equally confusing. As such, I'd like to suggest two possible alternatives:
1) As custom nodes aren't a feature generally known to less experienced users, make it clear to users - via a big red banner on the relevant wiki pages and via an updated message on deleting within this editor - that deleting nodes may break main menu items. In this way, anyone doing so would be aware of the consequences.
2) (And I don't how difficult the necessary changes would be within core) Introduce a fallback within core, so if a deleted node is accessed, it falls back to Kodi's inbuilt nodes. This way, users changes to nodes would be honoured, but deleted nodes wouldn't actually break.
Edit:- Whilst, if it is possible, (2) is probably a better solution from a technical perspective, with my script.skinshortcuts hat on (and with the fact that the predecessor to this script - the video node editor - was created expressly to accentuate the features of the skin shortcuts script), my own preference would definitely be for (1). Not only does that put the trust in users hands, it also fits with the Skin Shortcuts way of working - where we encourage skinners to use library nodes for their default shortcuts, and make the library nodes available for users to select in a completely customisable menu. I appreciate we're not dealing with script.skinshortcut-only skins, though, and hope that my reading-between-the-lines-with-Estuary means that Skin Shortcuts may soon not be the preferable way for skinners to support custom menus.