Bug 84166

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).