Community
Participate
Working Groups
Using the new API from bug 88293, there is no way to resolve which director should be used if more than one will produce the same region as a hyperlink location. For example, the fix to bug 112630 will produce a hyperlink for the region of a method, and so will the default java editor director. The only way to use the feature from 112630 is to disable the default one and enable the step into one. One suggested solution would be to allow differing modifier keys, that way we could make the step into hyperlinking use Ctrl+Alt (or the like).
This is a known issue and already on the Text plan We won't go for the modifier solution. Possible solutions are: - allow to order them on the preference page - we do it as we do it for the hovers: sort them by dependency (if A depends on B then A's contribution wins). This would enable your link detector (which of course should only detect during debugging and in editors of files that are on the current debug target's class path) - show all existing links in a hover [obviously the best solution but not sure we have time for this]
Why would you not do the modifier solution? If users could specify their own desired modifiers then we could have multiple hyperlink directors available at any one time. Use case: while I am debugging at any one time I have the abiltiy to hyperlink to the definition of a method, etc (as is now), AND I have the abiltiy to step into selection, where all I have to do is use a differnt keypress prior to clicking....basically you have the extensibiltiy and customizability of a menu command this way. some thoughts about your proposed solutions 1. ordering them on a pref pages could mean that I would have to open the page and change ordering every single time I was debugging and wanting to use hyperlink step into, and then when I was done debugging I would have to change it back (over and over again...). 2. I am not sure how you work it for hovers, but the hyperlink step into is only enabled when debugging (it follows the same criteria as the original step into selection command) 3. Personally I would find this solution the most annoying. If I understand it correctly: I would have to activate the link, wait for a popup, read all the choices, and make another selection? This use case makes the point of hyperlinking less awesome if I have to make further choices and selections AFTER clicking the link (where traditionally the link has immediately performed an action). For our step into selection, it would be simpler to select the method and hit Ctrl+R as opposed to this resolution strategy.
How can you speculate on 3?
I was just giving my opion of what I gathered from your description of 3. For all I know there could be precident, or some other reason for using hovers for conflicting action resolution.
re 1: why would you have to do that? Debug would just be top and since the debug detector would only be active and detect links if it is requested in a file that is on the class path then we're just fine. Similar to the default hover where it shows the value while in debug mode. Is currently the JDT or the Debug detector winning?
Currently, for 1, the JDT direct always wins i.e. the debug one is never used. The only way I could test it was to turn off the JDT director completely.
In I20070220-1330, the debug link always wins when a debug session is active. I found this sudden change of Ctrl+Click behavior to be very confusing. I consider the current behavior a bug, since the well-known navigation by Ctrl+Click does not work anymore in debug mode, and I did not change any settings.
I agree with the comments by Markus and Mike. The user needs some way on controlling which action is going to happen, or at least it must be clear to the user which action will take place. I've been working in I20070220-1330 and having the "step into" hyperlink run instead of the "jump to file" hyperlink some of the time is very confusing. I think that having a key modifier would be excellent. Gives the user control over the behaviour. Will having a hover will slow down the user, making the "step into" feature less useful?. Ordering by preference page or dependency doesn't make it any clearer to the user what will happen when they click on a link.
After playing around and testing various approaches I came to the conclusion that configurable modifier keys is the best solution for now.
Created attachment 60166 [details] First cut of a fix (awaits PMC approval)
Of course, the "joy" of the simpler strategy is that, by forcing you to read what is in the pop up, you can educate the user about is available. With the modifier key base solution, will the user ever notice that anything other than the un-modified hyperlink is available?
No. You will get what either the detector provider or the user (via prefs) decided to appear under a given modifier. This is the same as we have for years with the hovers. The popup-navigation solution makes navigation slower and is not feasible for 3.3.
>will the user ever notice that anything other than >the un-modified hyperlink is available? The popup solution wouldn't fix this because also the popup based solution would be triggered off a (configured) modifier.
+1
Committed to HEAD. Available in builds >= I20070311-0800. Remaining issues to be cleaned up during M7 are covered in bug 177112.
Verified in Build I20070320-0010
.
