Community
Participate
Working Groups
The variables and expression views provide similar visualization; just the variables view is prepopulated with the current context while the expression view is defined by user content. Both could probably be merged into the same view, and most of it be factorized for end-users.
Variables view might have hundred of entries, but we might be interested in just 2 and that's where advantage of variables view comes. Where we can just observe the value of concerned objects and don't waste time trying to find them.
I imagine we can unify them and still provide a good solution for the workflows defined in comment #1 by having the view showing multiple top level elements * foo.bar() returned * Variables ** this ** var1 * Expressions ** this.toString() ** var1.length() What do you think?
(In reply to Mickael Istria from comment #2) > I imagine we can unify them and still provide a good solution for the > workflows defined in comment #1 by having the view showing multiple top > level elements Variables view is dynamic and usually is full of various content that changes automatically on stack frame changes. As a user I don't want this space be "stolen" by "fixed" user content from Expressions view. Also that "fixed" content will be not shown anymore in a "fixed" place, it will jump up and down and most of the time it will be hidden because of variables above, and one would need to scroll to see it. So user will see either variables or expressions, and permanently scroll up/down. How could be that an improvement? Can you explain what would be the actual benefit of having both views content merged together?
This request comes from several people on Twitter who prefer IJ's debug experience for several reasons, but the unified variables/debug view is the most frequently mentioned. This is documented in https://www.jetbrains.com/help/idea/examining-suspended-program.html#add-watch > Variables view is dynamic and usually is full of various content that changes automatically on stack frame changes. As a user I don't want this space be "stolen" by "fixed" user content from Expressions view. The proposal here with 2 root nodes in the tree wouldn't make the Variables space stolen by Expressions, expressions would be shown below variables, and may be hidden/collapsed on demand. > Also that "fixed" content will be not shown anymore in a "fixed" place, it will jump up and down and most of the time it will be hidden because of variables above, and one would need to scroll to see it. That's true. I guess that people who've mentioned they prefer IJ's way find scrolling more convenient and consistent than dealing with multiple views. > So user will see either variables or expressions, and permanently scroll up/down. How could be that an improvement? In simpler cases, with few variables and few expressions, users would see both, at the same place without scrolling. > Can you explain what would be the actual benefit of having both views content merged together? I sympathize with the requests on Twitter, and I agree that merging both views would make things more consistent, basically a single view to "inspect" the application. That prevents from having lots of views open and prevent from switching. Overall, I am of the party of those who prefer scrolling over opening more views and switching between them.
Thinking aloud, can we combine the display area in the Variables view for showing expression view? Both have quite a commonalities.
