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.

- 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

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.