Improved SceneInspector shader display and shader handles #786
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This improves the display of shaders in the SceneInspector as requested for #335, and also improves the usability of the shader handles generated when creating shader networks - they are now repeatable for a given network and include the name of the node which generated the shader.
I suspect that sooner or later someone will ask for the full path to the node rather than just the name to help identify nodes in Boxes, and I do think this would be preferable, but we don't have the necessary signalling machinery to keep this easily updated at the moment. I think we could add a GraphComponent::fullNameChangedSignal(), but I don't want to do that until we're only constructing signals for the GraphComponent classes in a lazy fashion - signal construction is already showing up as a decent overhead following our recent optimisations (about 5% of total script load time), and also takes a fair chunk of memory and has overhead even when emitting signals without slots attached. This would be exacerbated by a fullNameChangedSignal(), particularly as the naive implementation would traverse the whole hierarchy down when a name changed somewhere. If we had a lazy implementation that only signalled when the signal had been accessed (and lazily constructed) I think this overhead would be much more acceptable, particularly as we have few other use cases for it at present...