hey @Boye, just to confirm, is your keyboard navigation working for standard input changing (i.e. always +/- the same amount), and the ask is for more granular control over incrementing with modifier keys? or is keyboard navigation for modifying numberic values not working for you at all? if the latter can you point me to the control you’re referencing (as I am able to increment with keyboard)
Dynamic incrementing is a cool feature request / would be an improvement from inspectorv1! I am taking note
Dynamic slider is on our radar for features (to replace the existing slider component which is a bit heavy / not dynamic, i.e. it always increment same amount no matter how much mouse moves, plus it only appears if there is an explicit min/max value defined for the property).
Right now we don’t have that level of granularity. Couple thoughts come to mind:
For the granularity of whole panes, and in some cases things going inside those panes (like scene explorer or properties), I could imagine augmenting the Inspector API (options) to allow filter the list of “service definitions” to remove some of the defaults. You can see in the code here that we just have a big list of these “services” that collectively compose the Inspector: Babylon.js/packages/dev/inspector-v2/src/inspector.tsx at 868aef32d2296adbf73b4c4df282dca3732f984a · BabylonJS/Babylon.js · GitHub. It would need a bit more thought on what this might look like from an API standpoint.
For settings specifically, currently default settings are baked in, but if we did something for bullet 1 above, then we could break out the default settings and the settings pane as two different “services.”
I’m still curious what your use case is though where you would want to hide the debug pane and remove the default settings.
Would love to know of any bugs you find! In some cases we may already know about them, but I’m sure there are cases where we have some bugs we don’t know about yet! For now, please just dump any bugs you find into the comments of this one issue: Inspector v2 bugs and feedback · Issue #17293 · BabylonJS/Babylon.js
Can you elaborate? I just tested locally and didn’t find any issue with enabling/disabling a TransformNode. For example, if you open this sandbox, expand to Nodes/__root__/RootNode.0 in scene explorer, and then toggle the “Is Enabled” in properties, the node is disabled and the model is not rendered.
React 19 compatibility should be sorted out today (will update later!).
We are making good progress on an experiment with an option for making the overall UI more information dense and should have another update on this soon!
Well, that was just the example. But actually I would like to show to the app users only the minimal set of default panes, to give them so-called “freedom-from-choice”
Yes, keyboard navigation works, but its always +/- 1.
I just tried the old inspector again, where Up/Down is 0.001 increments and shift + Up/down is 0.01 which isn’t too helpful either.
Another nice-to-have would be a quick way to ‘reset’ the value (to 0 or a default value). I think Unity does this when right clicking the label or arrows
Amazing work! Judging by the number of comments it’s going to be a challenge balancing everything. Here’s my feedback, all UI UX @georgie.
I understand this is a much more slick interface with an attempt to reduce clutter however I share the opinion that it’s necessary to have a more compact mode: with lesser margins between properties and containers. My suggestion is that the inspector can be configured to include optional compactMode. Having a well-formed stylesheet would allow for an easy implementation, also allowing override via css.
‘Copy to clipboard’ buttons were useful but I found it irritating that they were buttons (clutter!). Could we have a more elegant alternative such as holding CTRL and clicking the label of a prop, to copy to clipboard please? This would be much faster and more intuitive. Inspector is not a beginner’s tool so I expect this to be adopted by users.
I see drop-downs are used as toggle buttons at the moment. I’m sure this is WIP but we should avoid drop-downs with a small number of values.
The Scene Explorer tree group interaction needs fixing: I expect the click zone to encompass the outer div. Currently we have to click the arrow.
Kudos to retaining the CTRL + Click functionality to collapse all children.
I think it would be great to have a Template Display feature where we can input which properties are shown by default. This could declutter the UI significantly; in context of how the Inspector is used. Keep it simple, for example we can click “Show all” to restore all properties:
We have definitely had some discussions of Flow Graph and how it relates to Inspector v2. We don’t have total clarity or a concrete plan yet, but we know there is work to do here! Thanks for letting us know that this is something that would be valuable to you!
We are close to having a new “compact mode” experiment ready to share with you all!
We have been talking about this a bit already. So far we have been thinking about tucking it into a context menu. We could potentially have a power user shortcut like ctrl+click as well (similar to expand/collapse all in scene explorer, where there is both a context menu and a ctrl+click option).
Can you give a specific example? Do you just mean that if a dropdown only has two options, it should use a different control that is quicker to toggle between the two options?
This is interesting feedback and came up one other time earlier in this thread. I’m really curious about this one since in Inspector v1 you also have to click the +/- icon to expand/collapse. Do you feel like it is worse in v2, or just that this is somewhere we could improve the UX interaction in general? Currently clicking in the overall container div for the tree view item selects it, so we need some way to distinguish between where you click to expand/collapse, and where you click to select the item. In the earlier mention of this, the suggestion was to include clicking the label of the item, but I don’t think this would work since labels can be very long (basically take up the whole tree item). Can you expand more on your idea for different click regions?
Are you thinking you would be able to go into a mode where you could choose whether each property is shown or hidden or something like that? Or were you thinking more like a filter mechanism, kind of like in scene explorer?
This reduces spacing and the size of various controls and icons to increase information density. Currently it is disabled by default for touch first devices, and otherwise enabled by default. It affects scene explorer, the properties pane, and the other side panes. Here is a side by side comparison:
Oh, I see. I did not think about debugging on mobile. I see the conflict now between maximising data density vs needing min-sizes for certain elements (and the extra work of maintaining desktop/mobile versions).
Because otherwise I would have reported that it is still not on par:
I think the reason is that “Version” and “FPS” do not scroll anymore. There also is an additional (redundant) FPS counter at the bottom now.
However, given the aforementioned conflict. Is there an easy way to close the scene explorer but keep open the stats tab? Because if the stats tab gets the full screen height, I assume, there will not be an issue anymore with density. Maybe like this:
@Joe_Kerr thanks for the continued detailed feedback, it is appreciated! Some thoughts:
For the stats version and fps, we could potentially move those into the scrollable region, or we could remove them. As you said, the fps is already visible all the time in the bottom right, and we could add the version there as well.
Right now the plan is to make all tabs re-dockable to any of the four side pane quadrants (upper left, lower left, upper right, lower right) or to undock them into floating windows. This would mean in your example, you could simply re-dock scene explorer to the lower right and then it would just be a sixth tab.
A simple “zoom” option would definitely be easier to maintain than the full on compact mode we are experimenting with. Do you imagine this zoom would apply to all of the inspector UI, including toolbars, or only to the side panes?
Thanks @labris, you didn’t miss anything, this is just an oversight. I think probably any entity that is disposable should have the Dispose button. I’ve added this as a bug to the tracking issue here: Inspector v2 bugs and feedback · Issue #17293 · BabylonJS/Babylon.js. This should be an easy change so should be able to get it added soon!
Correct, it looks like the theme now has 3 options so looking good!
Perfect. That would work well.
I understand the predicament. The solution may be an invisible interactive area left and inclusive of the drop-down arrow. It feels intuitive to me: to be able to click any item in the tree where it collapses or expands its parent/children. I can then comfortably rush around the node tree and know that selecting left of the label will change the display, else when clicking the right side (label and rest of the panel available width) it would select the node as currently implemented. Currently I have to put my eyes into laser mode and find the arrow. See the crude sketch highlighting new interactive areas:
Yes but at any time, the “Show all” is always available at the bottom which would instantly make all properties appear, as long as the tab is selected. Personally, I think configuring which properties are shown by default is all we need as it’s in context of the App. Let’s call it displayTemplate. The default for inspector/playground would probably not use this feature. This may require a bit of work but could result in a minimal view of the properties. I’d also suggest if the config is used, we also hide “null” groups and data such as Animation and Metadata. Most of the time this is visible on the UI when it probably doesn’t need to be for 95% of users 95% of the time (bias?).
A filter search bar may be handy but unnecessarily clutters the area and requires extra user input, this is why I gravitate to the above idea. Again I’m just rolling an idea off my tongue, may not be worth investing in it now but if/when the property list grows, some solution will be needed
@labris today’s build is live and includes a change such that any selected entity that is IDisposable (has a dispose function) now has a Dispose button at the bottom of the General section in the properties pane.
