Community
Participate
Working Groups
I'm trying to find out what the general consensus for a UI design concern I'm currently facing. I'm not saying that bug is a definite feature enhancement that I have on Platform/UI, but I would like to see what thoughts the Platform/UI developers have on my suggestion. I have an editor that displays things that are also displayed in the various navigators (common, resource, package explorer,etc) like web pages, files, etc. If I enable "Link with editor" on the navigator, when I click in the editor, the IResource that the editor is currently editing is shown in the Navigator. This is not exactly what I want. I would rather have the selected resource within the editor synchronize with the same display of that resource in the navigator. I was able to get this function by manually listening to selection changes in my editor, and on selection changes to set the same selection to the various resource navigation views (Really, all ShowInTarget views.) Would it be annoying or useful to have the "Link with editor" option automatically synchronize with the selection of the editor, instead of just the editors underlying resource? Alternatively, a more conservative approach for this synchronization function is something that already is found in various places inside Eclipse. You can use the "Show in..." context menu instead. This displays a context menu labeled: "Show In..." -> followed by a sub menu of the views that are ShowInTarget compatible. I see this as being an issue to all editors that also show Resources. (UML, Web, Database, etc)
This is not really my area but I do have some thought on this so here they are: The problem is that Link with Editor assumes that the editor is open on a single logical object and it's purpose is to show that object in the object's view when the editor is active. So, for a file input, the Navigator, Project Explorer or Package Explorer can show that file when the editor becomes active. For more complicated models where the object may map to multiple files, the Resource Navigator would not be able to link since it only knows about files. However, the Common Navigator (and hence the Project Explorer) has an ILinkHelper API that can be used to select the corresponding model object when the editor becomes active. What you are describing is a bit different. From what you describe, it sounds like the model object you are editing consists of several resources (i.e. files or folders) which are surfaced in the editor somehow. When the user selects one of the resources, you would like to have another view (e.g the Project Explorer) show those resources automatically. As you described, this fits well with the way Show In currently works but doesn't map well to Link with Editor. Without understanding your specific scenario (since you haven't provided it), I'm not convinced that what you are asking for is benefitial. If we assume that you have a content provider in the Project Explorer, the user would expect the linked Project Explorer view to show the model object you are editing (e.g a multi-file diagram) if it is Linked. However, if the user selected something in the editor, you would like the view to show the resource corresponding to what is selected. There are two problems I can think of with this scenario: 1) Depending on how many resources are associated with the editor and the selection patterns of the user, this could result in a bust of selection changes in a linked view which can be distracting (not to mention the potential effect on performance). 2) In many logical models, there is no clear link between the element being edited and the resources that make up the element. In this case, it is not clear that you want something like Link with Editor to should these resources. Having an explicit command like Show In is probably better. Having said all this, I'm not trying to say that the problem you are faced with isn't real but mapping between different models (which is what we are talking about) is complex. I think it is easier to discuss this type of thing when we are presented with concrete scenarios instead of general solutions (i.e. a general solution presented without a concrete scenario is rarely addressed). If you could describe your specific scenario, perhaps we could then discuss possible solutions.
In my situation, I'm talking about a web diagram editor. This web diagram editor displays things like JSP/HTML files, struts technology "Action Mappings", Navigations between pages (and actions) as well as faces technology "actions" which are a combination of a named POJO and an method (in the named POJO). The common navigator has only a subset of the "extra" information displayed in the model (it shows "Struts action mappings" - and it doesn't show Faces things.) The common navigator does not show the contents of the diagram as a tree view - it shows a super-set (really: all available action mappings in a project.) As such, I think I tend to agree with your concerns. 1) There may be a lot of different selections going on in the Editor. Although I agree that this can be annoying, remember that "Link with editor" can be turned off pretty easily (1 click.) Still - I think I would be annoyed by this. 2) The "no clear link" concern is definitely something I'm going to face. In the case of a faces actions - we could select the definition of the POJO alias and/or the the action method inside of the POJO itself. Our 1 object in the diagram maps to 2 objects in the viewer. Due to these issues, I think the "Show in Target..." is the best approach to take in this situation. Thanks a lot for taking the time to chime in on this conversation.
Min - are you happy with the feedback, or is there something Platform/UI should do to help you?
I'm happy with this feedback. I will be using the ShowInTarget method instead of going with the "Link with Editor" approach. One thing I would like to have done is have the ShowInMenu and ShowInAction's be made into api. I've opened a sperate bug for that: bug 182018
Remy is now responsible for watching the [EditorMgmt] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
