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.
Add contextual menu action and Ctrl + Click gesture. See URL.
This action has to be implemented for FCS.
Ctrl+click gestuer is for multiple selection also so, I feel it may not be suitable for go to super definition. I have introduced a menu item in the "go to" right click action which right now is sufficient. Will see if I can implement the keyboard shortcut for this action. Partially fixed right now for non-referenced derived components. Waiting for getReferent() method from model for this.
Chris also raised this concern, when we walked through the findigs, but we concluded that Ctrl+Click still could be used to navigate. Actually it can have dual functionality. Ctrl+Click on a base type or other reference would navigate to type definition, Ctrl+Click everywhere else would multiselect. Even though there may be difficulties, let's try to pursue this, as Ctrl+Click might become an IDE wide gesture - a significant productivity enhancement. What do you think?
IMO, I feel that ctrl+click can not be over loaded. If you are ok with changing the gesture of multiple selection to shift+click, then I am ok with ctrl + click for go to definition. I am sure QA and user will find it odd to have a over loaded ctrl click.
I have a different opinion. If appropriate visual feedback is given, the gesture can be overloaded. Visual feedback for click through is blue font color and underline - which is generally understood. Ctrl+Click is already overloaded in the IDE. Ctrl+Click works in Java editor and e.g. struts-config.xml to click through, whereas it is also used to multiselect in other places. Seeing a base type (an identifier) and giving appropriate visual feedback for click through is IMHO enough for the user to understand. We have also seen in the usability that some users expect this feature. And consider the productivity! Have I convinced you? If not, let's extend the circle ...
I definitely like to have go to super by mouse click. My concern is just with over loading ctrl+click go to and multiple select. Here is the time proven reason why I feel this way...I used to have previously ctrl+click for showing the in-line editor and when I introduced ctrl+click for multiple selection QA instantly raised concern that when they were trying to multiple select, in-line editor came up. That is the reason why I changed the action of invoking in-line edit to shift+click instead of ctrl+click. Even i felt it annoying to have the inline edit come up while I was trying to multiple select. There is not much area in each UI element where you can ctrl+click for multiple selection and not invoke go to super defn accidentally. I totally agree with the argument that Java has this feature. But, the main dirrerence is Java editor does not have big sized UI components that could be multiple selected the way you can do in design view. That is where the major pain point of the user lies. Multiple click is most common usecase and if it is over loaded with action which takes the user to some other place in the view, he will not be happy (at least I will not be as a user) All I am suggesting is, if we are going to have ctrl+click for go to super defn, then mulitple select gesture must be changed to shift+click.
Agreed: ctrl+click for multi-select & inline-editing was not effective. Ctrl+click for go to super definition and shift+click for multi-select sounds almost agreeable, but then we'd be back to the argument above whereas shift+click will be for multi-select & inline-editing. Since inline-editing can be done via F2 and double-click in the Design view, perhaps shift+click can be devoted solely to multi-select? BTW, I thought ctrl+click & shift+click are both for multi-select: ctrl+click is to select at random while shift+click is to select consecutively?
Yes, if we are sticking to shift+click for multiple select, then we will remove the rename option. User has to use either double click/press space bar/press F2 for renames.
<HTT>BTW, I thought ctrl+click & shift+click are both for multi-select: ctrl+click is to select at random while shift+click is to select consecutively? </HTT> True. Consecutive select (using shift+click) will not be available for this release.
We definetely need to stick with Ctrl+Click for multiselect and Shift+Click for consecutive multiselect. That's the standard behaviour. I think that in the past there was a problem with Ctrl+Click to edit, because that's not a standard behaviour. However, Ctrl+Click to navigate is becoming a standard and expected behaviour (we have really seen this in the study often). I strongly believe that Ctrl+Click to Edit is a lot different from Ctrl+Click to Go To Super defintion, and whereas the former was unexpected and confusing the latter is acceptable and expected. There's no other way - we cannot change the gestures for multiselections, we cannot change the gesture for click through neither - for consistency reasons. The only thing we can really do is try the contextual way ... Please consider this again. My proposal is to give appropriate visual feedback on Ctrl+Mouseover on super type labels, which in most cases is not the place where users would Ctrl+Click for multiselection. For selection/multiselection, the users click the big objects - the elements - as observed in the study as well. I'm suggesting to try this and wait for feedback, I don't think it's a big risk, I really do thing that actually that's the right and only way. If you still disagree, let's include Todd.
I just cheked in the ctrl+click suggestion. Please try it out. I would like you to tryout multi-select of elements under "TravelItinerary" global element of OTA schema. If you are not careful you will notice there is a high chance for the user to accidentally ctrl+click on the name label that would lead to scrolling of schema. IMHO, this will be a bad user experience. The reason why this problem happenes is, label occupies almost 75% of tag component. So, the chances of user clicking on the label (even thought we show visual feed back) accidentally is very high.
Oooops, There was a misunderstanding, sorry! What have seen users were trying to achieve was to go to the definition of a base type. Some of them also expected that the action "Go To Super Definition" does exactly that. An example would be to navigate from po.xsd/purchaseOrder/shipTo to USAddress definition. That would be similar to variable declaration in Java. So I was suggesting to make active the labels with base type which are positioned next to the TAG visual object. That of course would not be in conflict with multiselection at all. Now, seeing that the "Go To Super Definition" action is not a counterpart of Java's "Go To Declaration", I'm a bit confused. I think we should: * have an action that allows the user to navigate to a base type (in contextual menu) * expose this action with Ctrl+Click on base type label, which is positioned next the the TAG visual object. I'm not that much sure now about the "Go To Super Definition" and it's shortcut with Ctrl+Click. It seems to me that this action is not that important and that it could be exposd only in the contextual menu.
The type label next to element tag is a hyper link now only for complex types. Let me know if you want me to disable ctrl+click on the tag name label. marking it as resolved.
Ok, please do so.
I can see now that the base complex types are hyperlinks, even without pressing the CTRL key. I'm not sure if that is what we want. Maybe we want to reserve the single click for selection, perhaps in the future user might be able to single click on the base type and change it. OTH, Ctrl+Single Click is becoming standard for "Go To ..." -- just a thought.
I do not think ctrl+click is something that a user would guess because, the type info is displayed as a grayed out label and is not selectable (clicking on it used to select the tag itself before). So, there is no focus for this label in the UI. There is no way the user could guess by pressing ctrl, he would be able to navigate. I would not like to add a whole new logic to make this label alone selectable and all given the state of the project. That is the reason why I made that label as hyper link. IMO, hyperlinks is the best way to let the user know (even non-NB users who are just trying out the product 1st time) that the lable is navigable and also hints him that the UI would scroll around or a new UI would open up on click. I understand that you are trying to standardize, but, hyperlink approach is more intuitive and suitable for this scenario. I do not think we can draw any anology to this situation with the Java editor because, there is a great difference in the verbiage presented here . The closest anology I can think of is the Javadoc pane, which has hyperlinks for variables and method names.... Did I convince you?
You did. A bit. Still I think it's too flashy ... Let's keep what we have for some time and see what are the reactions. OTH - you would be surprised how many users try Ctrl+Click (as this works in IntelliJ, Eclipse, NetBeans, ...)
I can see now that in the iterations on this issue we somehow missed/lost the "Go To Definition" contextual menu action in the Design View (the original reason of this issue). There should be "Go To Definition" action that works as in Schema view (e.g. goes from element PurchaseOrder to PurchaseOrderType). So although there is now a productivity enhanced variant of this feature (via links), the original issue is not resolved. I'm changing this to RFE as there is a very nice "workaround" now.
And reopening (as enhancement).