This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The new "Local Variables"-View in the Debugger-UI displays the local variables in columns "name", "type" and "value". The column "name" is organized as a tree view allowing the user to browse into nested objects or inherited fields of an object. The values are displayed in another column "value". There are several problems: - there is no horizontal scroll bar in the "Local Variables"-View (complex data may not be displayable) - the use of two columns "name" and "value" splits the structure of the objects from the values, this makes things much harder to check/recognize/use: - it is necessary to resize the columns every few clicks - there is a lot of (unused) white area between structure and values - eliminating a column ("type") does not get saved to the settings - column type is useless since the type is repeated in the value-column which is essential while browsing the data Please provide the old "Local Variables"-View (3.3.2) as fast as possible! (And please never try to use columns again; the data must be presented in a compact way.) Regards, Christoph Gerlach
Hello Christoph, thank you for your valuable input. I have heard somethink similair several times, and I agree with most of your ideas. We will definitly look at it. I am forwarding your comments to our UI. Hanz
My opinion: First, the Type column should not be shown by default. It's usually not interesting, and if a user wants to know, the user can show the column. That's one of the big advantages to having the whole column scheme. Second, the columns should not be assigned equal width. Give 30% to the name column, 70% to the value column. It's okay to truncate the right side of variable names for long variables. Finally, implement (in the TreeTable in openide that is) tooltips for table cells which show the COMPLETE cell value when it's truncated. I think it works this way on Windows when something is truncated.
@Tor Norbye I personally need to see the structure and the values of my data at the same time and not for just one single value. It is not satisfying to move the mouse over an entry in the name-column just to see the name of the variable (pasted over the value column for sure). A good UI for the local variables is designed for quick browsing of large structures. Using a tree view to determine the grade of details (consisting of the name of the field, the type and the value) together with scrollbars seems just right to me. The invention of seperate columns for structure and values adds the task of resizing the columns if you extend or colapse items in the tree. I cannot see any benefits from using columns at all because you never look for values in one row and compare it to the next row - except they have the same role in the structure (like members in an array). In that case the values will be vertically aligned anyway and there is still no advantage of having columns. Using columns is a vaste of space on the screen, no more. Regards, Christoph Gerlach
This issue was also mentioned in issue 26439. As I said in that issue, and as both Tor and Chrisoph have suggested, we can remove the Type column, since it doesn't add a lot of value here. I disagree with Tor's percentages because I think the name should have a much larger amount of space than the value by default (I'd give 70% to the name, and 30 to the value). The treetable was supposed to have had tooltips for truncated values, but this didn't make it into 3.4. Should there be a scroll bar on the name column in the variables view? We could do this, but I'd prefer to try this with the type column omitted and with tooltips by default. For the scroll bar to work well, the IDE will have to remember which frames have had their values scrolled and which have not, and be able to switch between the scrolled and non-scrolled positions when the current frame is changed (since it is pretty aggrivating to have to "unscroll" the view) I certainly recognize that you aren't happy with the tree table view, Chrisoph. However, the feedback I've seen indicates most people are pretty happy with the tree table solution. The advantage to putting the values in a separate column is that it makes it "predictable" where these values will appear. When one has a long list of fields in an object, for example, it isn't necessary for the user to scan each line to locate the value (which can make for quicker scanning). I agree that this is not as compact as the old display, but I believe it is generally more usable.
*** Issue 26439 has been marked as a duplicate of this issue. ***
- Information about type of field is (at least in Java) important. It should be visible by default (in searate column or as a part of field name). - Changing default size of value column will not solve the problem. - There must be horiz. scroll bar. Browsing deep structures is currently impossible... - Tooltips - I will ask core for some enhancements - "most people are pretty happy with the tree table solution" - ist not vary fair. We do not have representatiove set of users, I think. I agree that TreeTable solution is "visually nicer". May be that its OK for beginer users who need to see several variables, but no structured data. But for more advanced users is not usable. I do not want to throw it out now, but we should rethink it once more and do it more usable for every day ussage too.
I doubt there are many beginner users actually debugging a lot including examination of local variables compared with the number of advanced users. Hence the presentation of local variabels (actually all debugging concerns) should focus on the needs of advanced users. "Visually nice" is nice to have but not a goal in itself. Would you be interested in screenshots of "real life" debugging? Christoph Gerlach
I have some more observations: - the name of a local variable is repeated in the column "value", hence the goal of easily finding the value is not reached by the current solution of the local variables view. - the type is repeated in the column "value" if the value is a pointer to another object. Thus the column type provides additional information only for simple datatypes. And the value column contains a lot (usally > 90%) of useless (duplicate) information (the most interesting information, the value, comes last). If you want to stick with a TreeTableView I would like to make the following suggestions: - provide seperate horizontal scrollbars for each column - write the value in the format "value (type)" and ommit the name - write the type in the column "value" also for simply datatypes - having the tooltips would be nice as well - settings on the layout of the local variables view should be saved for the next debugging session Christoph Gerlach
Upps, I just found another bug in the column "type". There is a new feature to open the source file of a type if available by clicking on the typename in the column "type". This does not work for "super" types (my inherited types are from different packages than the concrete type). Christoph Gerlach
Christoph. I'm moving some of your points here into other issues so that each one is clearly separated from the others. This issue is going to get too confusing if we try to discuss everything you are mentioning here at once. I hope you don't mind. I created an issue for the non-persistance of column positions and visibility: http://www.netbeans.org/issues/show_bug.cgi?id=27188 And I just created one for the issue of what is shown via the hyperlinks http://www.netbeans.org/issues/show_bug.cgi?id=27231 And I created one for the contents of the value column: http://www.netbeans.org/issues/show_bug.cgi?id=27233 I've put you on the cc list for each of these so you can track them.
A scroll bar may help some. However, it may also introduce other problems. I watched a fellow using the 3.2 debugger with its scroll bar, and it was really painful to watch, because everytime he switched to using the debugger, he had to scroll around. We might be able to reduce the problem some by removing the icons (they take up a lot of space). When the debugger gets into the windowing system redesign, this may also be reduced by giving the variables view more space. In any case, I am not completely opposed to using a scroll bar. I just see that it has other problems. I'd prefer to do more investigation (both observations and usability studies) before we commit to doing anything. Some other points: - The data type information is important in all languages. The issue is just that it isn't as important as the name and the value. - From the data that we have gathered about debugging, it isn't really a "beginner" versus "advanced" issue. Some people use debuggers all the time. Some people use them rarely or never. That is, debugger use appears to be more of a personal habit than an issue of skill or experience level (of course, for some peoblems, everyone uses a debugger). Hanz, can you include the reference to whatever issue you file about tooltips here, so folks that read this issue can then go see what the status of that issue is? Thanks.
Just changing this to an enhancement, because this is the way it was designed, specified and presented to the community (this is not a comment on whether the design was right or wrong ;-).
*** Issue 27493 has been marked as a duplicate of this issue. ***
->p3
The tooltips should work fine now. Also there are separate scroll bars for individual columns. IMHO the usability of Local Variables view is fine now in NetBeans 4.1. Closing as fixed.
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.