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.
1. Create a Java project - this will create a main class called something like JavaApplication1 2. Create 2 subclasses of JavaApplication1 3. Go to the line where JavaApplication1 is declared and press Cmd on the class name, a tooltip which contains text "Ctrl-Alt-Click Navigates to Overriding Classes" will be displayed Problem 1: Ctrl+Alt+Click does not work on Mac - the correct shortcut is Cmd+Alt+Click Problem 2: Shortcuts which are a combination of 2 keys and click are hard to perform, it would be better to have a different shortcut that does not require a click 4. Hover a mouse over the editor gutter which displays the indicator that the class has subclasses - tooltip saying "Has Subclasses" will be displayed Problem 3: The tooltip should also tell the user about the shortcut, otherwise it will not be discoverable Problem 4: The terminology should be consistent - one tooltip uses the term "overriding classes", the other tooltip uses the term "subclasses". I think this should be normalized to "subclasses".
Fixed in jet-main. http://hg.netbeans.org/jet-main/rev/00117c1199fb
Integrated into 'main-golden', will be available in build *201205010400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/00117c1199fb User: Dusan Balek <dbalek@netbeans.org> Log: Issue #211649: Issues with the shortcut that shows subclasses - fixed.
Thanks Dusan, I see problems 1 and 4 are now fixed, can you please also look into problems 2 and 3? Problem 2 requires some UI input, so cc'ing Petr Somol.
(In reply to comment #3) > Thanks Dusan, I see problems 1 and 4 are now fixed, can you please also look > into problems 2 and 3? Problem 2 requires some UI input, so cc'ing Petr Somol. Regarding problem 2: there is another shortcut for that (in the standard NB profile): Ctrl-Alt-B. Its not much promoted (but that is what 3 was about, right), and is not the nicest shortcut, but there is not enough nice shortcuts to cover all useful/important actions, and seems (to me, at least), that this action could live with a less pleasant shortcut (in the standard NB profile, at least).
Thanks - I think Ctrl-Alt-B is fine. I even see that there is Navigate -> Go to Implementation in the editor popup menu, although I don't like the term "implementation" in this context. Could we just use "Go to Subclasses"? (And it should be plural.)
Hm, I have nothing against changing the action's name, although Go to Subclasses unfortunately does not seem very appropriate to me - the action also jumps to the implementations/overriders of a methods.
Ctrl-Alt-B is fine here. As for the term "Go To Implementation" in Navigate menus, I agree it is not too good as it sounds right only with interfaces and abstract classes. However, replacing "Go To Implementation" with "Go To Subclasses" only shifts the meaning (and the problem) from interface context to class context, but not covering both. But the Go To actions work with both interfaces and classes, so it would be desirable to have this fact reflected in the action name. And note that the same naming problem applies to the other direction - "Go To Super Implementation" is perhaps even more confusing than "Go To Implementation". Therefore I suggest to rename the pair of actions for going up and going down in the hierarchy at once instead of renaming just one of them. The options we have include: 1) Go To Superclass - ignores interfaces Go To Subclasses - ignores interfaces 2) Go To Super Entity Go To Derived Entities 3) Go To Ascendant Go To Descendants IMHO the second option sounds most correct but the third would look more straightforward in menus, while the first has the problem with interface context. Note that I consider the options above only because they relate to actions that are applicable both to classes and interfaces. From UEX point of view it would certainly be better if the more specific action name was used whenever it is possible: with cursor on a method name in an interface, the action would better be described Go To Implementation(s), while with cursor in a method name in a class, the action would be better described as Go To Subclass(es) or so. It would be indeed good to make the terminology consistent across NB, as suggested in Problem 4 in Comment 1. Whenever there is no ambiguity in meaning, the shorter and clearer option is preferable; in this sense my non-native feeling is that "subclasses" is better than "overriding classes". CC-ing Rich to check this. Remarks: 1) main menu Navigate->Go To Super Implementation shows the shortcut Ctrl+Shift+P, but pop-up menu in editor shows no shortcut. This is minor issue. 2) pop-up menu in editor lists both Go To Super Implementation and Go To Implementation, while the main menu Navigate lists only Go To Super Implementation. 3) another issue relates to what Go To Implementation does - it displays a list of overriding classes first, but when the list is long (as is the case quite often), it is cropped at screen edge without any possibility to scroll.
I am sorry, but both 2.&3. seem much worse to me than any of Go to Implementations/Go to Subclasses. The names in the actions resemble nothing from the JLS, AFAIK, and noone could, IMO, ever guess what that action could possibly do. Having a slightly incorrect action name that is understandable is better, IMO, than a fully correct name that cannot be understand. The problem I see with Go to Subclass is that it is confusing on a class methods: it won't only jump to the subclass of the enclosing class, it will jump to the specific overriding method in the subclass. (I think that the meaning of Go to Super Implementation was more like "go to the code=implementation that is in a supertypes", i.e. piggybacking on the standard JLS term while using it in somewhat different meaning.)
(In reply to comment #8) > possibly do. Having a slightly incorrect action name that is understandable is > better, IMO, than a fully correct name that cannot be understand. Just to say that I agree with what you say above. My previous comment was meant to summarize the problem and pose the question whether we can come up with a reasonable solution or not - I definitely do not want to push any change where there is doubt about the added value.
I guess we can't provide different display names based on the context, can we?
AFAIK, due to performance reasons, we cannot even make the action enabled/disabled base on the given context (the action is always enabled). So, I'm not sure we can quickly decide which of the name variants to use in the given context :-(
All, Let me make sure I understand the issue at hand here. We have a set of navigation functions that, when invoked upon a class or an interface, allow for navigation to either the next item UP the inheritance hierarchy, or to any items DOWN the inheritance hierarchy? How does the second part work? What if there are multiple classes which inherit from the currentl class? In inheritance jargon, there apparently isn't a standard term for this. I've heard, on the "UP" side: parent, super, base, ancestor. On the "DOWN" side, it's usually just "sub", but "child" and "derived" can be used too. I prefer, and think it's the most broad definition, to use parent and child. If you want to abstract it one level out from it being a class, interface, or other object, it's just a "type". If we can't determine what sort of object it is we're looking at and change the name of the menu's object dynamically, I'd suggest going with "type". So, my proposal is: Go To Parent Type Go To Child Types Thoughts? Rich
I'm not sure that 'Go To Parent Type' and 'Go To Child Types' are better names that we have now as the action also jumps to the implementations/overriders of a methods (and I guess that this is most common usecase). My suggestion is to leave the action names as are now... Anyway - problem 3 fixed - shortcuts are added to the tooltips that are displayed when hovering a mouse over the icons in the editor gutter. http://hg.netbeans.org/jet-main/rev/03a1773b44cb
Although Rich's idea in Comment 12 is considerably better than mine, I feel there is resentment about changing the names of these actions among developers (I asked a couple of people around + cf. Comment 8 and 13). Staying conservative and not changing the names seems to be the wiser option unless a wider agreement is reached.
I'm OK with leaving it as is for now if the current terminology is more descriptive of the underlying function.
Integrated into 'main-golden', will be available in build *201205050400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/03a1773b44cb User: Dusan Balek <dbalek@netbeans.org> Log: Issue #211649: Issues with the shortcut that shows subclasses - Adding shortcuts to tooltips.
Dusan, thanks for fixing problem 3. I still think we should strive for more consistency, e.g. right now the tooltip in the editor gutter informs about shortcut "Meta+Alt+B" (on Mac), whereas tooltip when hovering over class name with Cmd pressed says "Cmd-Alt-Click", i.e. quite a few inconsistencies: i. We should decide whether to say Meta or Cmd on the Mac - I prefer Cmd ii. We should decide whether to concatenate multi-key shortcuts using + or - iii. We should decide which of these two synonymous shortcuts to inform about more - I prefer Cmd-Alt-B, because Cmd-Alt-Click is hard to perform
Using "Meta+Alt+B" is consistent with Tools->Options->Keymap, so "Cmd-Alt-Click" displayed in a tooltip when hovering over class name with Cmd pressed should be changed to "Meta+Alt+Click" instead.
Sounds good for now; looks like the "Meta" question is more general, so I filed a separate issue 212599 for that.
Wow, I see that issue 212599 was already fixed by Fanis, so I suggest to use the same approach as in keymap options.
Is the question here whether or not to use "Meta" instead of "Cmd". We should use Cmd. Meta, while ambiguous with regards to context/platform, is not recognizable. It's my assumption that Mac users are accustomed to seeing PC-centric shortcuts and realizing what the relevant Mac equivalent is.
Using shortcuts consistent with keymap options. http://hg.netbeans.org/jet-main/rev/09317b52cc3f
Integrated into 'main-golden', will be available in build *201205180400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/09317b52cc3f User: Dusan Balek <dbalek@netbeans.org> Log: Issue #211649: Issues with the shortcut that shows subclasses - using shortcut consistent with keymap options.