Open HarmonicaAlex95 opened 3 months ago
I don't think the approach you've specified here is suitable, @HarmonicaAlex95. Display nodes already exist- and converting all stores to also be display nodes just needlessly bloats the size of the nodes for when display of their stored values is not currently necessary.
Pulling out a display node to see the stored data is the current intended method to view its contents.
If you just want to quickly check what is stored in a given store- there may be better options to consider, e.g. if hovering over the node would display a tooltip indicating the currently stored object/value/reference, etc.
Per our reporting requirements we prefer issues to focus on the high-level issue rather than a specific solution to the problem a user is experiencing.
- Focus on the high-level issue first, not a specific solution as this lets us approach the problem most efficiently. E.g. it's better to create an issue saying "I can't do X", rather than "Add a component that when this and this it does this". Often there are many different solutions to a problem and if you ask us to implement a very specific solution, instead of asking the problem you're trying to solve, you're more likely to get a lot of questions and possibly no. To learn more, check this page about the XY Problem: https://xyproblem.info/
I feel this would be valid still as it would be nice to have a clickable drop down to show a value from a quick glance from inside the variable (this could be collapsible/expandable and when your done looking at the value, you can click the button again to collapse it once more to its normal size), especially when working with a huge portion of code. And would also be more performant than having yet another display node take up another set of slots which would then be more slots within it to render the UI of that node. It gets messy fast. (this is all my opinion, just thinking).
One other alternative is having you hover over the node input/output and not only showing the data type, but the stored value would also be nice.
Display nodes can actually cause more updates to happen which can reduce performance. Having a display always visible on the store would probably not be ideal for that reason. I think it would be better if you were to hover your laser over the store and it would temporarily show the value.
I am against this to be default because there can be values that are dangerous to display: I'm working with strings the size of megabytes. You don't want that rendered! But maybe that is an issue on its own...
Yes, in that specific case, that would also apply with the existing display node mechanism. I saw you had created an issue regarding handling for large strings in #2630, but is still something good to consider. Thanks for making an issue for that, @mpmxyz.
Hence why I suggested that it be a hidden thing and when pushing a button on the flux node it would expand to show the contents (this feature would be default off, or default collapsed). Then when not needed anymore, press the same toggle button to collapse it again.
Is your feature request related to a problem? Please describe.
So whenever I wanted to view the content of DataModelStore, I had to pull a new Display node to see the content. It would be nice to have it showing by default without having the necessary to have extra node.
Describe the solution you'd like
A direct display showing below of the display under DataModelStore without changing the position of output connector
Example of the proposed UI(int Data Model Store) as shown below
Describe alternatives you've considered
A panel that shows a list of what Variables that is being used under a slot by having a parent node reading any DataModelStore available, showing their value stored in an ordered list
This also includes the ability to shortcut navigate that particular slot/variable
Additional Context
No response
Requesters
HarmonicaFennecCat, AmasterAmaster
Discord: harmonicafenneccat, amasteramaster