Community
Participate
Working Groups
M4 There are currently several mechanisms for synchronizing the selection between editors and views: - there is a global Sync With Editor action which the Navigator hooks - the Navigator also has an explicit Sync With Editor action - the Package Explorer has a preference for automatic linking - the Java editor has a Show in Package Explorer context menu action - the Java Coding action set (which is associated with the Java editor) adds Show in Package Explorer and Show in Navigator View actions to the Navigate menu There are several problems with this state of affairs: - the Navigator and Package Explorer are inconsistent - Sync With Editor requires that the view be active, however navigation is more typically done from editor to view - Sync With Editor requires that each view hook the global action, and, for consistency, add the action to their toolbar - having action sets adding multiple Show in XYZ items to the Navigate menu doesn't scale well - editors have to choose which Show in XYZ actions they will put in their context menu Here is a proposal for improving this situation. - We remove the Sync With Editor action from the Navigate menu and the Navigator. - We add a Show In... action to the Navigate menu, which is enabled iff an editor is active. - Show In... is assigned an accelerator, ideally one that can be invoked with the left hand, so that the right hand can move to the arrow keys simultaneously (any suggestions?) - When activated, Show In... pops up a small list of applicable views, with a heading "Show In" (this will look similar to the Ctrl+F6/F7/F8 switchers, but will not be spring loaded). - The list is initially sorted alphabetically (using the collator for the default locale), but when an item is chosen it moves to the top of the list (MRU order). The order is remembered for each perspective, and is persisted across shutdown and restart. Choosing an item in one perspective does not affect the order in other perspectives. - The list of views to show is perspective-sensitive, and is populated in much the same way as the Window > Show View submenu. You can add items programmatically in the perspective factory, or declaratively via the perspectiveExtensions extension point. Items will be added by specifying the view ID. The view must implement a particular interface (see below). - The view class must implement a new interface: /** * This interface must be implemented by views listed in the Show In... prompter. */ interface IShowInTarget { /** * Shows the given selection in this view. * * @param selection the selection to show * @return <code>true</code> if the selection could be shown, * <code>false</code> otherwise */ boolean show(ISelection selection); } By default, the selection passed is a StructuredSelection containing the source editor's input (and not its selection). If show returns false, the workbench simply generates a system beep. Passing the editor input is sufficient for the Navigator (FileEditorInput adapts to IResource), but is not sufficient for the Java editor and Package Explorer, which work in terms of fine grained Java model elements. To support this scenario, there is another new interface: /** * Parts which need to provide a particular selection to a Show In... * target can implement this interface. */ interface IShowInSource { /** * Returns the selection to pass to the <code>IShowInTarget</code>. * Returns <code>null</code> if there is no valid selection to show. */ ISelection getShowInSelection(); } We considered using the existing interface ISetSelectionTarget, which is remarkably similar to IShowInTarget, but decided not to for 3 reasons: 1. ISetSelectionTarget is primarily used for showing newly created items (via a wizard). Views may want to participate in Show In... without having to participate in showing newly created items. 2. Since we need IShowInSource, IShowInTarget is a better name. 3. It's helpful to have the return code indicating success or failure, so that the workbench can handle it accordingly. For IShowInTarget, we considered passing not just a selection, but also the editor input, e.g. show(IEditorInput input, ISelection selection). With this approach, the Package Explorer would get the Java Editor’s input and its TextSelection (obtained from the editor’s selection provider) and could map to the Java element using the editor input and text selection range. We decided against this approach for two reasons: 1. It’s more convoluted than just letting the source indicate the selection it wants to show. 2. It binds IShowInTarget too tightly to editors. We might want to support Show In… from view to view in the future (e.g. show Package Explorer selection in the Navigator). In fact, with the proposed interfaces, it would be trivial to do so for 2.1. - For 2.1, there will be no further enablement rules for the Show In items. For example, the Java perspective will list the Package Explorer and Navigator, and these will always appear as enabled in the Show In... list. However, these views may not be applicable in all situations (e.g. an external class file, or a repository file). For 2.1, the target would still be notified but would return false, causing the workbench to generate a system beep. - The IShowInSource and IShowInTarget interfaces are obtained by first checking to see if the part in question directly implements the interface (i.e. part instanceof IShowInTarget). If not, it checks for an adapter on the part (i.e. part.getAdapter(IShowInTarget.class)). Using adapters allows the part to avoid having the interface methods as public methods on its class, and can be used to resolve method naming conflicts.
There are some more problems with the current state of affairs (the proposal also covers these cases): - the current solution doesn't allow that a view contributed by someone else can be given the same status as the Package Explorer. - the current solution is incomplete, there is a Show In Package explorer action but there is no Show In Outline for example. Comments on the proposal: 1) The Show in... action should also be available from the editor's context menu. The rationale is that Show in Package Explorer is currently available from the context menu. It is frequently used and offering the action from the menu bar only would remove the convenience of the context menu. This would require that a Show In action is surfaced as API (similar as OpenWithMenu) so that editors can include it in their menu. 2) Will the list of views in Show in... only include Views that implement the IShowInTarget interface or will it include all Views (available in Window>Show View). For example, the Task, Search, or Console view should not show in the menu. 3) Assuming we do 2) this will require that the ViewReferences of all the Views in the list will be restored so that the interface check can be performed. To avoid the early restore/creation there could be an optional attribute in the Views extension point that allows a View to declare whether is supports Show in. 4) Show in Target granularity We are currently doing a fine grained selection in the PackageExplorer. We will likely change it to only show the IEditorInput. Doing a fine grained selection based on the text selection results in a signifcant tree expansion that can result in a loss of context. This means: Show In>PackageExplorer: would only select the EditorInput Show In>Outline: shows the text selection of the editor. What I'm getting at here is that the Target needs to be able to decide what to show and not the source. As I understand the IShowInSource interface it would be able to "dictate" what is shown. 5) Did you consider a more explicit interface for IShowInTarget? interface IShowInTarget { boolean select(IEditorPart part); } The existing interface with an ISelection where the first element is an IEditorInput is implicit and leads to ugly code, i.e., the PackageExplorer needs to check whether the first element is an IEditorInput or a JavaElement. With the above interface the target can get at the EditorInput from the part and it could also negotiate other interfaces via an adapter on the IEditorPart. To support Show In from Views the above interface could be generalized to: select(IWorkbenchPart) The ShowInSource interface would still make sense but it would be up to the target to make use of it. 6) the idea to also support adapters is good
1) OK, we’ll make the action API. 2) and 3) For views to show up in the list, they have to be explicitly added to the perspective layout, either in code or via new support in perspectiveExtensions, in similar way to how the Show View submenu is populated. For example, the Java perspective could have Show In / Navigator, even if the Navigator is not open. It will not check views dynamically, and so does not have issues with plugin startup. There is no change to the views extension point, however the view class must implement IShowInTarget if it gets added to the list. 4) For this case, the Java Editor’s IShowInSource would yield a selection containing the current member (as a Java model element). The Package Explorer would choose to show only the containing compilation unit. The Outline would show the member. So, the source gets to say what it wants shown (at as fine a granularity as possible), but the targets can still choose what granularity they want to show (assuming the selection has enough info to obtain the parent elements). 5) I didn’t mean to suggest that the selection would contain both the editor input and the text selection. I was imagining that, by default, the selection would contain just the editor input, unless the source implemented IShowInSource. I did consider an API that would get passed both the editor input and the selection as separate arguments. I also considered simply passing the editor, which would allow any required info to be retrieved. However, these both restrict the API to working only from editors to views, which is why I proposed IShowInSource. The source can put the appropriate model elements in the selection (e.g. Java model elements), and the targets get to decide how best to show them. If we generalized it to pass the IWorkbenchPart for the source, then it wouldn’t be restricted to editors, and targets could pull out any info they need. However, I think targets would end up having special case code for different kinds of source parts, and could only handle the kinds of source parts they know about. I think it makes more sense for the mechanism to trade in terms of model elements rather than workbench parts, so the parts are more decoupled. If we provide IShowInSource, allowing the source to specify the appropriate model elements, I don’t see any benefit to having the target be passed the workbench part rather than the selection.
Here are the proposed APIs as discussed on the phone: /** * Carries the context for the Show In... action. * The default implementation carries an input and a selection. * Subclasses may extend. * * @see IShowInSource * @see IShowInTarget */ public class ShowInContext { /** * Constructs a new ShowInContext with the given input and selection. */ public ShowInContext(Object input, ISelection selection); /** * Returns the input. */ public Object getInput(); /** * Returns the selection. */ public ISelection getSelection(); } /** * Parts which need to provide a particular context to a Show In... * target can implement this interface. */ public interface IShowInSource { ShowInContext getShowInContext(); } /** * This interface must be implemented by Show In... targets (parts listed * in the Show In... prompter). */ interface IShowInTarget { /** * Shows the given context in this target. * * @param context the context to show * @return <code>true</code> if the context could be shown, * <code>false</code> otherwise */ boolean show(ShowInContext context); }
API looks good, one nit... Is it intentional that the ShowInContext API doesn't allow Null return values in the spec for getInput and getSelection. If we generalize ShowIn to Views then they might not have an input.
I'll clarify the APIs so that they allow null.
Should also allow user to customize which items appear in the Show In.. list in the perspective customization dialog. May not be able to do this for M5 though.
I've released the initial cut of this for tomorrow's integration build (I20020128). It adds Show In... to the Navigate menu as a hardwired workbench action, not retargetable. This action is enabled if the current part is an editor, or if it's a view that provides an IShowInSource, and the Show In list is non- empty. Editors can also provide an IShowInSource, but by default it takes the editor's input and selection to form the context. The Sync With Editor action has been removed from the Navigate menu and the Navigator's toolbar. Its global action id remains, but has been deprecated, and will be deleted for 2.1. There are the following new APIs: org.eclipse.ui.action.ShowInAction org.eclipse.ui.dialogs.ShowInContext org.eclipse.ui.dialogs.IShowInSource org.eclipse.ui.dialogs.IShowInTarget org.eclipse.ui.IPageLayout.addShowInPart(String id) There is a new perspectiveExtensions element called showInPart, which provides the id of the view to add to the list. The schema has been updated. I've given the action a default accelerator of Alt+Shift+S. This feels alright, but I need to check with Tod to see if Alt+Shift combinations are allowed in other locales. An alternative is Ctrl+Shift+I, but this requires two hands. Any other suggestions? The prompter is just a regular dialog for now, but I'd like to make it more lightweight, like the Ctrl+F6/7/8 switchers. I recommend making the following changes to JDT: - remove Show In Navigator View and Show In Package Explorer from the Java Coding action set - add the following perspectiveExtensions to the Java and Java Browsing perspectives: <perspectiveExtension targetID="org.eclipse.jdt.ui.JavaPerspective"> <showInPart id="org.eclipse.ui.views.ResourceNavigator"/> <showInPart id="org.eclipse.jdt.ui.PackageExplorer"/> </perspectiveExtension> <perspectiveExtension targetID="org.eclipse.jdt.ui.JavaBrowsingPerspective"> <showInPart id="org.eclipse.ui.views.ResourceNavigator"/> <showInPart id="org.eclipse.jdt.ui.PackageExplorer"/> </perspectiveExtension> - change Package Explorer to provide an IShowInTarget (views in the Show In list must implement IShowInTarget) - consider providing an IShowInSource as well, so Show In is enabled when the Package Explorer is active (see ResourceNavigator for an example) - consider adding support for the Hierarchy view as well It's unclear whether you should add these to the debug perspective. While convenient, they are Java specific and so would clutter the perspective for somebody debugging C code. This is a downside to this new mechanism compared to action set / part associations. I've also changed PageBookView (superclass of the Outline and Properties views) to delegate IAdaptable to the current page, if supported. This will let you Show In / Outline from the Java editor, since the Java editor's outline page will already be active. But it won't work properly from other parts, since the mechanism provides no way of opening or activating the appropriate editor to populate the outline for the current selection. For 2.1, I suggest we omit Outline from the list, and just let the user use the Ctrl+F7 view switcher to navigate to the Outline for the current editor. Known deficiencies: - the Show In list is initially unsorted (should be alpha sorted), however it does correctly put the last chosen item at the top, and remembers the list on a per-perspective basis - cannot customize the list in the perspective customization dialog Note that the dialog is implemented using ListDialog, which I've pushed down to org.eclipse.ui.dialogs. There are several variants of this in JDT, Search and Compare. These plugins should consider using this dialog. I'm considering adding an option to ListDialog to have it use a compact presentation, like the switchers. As part of these changes, I've also added ArrayContentProvider in JFace (see bug 29609). There are lots of places where this could be used.
Since I20030128, I've moved the new APIs to org.eclipse.ui.part (from org.eclipse.ui.dialogs). They are now: org.eclipse.ui.part.ShowInContext org.eclipse.ui.part.IShowInSource org.eclipse.ui.part.IShowInTarget The old interfaces have been deprecated (and reimplemented in terms of the new ones, so they should still work) and will be deleted as soon as JDT no longer references them.
we haven't yet started the migration so it is OK to remove the old interfaces now. we will start on the migration tomorrow.
OK, they're gone. You'll need to load the workbench from source.
It would also be good to have the Sync view support the new mechanism. It current has Show In Navigator and Show In Resource History. With the new mechanism, it could also show in the Package Explorer. Its selection would have to contain elements that are adaptable to IResource, as well as be understood by the Resource History (CVS path).
Filed bug 30529 for Team support for Show In...
updated JDT as you suggested. - removed the back linking option - removed the show in package explorer from the context menu - removed the show in package explorer/navigator from the action set
There is one problem in that IShowInSource only works in the adapter case. It doens't work when the interface is implemented directly. This is inconsistent with IShowInTarget.
Fixed ShowInAction.getContext to use getShowInSource, which does both the instanceof check and the IAdaptable trick.
Still TBD: - implement lightweight prompter (as switch in ListDialog?) - proper Javadoc for ListDialog - write help content for action and dialog
Also need ISV and User doc for Show In... support.
Clarified spec for IShowInTarget.show with: * The target should check the context's selection for elements * to show. If there are no relevant elements in the selection, * then it should check the context's input.
Erich suggests allowing show in source to provide a list of targets. Should consider this.
Need to allow new perspective customizations (show in items) to appear without having to reset the perspective.
You cannot get the Show In contributions once you have customized and saved your perspective. Even resetting the perspective doesn't make the contributions available. Given that you cannot customize the perspective there seems to be no way to get the contributions.
On 20030205, do I have to use Navigate->Show In each and every time I want to find the selection in the Package Explorer? If this is the case this really changes the way I work...I used the automatic back-linking behaviour in both the package explorer and navigator.
The answer is yes. We would like to replace back-linking since it has loss-of- context problems when you close editors (it warps you elsewhere). Automatic back-linking in the Navigator has been gone for a while. Do you mean the Sync button?
Please see last post.
I guess I don't use it in the Navigator as much as I thought I did. I have never used the Sync button. The warping was annoying. I will have to adapt. Thanks for the explaination.
I find removing the automatic back linking in the Package explorer is a step backward. When you have more than 10 editors open, it is not possible to read the name of .java file you're editing. However I always knew where I was just by glancing at the Package explorer. I now cannot trust the selection in the Package explorer any longer. I know that I can use a key combination to have the selection happen, but this is way less convenient than moving my eyes to the left :-)
I think there are better ways to track which editor you're in other than relying on backlinking. The editor should show its file in the status line (including full path).
I agree with Jerome that it is a usability step back. Show in works, but I have to use many mouse clicks to get there (figure which view I want to show into...). I don't mind the fact that when closing an editor, another one gains focus and will cause the selection to change in package view. If I don't want automatic linking, then I would disable it.
Same for me. I never voted against the new "Show in..." feature/behavior but I always asked to keep the option to enable back linking. Those coming for VA Java and/or using the Java Browsing perspective are used to it. BTW: Some time ago there was work being done to reduce the number of steps to achieve something. This new behavior actually requires more steps to achieve stuff that I could do in zero steps before. Please, bring back an option where users can enable back linking.
The trade-off is loss of context vs. more gestures. The feedback from back linking users we got so far is that they are not that concerned about the loss of context. We can revive the back linking for the package explorer, but then we would be inconsistent with the Navigator and other "navigator style views".
Dani asks (about having to reset perspectives for the list to show): This works for predefined perspectives (and modified predefined perspectives) but what about perspectives I created myself? - Window -> Reset Perspective did not do the trick - Window -> Preferences -> Workbench -> Perspectives: the "Reset" button is disabled for my perspective Do I have to delete and recreate my predefined perspectives? Nick replies: Sounds like this case is not covered. I'll add it to the PR and definitely consider it in the fix to this problem. You should not have to lose your work. When you created your perspective, which predefined one was it based on? If it got the list from that perspective (without having to reset anything), would it work?
>When you created your perspective, which predefined one was it based on? They are based on Java and Java Browsing >If it got the list from that perspective (without having to reset anything), >would it work? Don't understand exactly what you mean here.
A user-defined perspective based on the Java perspective would get the Java perspective's list of Show In items (without having to reset).
ok for me.
1) Shouldn't this be part of the perspective customization dialog too? 2) Couldn't the opened views (the target) be included to the show in dialog as well even if they are not defined in xml?
1) Yes, but this will not be in for M5. Depending on other priorities, it may not be in for 2.1 at all. 2) Will have to consider this. See also comment #19.
Another use case where I miss backlinking: In a self-hosting workspace I'm editing IJavaElement.java in project org.eclipse.jdt.core. I have another editor open on IResource.java in project org.eclipse.core.resources. I want to open IResourceDelta.java in project org.eclipse.core.resources. Since org.eclipse.jdt.core is expanded, I cannot see org.eclipse.core.resources in Package explorer. With backlinking I used to give focus to IResource.java so that it would show me org.eclipse.core.resources expanded, and from there it was easy to open IResourceDelta.java.
Perspectives are sometimes criticized as only being a bunch of views grouped together, but having little awareness of each other. Linking selections automatically is thus important as it gives a perspective some sort of coherence. I am naturally expecting that a selection in editor is reflected wherever it makes sense (outliner should keep up, navigator should notice, etc...). If not, then it feels like a bug, especially since we had this behavior for the past years (regression). I accept that some users don't want this behavior, and it can be disabled, but IMHO it should default to be linked, as would other VAJ/IDE users I presume.
2 more things i would like to see with this feature: 1> If only one option don't show dialog but directly link it. Linking for example the package explorer when it is the only thing that can currently be linked can then be done with one keystroke. 2> If i am in to Go Into "Mode" (package explorer or navigatior) and i say show in XXX on a resource that isn't in that portion of the view then the view doesn't go up and tries to select it there (and still not there go up ....)
number one of my request will be (sort of) fixed when 31106 is implemented.
I have a suggestion that should help make this more usable. In the help viewer there is a toolbar button called 'synchronize navigation' that finds the current help page over in the table of contents. How about a similar button on the editor or workbench toolbar that does a 'show in package explorer' for the resource currently being edited? I think that would address the problem with more gestures.
Should support the following views as Show In sources: Task List Bookmark List
Main feature implementation and bug fix for not having to reset perspectives made it in for M5/RC0. Still some work to do for RC1.
Regarding Ed's comment #41 and other comments on back-linking, there are 5 basic models we contemplated: 1. Automatic back-linking. Pros: - doesn't require any extra clicks to show editor input in view - always in sync between editor and view Cons: - surprising loss of context when you close an editor and it warps you to the selection for the newly active editor (sometimes you want this, sometimes you don't) - doesn't support view-to-view linking (it could, but it would probably be too confusing) - requires preferences (for each view) to turn it off, since not all users like this mode of operation 2. Explicit Show In XYZ view actions (either on the context menu or the Navigate menu) provided by the source part. Pros: - straightforward - quick to use via mouse if on context menu (not too bad via keyboard either if mnemonics assigned well) - can assign keybindings to the individual actions Cons: - its "egoistic" -- source part has to hardwire support for its preferred targets - doesn't scale well when there are many potential targets 3. Sync With Editor action in the Navigate menu and on the view toolbar (we had this in M4, supported by the Navigator) Pros: - one click syncs you up (if view is visible and is not a fast view) Cons: - slower than option 2 if view is not open or is a fast view - not great for keyboard navigation: even if you assign a keybinding to the action, the target view must still be activated first - requires every target view to add a button to their toolbar (visual clutter) 4. Sync With Views action for the editor (broadcasts to all targets; what Ed suggests) Pros: - one click syncs you up (in all interested views, even if obscured) - can assign a keybinding to it - scales well Cons: - may cause loss of context since you may not want all views to be sync'ed up (e.g. may be doing different things in Navigator vs. Package Explorer) 5. Show In... (user chooses target) Pros: - quick to invoke (assuming mouse users will use accelerator with left hand, or reassign it if right handed) - allows explicit selection of target - remembers last selection, so should be as quick as dedicated Show in XYZ action if you're usually going to the same one - scales well (no extra UI in sources or targets, and doesn't require prefs) - allows more synergies than the other options (view to view navigation) Cons: - must be manually invoked (i.e. it's not option 1) Overall, we felt option 5 works best. Note that the issue of scalability is important for us. We don't see it so much just in the SDK, but this is a real issue for larger products like WSAD.
Will the automatic backlinking be resurrected ? The grand picture is one thing, but the obvious scenario where I am inside the Java perspective with my package view next to my editor (default) shouldn't be treated as a rare case. If I have multiple navigator views, then there is a strong chance that they are stacked on top of each other, and thus only the active one should try to keep up with my editor selection (other navigator would perform a check when it gains focus).
We have no plans to add backlinking back in the Navigator. It's up to the JDT-UI team to decide if they want to add it back in the Package Explorer (and whether it's on by default).
I know its unfair, but why do we have to change a good feature to a far more complicated one (at least in the moment)? Why so late in the 2.1 time frame? We already have M5, hopefully its possible to get a more comfortable solution in 2.1 Have not read all the comments, so there is perhaps a deep good reason to change this.But I as an user want to be informed about this. I would expect to have an button on package view or an action at the editor context menu to show the current cu in the package view. I felt like an idot as I wanted to export(drag&drop) a bunch of java files. Scrolling the file to the package statement and clicking my way through the package view. Now I know the the Open In Action, but it is to complicated to use it. If the new interface is not useable to bring the old behaviour back or a one click|one action to focus the package view on the current type, it should be changed to allow this. The browsing perspective will be my new friend, but I can not drag&drop from there. And add some pointers to the docs (changes from 2.0 to 2.1) Sorry for the rant.
>Why did we change this? The answer is simple... to get feedback from our users. We have forced some new behaviour on you and are now listening. In fact, we are getting valuable feedback. Here is some more background. Navigation from an Editor to a View and from a View to another View are an important interaction in Eclipse. The old solution (Show in Package Explorer/Navigator actions/back linking) is not general enough. Plug-ins are contributing additional views and it is important to not lock them out and allow them to get the same first class treatment as the Package Explorer or Navigator. The current Show In... (alt+shift+s) is such a general mechanism. What we wanted to find out is whether this general mechanism is sufficent. Therefore we have removed the older mechanisms from the UI in the last build. The feedback we are getting tells us that users like the more general navigation support, but they also like the existing "short cuts" (Show in Package explorer/back linking). So we will look into improving this.
Navigate > Show In... seems always disabled in M5. Since you're looking for feedback, I have always hated the Show in Package Explorer option (I don't use the Package Explorer like an Outline view, either) and it is darned hard to find out where to turn it off. If you do reinstate this, please don't make it the default.
[EG. we want feedback] Ok. Than a more constructive one from my side. I also did not like the old linking behaviour very much. But it was a fast way to get the resource and package location of a class. And it was not disturbing enough for me to change it. In newer builds (<M4) I just added a navigator with no linking behaviour to the java perspective, so I could select there any resource I want, without the disturbing jump in packageview if I select an editor. The imo best solution would be to have something like a prefered object for Show In... .So it should be posssible to have a one-click|shortcut action to move the packageview to the current active edior resource. Another way around would be to simply Show In the first view in the list. And to let the user order the list of views.
(BTW if you join the discussion now and don't want to read the full bug history - pls read at least Nick's analysis in comment #44). Bob - "I have always hated the Show in Package Explorer option" by this you are referring to the preference setting (back linking) and not the "Show in Package Explorer" in the Java Editor's context menu? Pls see comment #31 for the "empty show in menu" problem. Martin - a light weight prompter and (a la ctrl-F7) plus sorting the target list MRU would cover your needs - correct?
*** Bug 31406 has been marked as a duplicate of this bug. ***
I see the "Show in..." and "Link package explorer..." really as two separate functions. The "Show in..." feature is nice if you want to show an editor in any of a number of different views. You would do this as the need arises, probably infrequently. But the "Link package explorer..." is nice if that is your main view and you always want that view and the editors to be synchronized. (As it is now, if I wanted this functionality, I would have to do a "Show in..." each time I changed my editor.) The functionalities could possibly be combined. The "Show in..." could have a user-defined default view that it automatically shows in. And you could still manually do a "Show in..." for any other views that you were interested in.
[erich; read before] I liked option 3. Good from a users perspective. The view should change - ask the view. Easy to find. I have to confess I get used to the alt+shift+s;key down;enter. I would try to 'hack' it to have the packageview always first. Now its a bit random wich view is first. So a user defined sorting sounds not bad. But also a ctrl+f7|f6 style control could be nice. My major problem is to find the action. I never expected it in the navigate menu, and also the label Show In... does not point to its usage. Its to general. My state of mind is, show me where the type|resource is situated in the project. I do not think which view would be better to show the current resource.
Re: comment 54... Instead of doing "alt+shift+s;key down;enter", you should be (are?) able to just bind a key mapping to "Show in Package Explorer". Then, presumably, you only have to press your key mapping and it will automatically jump to the selection in the Package Explorer, without you having to choose from the listing. I say "presumably" because I can't seem to get that key mapping to work when I set it in the preferences. Does anyone know if this should or already does work? And if it works like I described? That is, only one key-mapping press will immediately show the selection in the Package Explorer. If this is possible, it would greatly alleviate my dislike of the new "Show in..." method, in that I find it takes to many keystrokes. If it was able to be tied to a simple keystroke, that would be much more efficient.
Erich - I misspoke. What I have always hated, in terms of #44, is automatic back-linking. Automatic back-linking was not just bothersome when you closed an editor; it was equally annoying when you used Open Type to open the source for a class in the JDK or Eclipse. Whole hierarchies unfolded to expose these packages, making the view very difficult to use to locate one's own classes. I posted this comment mainly so you didn't get feedback only from the "Where's this wonderful feature?" crowd, whose usage patterns are obviously different than mine. Having re-read Nick's analysis, I agree with the conclusion. It is important that the feature work symmetrically across all applicable views. By use cases, it is easy to see that sometimes users will want a particular view reset and sometimes they won't. For example, when you open an editor, it is often helpful to have the tasks view scroll to the tasks for that resource. But when you are working on one of those tasks, it can be unhelpful, as the tasks view provides a shortcut back to your locus of interest. The more views there are, the worse the problem gets, but Eclipse has enough to illustrate the issues. However, I note that there are a couple of special cases that test this general rule. a. In M5, selection of an editor in the editors view does not change the selection in the Package Explorer, but selection in the Package Explorer does change the selection of an editor in the editors view, if the editor is already open. Is this asymmetry justified when there are other equally convenient ways to expose an open editor, or is a hangover from automatic back-linking? b. Currently the Java editor (and mine) "opt out" of the general strategy and allow the outline view to be back-linked (symmetrically). But I think this exception is only possible because both views are contributed by the same plugin. Would a plugin contributing a graphical GUI editor view that wanted to auto-synch with source selections be out of luck? (Is this one of those "Show me one and we'll refactor to accomodate it," questions. :-)
*** Bug 31492 has been marked as a duplicate of this bug. ***
I don't care how it's done nor how ugly its done, all I want is the explorer to sync with the editor. It is such a great feature that you can't just remove it! Now it just sucks. Not even mapping a key like ctrl-2 to "show in package explorer" can make it work. Forced to alt-shift-S, with an aimed double click: that is WAY too annoying. It should not require keyboard at all for such a common action. It was allright since 2.0. Just put it back. I actually select some editor to avoid endlessly clicking in the tree! I even keep editor or tasks, (now bookmarks since they are finally in a table and sortable) knowing that the tree will open exactly at the package I want to work on. Bye now, I gotta rollback to my good "old" i20030122...
it IS very annoying. in M3 it used to be just fine, but (if I remember correctly), the collapse all button was not there yet, and the tree became very expanded. in M4, it started to act wired, and sometimes opened the file in the package explorer when I opened the dialog anyway, but most of the time only if the package was already opened. this was a little annoying, but I could live with that. now its now opening it at all, which really does lower my peoductivity. I would really love to see a good solution for this as soon as possible.
*** Bug 31509 has been marked as a duplicate of this bug. ***
*** Bug 31481 has been marked as a duplicate of this bug. ***
I have had an argument or two about this the last few days, and I thought I would share. I generally agree with the "what's wrong with the current picture" analysis. I hated the Package Explorer linking. I don't like views whizzing around me. I also agree with Bob: if you bring it back, please turn it off by default. Colleagues of mine, however, seem to find this whizz-tastic option invaluable, so I imagine you will get (are getting) a lot of requests to bring it back. I did use the Show In Package Explorer context menu quite often. In fact, I have now selected "Open Super Implementation" about 25 times by accident. My hands are apparently trained on it, but I am learning. After much deliberation, I have decided that any single-action solution to see the editor file in the most often used target (package explorer) would be OK. I can train myself to use something other than the old context menu, but I think there is a consensus that Alt-Shift-S-[Down]-Enter is a bit too much. Normally I would beg that it not be Ctrl-F7, but I supopse now I can change it myself (go key bindings!) :) -Andrew (one of the anti-whizzing-views people)
*** Bug 31753 has been marked as a duplicate of this bug. ***
*** Bug 31580 has been marked as a duplicate of this bug. ***
Just to throw a little chaff in front of the missile, I have yet to see Show In... or its accelerator enabled. I have performed the ritual dance (not a pretty sight) and incanted the ritual cant, but the replacement feature seems to be out of order.
Bob, which build are you running? In the M5 build (I20030206 17:00) and more recent builds, you should not have to reset the perspective for this to be enabled. You need to be in the Resource perspective, Debug perspective or one of the Java perspectives (or custom perspectives based on any of these). The active part must be a text editor (either plain or Java) or a view that provides a Show In... source (e.g. Navigator or Package Explorer). The text editor is the easiest to see since if you're in a view, it removes itself from the list. If this doesn't work for you, could you please indicate which build you're running and attach a copy of your workbench.xml file (from .metadata\plugins\org.eclipse.ui.workbench).
I agree that action #5 in comment #44 is the best option. However I don't see any reason to remove the users ability to toggle (on a view per view basis) automatically syncing with the editor selection. For each view that supports IShowIn (* not real interface name) allow the user to configure if they want it to automatically sync. Leave them all off by default. Users that like the feature and that are not confused by the context switch (or annoyed) can enable it for the views that they like to be synced automatically, and the rest can use ctrl-shift-s as needed. Sound look a good idea? Also, I am using M5 and bound ctrl-d to sync with package view, and ctrl-shift- d to sync with navigation view (global scope, standard configuration, standard configuration active) and hitting those keys while in the editor has no effect. ctrl-shift-s works just fine however. Is this not implemented in M5? When I was using M3/M5 I used the auto sync feature to quickly find an item in the navigator or package view so that I could access the team menu or other similar item. Some items in my tree can be quite deep and take while a few seconds of hunt and click just so I can access some menu on a file. It is very convient to open a file with ctrl-shift-t or ctrl-shift-r in an editor, sync the navigator view, and preform my action. I would like to have this behavior be as effecient as possible otherwise I might as well hunt and click my way to the file myself.
Nick, are you saying it doesn't work in the Plug-in Development perspective? No wonder I was puzzled. Now that I open the Java perspective, I see it enabled. But I need it to be enabled in PDE, where I do all my work. :(
I notice it isn't enabled in my XML perspective, either. What does a perspective need to do to get this to work? (Would have been nicer if it were backward-compatible.)
With the support in M5, individual perspectives or plugins that extend them must explicitly register Show In... targets with the perspective. In M5, this was only done in the perspectives mentioned in my last note. Spec for the perspectiveExtensions extension point, or the showInPart elements in the plugin.xml for org.eclipse.ui or org.eclipse.jdt.ui. Yesterday I released support for the active part to provide a list of items as well, so the Java Editor could list the Navigator and Package Explorer independent of which perspective is active. See org.eclipse.ui.part.IShowInTargetList. Also added Show In... source support for the Tasks and Bookmarks view, and augmented the ResourceNavigator to handle markers in the selection.
Ok, I can do that. Thanks. Should I assume that Show In... will be supported in PDE perspective (one way or another) or should I file another bug report?
I think if the Java editor specifies the Navigator and Package Explorer as Show In targets, there will be less of a need for particular perspectives such as the PDE perspective to also list targets. However, if the PDE perspective has other views that it wants to include as Show In targets, then it will have to list them.
Based on your feedback and discussions with the usability team, we have decided to do the following. Show In support (in Navigate main menu): - Change to using a submenu for Show In rather than a dialog or lightweight prompter. There will be no accelerator, but mnemonics can be used. - Items in the submenu will be arranged in Most Recently Used order. - The order will be persisted with the perspective. - The Navigator and Package Explorer will be listed as Show In targets by the Java editor, so they will appear when the Java editor is active, regardless of the current perspective. "Show In Package Explorer" context menu item: - Since this will be the most commonly used Show In item from the Java editor, the Java editor will add "Show in Package Explorer" back to its context menu. - In addition, it will register this action with the keybinding service, allowing the user to assign it an accelerator key (it will have none by default). Back-linking: - Add back-linking back to the Navigator and Package Explorer, but not as a global preference setting. - It will now be a per-view toggle setting, available on the toolbar (and also the view/triangle menu, for accessibility). Note that this also allows one-off syncs (for those that have linking off) by clicking on the button twice. - The tooltip / menu item name will be "Link With Editor". - The setting will be remembered with the view. - The default setting will be off (no back-linking) in the Navigator and Package Explorer. - The Java Browsing views will support this as well, but may choose to have it on by default. - As was the case in 2.0, the setting will only control whether back-linking is on (i.e. a change in editor affects the selection in the view). Forward linking will always be on (a change in selection in the view brings the corresponding editor to front if it is already open). - Other Navigator-like views in other Eclipse-based products will be encouraged to support this. Thanks to all for your feedback and patience with us on this late-breaking item (this has got to be one of the most cc'ed PRs of all time!)
Backlinking sounds good to me, as long as I get some global preference (Jdt/Platform?) where I can tell it what the default is, unless the backlinking behavior was on by default <g> I don't want to be forced to toggle another preference on a per package explorer basis (yes it is more powerful, but in the end I just want backlinking by default), i.e. more power is good for advanced scenarii, but the simple browser behavior we used to have shouldn't be made more complex.
Actually, if the package explorer individual setting becomes the default for new windows, I believe I am a happy camper again.
The back-linking toggle has been added to the Navigator. This is in last night's nightly build and will be in tomorrow's integration build.
That's good, because just as strongly as you want back-linking to be the default, I want it not to be the default. ;-}
Above I stated: The default setting will be off (no back-linking) To clarify, this means that when creating a new view, either in a new window or after closing and reopening a view, the setting will be off. To do what Philippe requests in comment #75, there are three options: 1. Inherit the setting from the window where you choose New Window. This only addresses the New Window case and not the close/reopen case. We also don't really have any good mechanisms or policies for managing the inheritance of settings between windows. 2. Remember the last setting as a global (persisted, e.g. using the dialog store). This would address both cases, but may be confusing to the user. E.g. if I turn it on in one window, the turn it off in another window, the next window I open will have it off, even if I open the new window from the window where it's on. 3. Use the preference override mechanism. Note that we have kept the old linking preference internally, to allow products to override the default setting. See IWorkbenchPreferenceConstants.LINK_NAVIGATOR_TO_EDITOR. This could also be used to meet Philippe's needs, but it's a hidden feature (not accessible from the UI). You can add the following to the plugin_customization.ini of the primary feature's plugin (org.eclipse.platform): org.eclipse.ui/LINK_NAVIGATOR_TO_EDITOR=true JDT will adopt the same approach for the Package Explorer. For 2.1, I'd prefer to leave it at that since I have concerns with Option 2 above.
There's something wrong with this analysis. Opening a new window currently discards all perspectives except the current one at the time and resets all perspective attribute to defaults. This case should not be affected by #2, or it would behave very differently than everything else. But the close/re-open case absolutely positively should behave as in #2. This is the way it behaves with, e.g., filters and other view properties.
Here are the changes that JDT released into the integration build of 02018: * all the "global" back linking preferences got removed. * Package Explorer: same behaviour as Navigator * Browsing perspective views: - back linking is stored per view. Back linking is on by default - the back linking toggle isn't available in the toolbar, but only in the view menu. The rationale is that these views are almost always used with back linking. Adding a back linking control to the view's toolbar would have made this option too prominent. * Type hierarchy view: - back linking stored per view. Off by default. - the back linking toggle is only available from the view menu. To be done: * Revive Show in Package Explorer in the editor context menu.
I apologize for replaying this one note, but the last response simply said it would be possible for JDT to implement. I am hoping for some indication JDT actually will implement in 2.1: Show In... (from editor view to Package Explorer/Navigator) will be enabled in the PDE perspective, yes?
>Show In... (from editor view to Package Explorer/Navigator) will be >enabled in the PDE perspective, yes? yes - this also went into the integration build of today.
Gosh, it took quite a while to read it all !! Ok, based on comment #73, it seems that to enable back linking (I use it mainly in the package explorer), you will have to click on the button on the toolbar, or use alt+shift+s and then select package explorer. I saw the comment which says if I set the following : org.eclipse.ui/LINK_NAVIGATOR_TO_EDITOR=true backlinking would work - but I think it will enable backlinking only for the navigator, not the package explorer. Something like LINK_PACKAGE_EXPLORER_TO_EDITOR=true is probably needed. Personally, I really use the backlinking a lot. I want it to be automated in the package explorer view. Many times I use Ctrl+Shift+T to open a class in a particular package, and because of back-linking, I can see all the classes in that package immediately since that package is also expanded. Now I have another step to do the same operation. It is very useful to have that on in conjunction with my Perforce Team provider, since now after opening the file, I can immediately right-click on it to see its properties. I think its actually a hassle to use a mouse gesture/keyboard everytime to figure out where the currently opened file is. If we can't do anything, please put an option in the preferences which enables backlinking for the package explorer. You can leave it off by default for people who hate the explorer whizzying around, but for people who use it (and from reading the comments it seems people use it mostly on the package explorer) leaving that option in there is actually a blessing. And an extra item in the preferences menu, especially for something as important as this feature is not a very bad thing. Thanks from a user who loves the backlinking feature :) Jalpesh.
The toolbar button is a toggle button, so once you've turned linking on, the view will stay synchronized with the editor.
The Navigator now remembers the Link With Editor settings in the dialog store, as per Option 2 in comment #78, so we no longer disadvantage those that prefer linking on. It seems the pros outweigh my imagined cons on this one. JDT will do this as well.
Added IWorkbenchActionConstants.GROUP_SHOW_IN. A group with this id should be used in context menus with "Show in ABC" actions (e.g. the Package Explorer's), to allow other plugins to add their "Show in DEF" actions to the same group.
*** Bug 32361 has been marked as a duplicate of this bug. ***
In the I20030221 build, Show In has been changed to use a submenu rather than a dialog (as mentioned in comment #73). There is a known problem with the order of items. The items should be arranged with the most recently used item first, but this can only be done for items that are contributed by the perspective, not by the current part. Items contributed by the current part are always added at the end.
Since it now uses a submenu, there is no longer any accelerator (used to be Alt+Shift+S). Keyboard users can use mnemonics: Alt+N, W.
Is there any reasoning behind removing the accelerator for this feature? Sure I can access the menu with Alt-N W, but I would much rather do it with fewer key strokes. It doesn't bother me that these bindings aren't set by default, but please atleast give me the ability.
*** Bug 32611 has been marked as a duplicate of this bug. ***
We switched to a submenu because it was felt that the number of items will typically be small, and a dialog is too heavyweight for this purpose. Also, JDT has added back the most common case: Show in Package Explorer is back on the context menu of the Java editor. If you're a keyboard user, you can activate this using: <menu key or Shift+F10>, K or use mnemonics as you illustrate. The accelerators was removed because you cannot assign accelerators to submenus. Mouse users can click twice on the link icon (if the view is already visible).
I recall you were adding API so any editor can enable this menu. Could you point out where it is?
I'm using the RC1 build, and I do not see the toolbar button (in the java perspective) which will allow backlinking on.
Sorry for the previous comment, I was looking in the main toolbar. The button is available in the Package Explorer Toolbar.
For Show In to be enabled, the source part (current part) needs to provide a ShowInContext, and there must be some list of target ids to show. These can be provided either by the perspective or the source part. Note that the source part is excluded from the list of targets. For the ShowInContext, the part can provide one explicitly by implementing IShowInSource (either directly or via IAdaptable), or, if the part is an editor and does not implement IShowInSource, then a context is created from the editor's input and selection (using editor.getEditorInput() and editor.getSite ().getSelectionProvider().getSelection(), with the appropriate null checks). To list target parts on a perspective, use <showInPart id="..."\> elements in an extension off of the org.eclipse.ui.perspectiveExtensions extension point. The source part can provide a list of target parts by implementing IShowInTargetList (either directly or via IAdaptable).
Currently only views can be listed as targets. Targets must implement IShowInTarget (either directly or via IAdaptable). IShowInSource, IShowInTarget and ShowInContext are all declared in org.eclipse.ui.part.
Thanks. The combination of the default context that is created plus the added <showInPart> elements in the manifest seem to work quite well. I notice the <showInPart> elements seem to have no bad effect in 2.0, allowing an editor to remain 2.0-compatible and still support Show In in 2.1. Perhaps that is how all extensions behave (don't complain about unrecognized elements), but I wasn't sure it would work until I tried it.
The eclipse runtime ignores unrecognized elements. Recently PDE added support for checking extensions against the schema for extension points, so it would probably generate warnings in this case. But that's only at development time.
Fixed sorting. Initial order is: targets from perspective, followed by targets from active part (eliminating duplicates). It then maintains MRU order. The last used timestamps are persisted with the perspective (including targets from parts). This is the last planned change for Show In for 2.1. If there are defects found or other issues encountered, please enter new bug reports rather than reopening this one.
