Expand Selected Variables Button in Debug

This document is the public proposal of the "'Expand selected variables' button in variables view of debug perspective." project. You are welcome to write comments and edit document.

I recorded a short screencast/video that highlights the UI issues and helps understand better what I am trying to address HERE.

Full detailed proposal which I submitted through Google Summer of Code system is HERE.

Abstract

Many people use variables view of debug perspective to watch the state of their application, see what are the input and output. Sharing this information is not too easy. Current variables view provides "Copy Variables" feauture, but developers have to expand the necessary variables manually. Main idea of this proposal is, making this expand opearations semi-automatic or automatic.

Background

I personally use "copy variables" action of variables view, when I need to share the state(mostly errors) of my application with my team. Team members can easily understand the situation, since all the data is there. However, preparing this information is not always easy. Especially when working with EJB's or WebServices, received data is too much to manually expand thus hard to copy and share. I always needed a "expand selected variable" action.

Details

My proposal is, implementing a "Expand Selected Variables" button with many options such as

• "expand static variables"
• "expand inherited variables"
• "expand public|private|default|protected"
• "expand until type"
• "exclude(or include) variables that matches a regex"
• "expand N levels".

For example, object "A" has a static variable named "st". If user deselects "expand static variables" option and tries to expand "A", "st" will not be expanded. User won't see members and variables of "st". Other options are all similiar. Then copy operation can be done using "copy variables" button, which copies expanded variables into memory. Unlike "collapse all" button, "expand all" is not logical because there may be a self referencing structure. My proposal is a minor but a neccessary improvement.

Risks

One risk is the difficulty of dealing with self-referencing structures, because application have to expand them only one time. There may be variable A which has a reference to B; and there may be a variable B which has a reference to A. This kind of problems -seem- can easily solve by a set, however this isn't the best approach. Another risk may be the quantity of the features I proposed. I think it would be better to withdraw some of these. I published them here, because I couldn't determine which.