Community
Participate
Working Groups
If you put the following classes A and TestHierachy into separate files, place the cursor within the body of TestHierachy.B.test(), press Ctrl+O twice, you don't get to see A's member a. It works as expected if you place B into a file of it's own. // file A.java class A { int a; } // file TestHierarchy.java public class TestHierarchy { class B extends A { int b; void test() { // press Ctrl+O twice in the following line // and you won't see A.a } } }
+1. I would expect that the hierarchy is built for the enclosing type at the caret location (or for the main type if there is no enclosing type).
*** Bug 333701 has been marked as a duplicate of this bug. ***
Not showing the inherited members from the top-level type any more would mean a loss of functionality. The best solution I see is to show the inherited members of the type that encloses the selection, and also show the inherited members of all enclosing types up to top-level. That solution would also scale in examples where a CU contains a lot of nested classes (e.g. the JavaEditor class).
Please increase the importance of this bug. From my point of view this is not a minor but rather a major bug. As Markus has mentioned previously this is a loss of functionality.
Created attachment 186283 [details] Fix
Fixed in HEAD. We now show inherited members of top-level types (old behavior) and inherited members of the initially selected type. (In reply to comment #3) > show the inherited members of all enclosing types up to top-level I didn't implement that.
(In reply to comment #6) > Fixed in HEAD. We now show inherited members of top-level types (old behavior) > and inherited members of the initially selected type. Do you mean the Quick Outline of currently selected type, shown after pressing Ctrl+F3 instead of Ctrl+O? > (In reply to comment #3) > > show the inherited members of all enclosing types up to top-level > I didn't implement that. Why not? P.S. The "Java development user guide > Getting Started > Basic tutorial > Editing Java elements > Using quick views" help section has following note: Ctrl+O always opens the outline for the current Java editor. Press Ctrl+F3 to open the quick outline for the currently selected type. I think this note is confusing and it's better to be written a little differently: Ctrl+O always opens the outline for the current Java file. Press Ctrl+F3 to open the quick outline for the Java file of the currently selected type.
This makes Ctrl+O unpredictable as it only adds the inherited members for the nested type at the editor's caret location and when I then expand another type in Ctrl+O Ctrl+O mode I don't see its inherited members. It also means that I can't select a type in the Quick Outline and then get its inherited members with the second Ctrl+O. Please either revert the change or make sure that in Ctrl+O Ctrl+O mode all expanded types show its inherited members.
(In reply to comment #7) > > and inherited members of the initially selected type. > > Do you mean the Quick Outline of currently selected type, shown after pressing > Ctrl+F3 instead of Ctrl+O? No, this doesn't depend on how you opened a Quick Outline. It only depends on the type on/in which the caret was placed before the dialog was opened. That type is already used to improve the filtering experience (bug 88195). > > > show the inherited members of all enclosing types up to top-level > > I didn't implement that. > > Why not? Because it would make the tree too big and show too many less interesting elements. In a class with many nested types (e.g. AbstractTextEditor), a query like "getC" would show a getClass() method inherited from Object for each and every type. (In reply to comment #8) > This makes Ctrl+O unpredictable as it only adds the inherited members for the > nested type at the editor's caret location That's fully predictable. > and when I then expand another type > in Ctrl+O Ctrl+O mode I don't see its inherited members. We have to find a balance between supporting the primary use case well and showing too much information (which reduces usability for the primary use case). As I said above, we can't show inherited members for all types in the tree. Using the initially selected element to show additional inherited members is fully predictable and supports the primary use case (seeing the inherited members at the caret location, like it already works when you're in a top level type). Using the element that is selected when Ctrl+O is pressed a second time would support a theoretical workflow where a user selects another type and then wants to see the inherited members of that type. This is less common. And since the Quick Outline immediately selects items under the mouse and opens them on single click, it's harder to achieve. Furthermore, it happens often that the selection has no meaning at all, because the user just wanted to move the mouse away from the tree, which as a side effect selects an arbitrary element. Please work with the feature and only reopen if you find this to be a problem in real life and have a better solution.
Markus and I had a longer discussion about this today. We both agreed (and verified) that showing all inherited members causes performance issues. We also concluded that the current solution is confusing for users because they don't have an indication which type(s) show the inherited members and hence also don't understand why it's working for some but not for others. Finally, we found a good solution to this problem: we will decorate those types with the "focus" decorator that we already use in the [Quick] Type Hierarchy. That way, the behavior is again predictable for the user.
Created attachment 186489 [details] Fix 2 (adds focus indicator)
Fixed in HEAD.
Verified for 3.7M5 on Mac with I20110124-1800.
Verified for 3.7 M5 with I20110124-1800.
