Community
Participate
Working Groups
Provide a general purpose navigator. The Eclipse Navigator view presents a view of resources in the workspace. The Eclipse Platform should provide a more flexible, general purpose, extensible navigator infrastructure that would make it possible to show other objects as well (like an the extended physical view provided by Windows Explorer). [Platform UI, JDT UI] [Theme: User experience]
An analysis of Navigator like views in WSAD shows: -most views have copied large parts from the platform ResourceNavigator -one implements IResourceNavigator -some implement most of the customization (actions, content/label providers) in the subclass of *TreeViewer* with the subclassed ViewPart doing hardly anything It appears that all these views should be able to subclass the ResourceNavigator. The shortcoming here is the lack of a clear subclassing and customization path, mainly the doc is lacking. The navigator should: -allow for action customization, via factory methods and/or action groups that can be set via API. -provide a factory method to get status line text. Hook selection listener and handle status line update for the subclass. The perspectives/views I looked at are Component Test Perspective (DefiniitionExplorer, ExecutionExplorer), Data Perspective (DBAResourceNavigator, DBAExplorer), Server Perspective (ConfigurationView), J2EE Perspective (J2EEView, WebViewPart)
In addition to understanding how best to support the creation of Navigator-like views through subclassing, we also want to understand: - how to generalize the Navigator so that we don't need to have duplicate views for minor functionality changes - come up with recommendations for when to use or customize the Navigator vs. write your own view
An initial proposal for this plan item has been posted on the Platform UI home page. Please see http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout% 7E/platform-ui-home/navigator-proposal/general_purpose_navigator_proposal.html
Some of the feedback suggests that a universal navigator view would be the ideal solution to the scalability problem. That is, a single navigator view that can present individual folders specific to the contents instead of allowing plugins to define customized navigator views that can be switched to depending on work context. One plugin could contribute a presentation/content provider for Web projects, another could contribute one for C/C++ projects, all to the same view. Furthermore, this would allow different presentation of the same content depending on context/perspective/user option. E.g., a folder within a Java source folder could be shown as a package or as a simple folder resource. This approach would avoid switching views altogether. Views that heavily change the presentation at the root level, e.g., there are categories instead of projects should still be supported, possibly still as separate views. We should be able to support this kind of universal navigator view with the mechanisms we discussed so far. We should consider the benefits and drawbacks of such a universal navigator view from a usability point of view.
Created attachment 5260 [details] Screen shot of navigator-like views in WebSphere Studio Enterprise Developer The z/OS Projects view shows local workspace projects as well as remote projects on different hosts. Containers in the remote projects are used as filters that retrieve a set of elements from the remote location when expanded. The z/OS Systems view on the right is similar but does not allow all the actions that the Projects view does (it also seems to use categories instead of a plain project list).
Dani says: A scenario where we had to make an additional navigator-like view was the Java Browsing perspective: the Projects view is a Package Explorer where the user only sees projects and its package fragment roots. It should be possible to configure the general purpose Navigator per perspective. Nick replies: Although we are discussing the idea of the changing the presentation of the general purpose Navigator view depending on which perspective you're in (or perhaps based on some other context) , I know that some users of the Java Browsing perspective also choose to show the Package Explorer, or use it in place of the Projects view. It would be good to hear from those users, and understand the rationale behind this usage. Are there any other differences between the Package Explorer and Projects view?
The general purpose Navigator and views in general should be customizable per perspective. Here are two use cases: - In the Java Browsing perspective I use the Package Explorer and filter Java files. This gives me access to non-Java resources inside the Java Browsing perspective. The different filter settings are the only difference to the Package Explorer used in the Java perspective. However, each time I switch from Java Browsing to Java perspective I have to adjust the filter settings. - I might want to use different default filter settings when using the Problems view in the Java perspective than I would want to use in a Problem Browsing perspective. Some background: The Projects view is a Package Explorer with a content provider that does not show files and that only lets you drill down to the level of package fragment roots. When implementing the Java Browsing perspective we thought about using the Package Explorer in the Java Browsing perspective but rejected it since the out of the box behavior of the Java Browsing perspective would have been bad. Summary: If the general purpose Navigator wants to be a success then it should be customizable per perspective. The code which allows the general purpose Navigator to achieve this should be available for other views as well.
A document outlining the proposed design of the General Purpose Navigator, the prototype plugin itself and an example plugin have been posted on the UI team proposals page. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout% 7E/platform-ui-home/docs.html Once loaded from the jar the org.eclipse.ui.examples.navigator plugin will add a "Common Navigator" view in the "Other" view category. This example uses the prototype code to demonstrate various view contributions. You are encouraged to review the design and provide feedback for the further refinement and devlopment. Feedback is welcome on the platform-ui-dev mailing list and in this bug report.
The concept sounds great be there is something lacking. Let me explain our situation. We have specialized Java projects which are signified by a new nature. We have meta files in one of the source folders that is XML based and it is parsed into objects. We want to be able to display these objects in the view and not the files that they were read from. We also want to display the Java files that are associated in the projects like the Java Navigator would display them. We go a step further and group the objects into main groupings in our navigator based on the set of specialized projects that we support. Within each main grouping, we present the root object from each meta file and then all of its children, and so on and so forth. The Java Navigator structure would be imbedded in this structure (today we cannot do this). It would be nice to be able to switch from this object structure representation to a straight Java Navigator respresentation showing all Java projects. In the current design, it sounds like the Java content provider would always win since it supports the most natures. Is this correct? With this design, will we be able to do the large grain groupings like we want?
We are planning to replace the IActionFilter mechanism used for extension enablement/selection with something more powerful like the property testing outlined in the "Participating to Refactorings" proposal. This would allow you to test whether a project has a particular set of natures and only those natures. Even now you could just specify a higher priority for your extension that enables for the Java nature and your special nature. This would override the Java extension but you could still use the Java content provider to get Java elements. To emphasize the direction we're taking with our design. For the logical workspace presentation you mention you could either create a separate general purpose navigator view that shows categorized content or add your categorized content as additional root elements to the Common Navigator (in addition to all other root elements supplied by other extensions). The latter approach allows you to define filters as a way to toggle between category view and regular project view.
An updated version of the General Purpose Navigator framework has been posted on the Platform > UI Team > Proposals page. The design document outlines the current design of the framework, discusses issues, and provides an overview of the example plugin code.
Reassigning to Nick since he is taking ownership of Navigator
We published some minor clarifications and corrections to the design document and to the example plugin.xml as well as to the example provided in the org.eclipse.ui.views.navigator.navigatorContent extension point schema.
Status update: since Milestone 4, this work has been put on hold to allow us to devote resources to higher priority plan items. This plan item is still "Proposed", not "Committed" on the 3.0 plan: http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_0.html Although we would like to resume this work for 3.0, we cannot commit to it at this point in time.
One thing I'd like to see is a viewer that can handle multiple items for the same model element. Example model tree: Project Container Resources Members "Logical" (visual) tree: Project Container Group Resource Member1 Member2 Member3 Member5 Member3 Member4 Member4 MemberX MemberY Noticed the "loop"? Thats because our model doesn't make sence by simply presenting it "as is". Instead it must be presented with a logical ("flow") view. I solved this by providing a custom TreeViewer implementation which overwrites and duplicates lots of code of TreeViewer, AbstractTreeViewer and StructuredViewer. Mostly because of "final" and/or "private" methods. Allthough the mapping is some kind of generalizes in StructuredViewer (protected methods for map and unmap) the map is still accessed directly a lot.
deffering
Key questions: - Are you showing the workspace model (projects, folders, files) that the IDE uses (provided by org.eclipse.core.resources) plug-in, or the actual filesystem model, or some other model? I show the workspace model in a default project and let the user learn about 'Project' from the File menu. - Would you want to reuse the Resource Navigator exactly as-is (same presentation, actions, etc), or only parts of it? Which parts? I use the navigator as-is to give the user a view of the workspace filesystem. The Navigate menu and the Software Updates defaults that end up in the Help menu via the resulting dependencies are the most problematic contributions to explain away (or modify) for our audience. - If there was a generic navigator view in the IDE (e.g. showing plain projects the way the Navigator does, but showing Java projects the way the Package Explorer does, and likewise for C projects, Web projects, etc), would you want to integrate with it, or would you want to reuse the underlying infrastructure to do your own view? A navigator/explorer that could show the project/object views of multiple kinds of files would be very useful.
We are developing an RCP app that we would also like to distribute as an Eclipse plug-in. We are currently struggling with how to provide navigation of our resources - and the main problem is that the built-in Navigator is file-based. The first issue is that our data model could be coming from a remote filesystem or a database. To solve this, we would like to be able to plug-in additional content providers to an existing workspace. The second issue is that a single file-based resource consists of a hierarchy of sub-resources. While we could use something like an Outline view, this requires the user to constantly swtich between the two. In our users eyes, this is cumbersome. To address this we would like to be able to plugin child content providers onto any workspace resource. With these two solutions, we should be able to use a single navigator, regardless if our app is running as a standalone RCP app or an Eclipse IDE plugin. As it stands today, we may have to clone much of the Navigator code and provide it as the default navigator in standalone mode and as an additional view in plug-in mode.
For our applications (entering business data) we often use a navigator tree for editing customer data. Additionally tabs are used to display the user's position. E.g. ----------------|account data|------------------ customer data addresses telefone data account data account history ... I could imagine that a Resource Navigator framework for RCP automatically selects for each tree entry the configured view to edit the data.
We've spent quite some time building what may amount to a general-purpose navigator as part of a research project in the University of Portsmouth and wonder if the experience (or some of the code) might be of use in this instance. The basic requirements were realized when we were trying to represent what initially appeared to be hierarchical data, but which upon examination showed itself to be a graph. The result is a system which uses RDF to store content and metadata, which can be provided from any participating plugin. The presentation of store content is handled by an Explorer View, which uses the RDF store to both define the tree structre and provide dynamically customized content. If it's useful to anyone, the code is on sourceforge, and there's a mailing list which can be joined through http://rdfx.org/mail/
I am currently developing a plugin-in that is supposed to be used in experimental information retrieval. For this I need something similar to the ResourceNavigator to manage input/output data for each experiment, but without the connections to the ide plugin, i.e. a simple, resource-based navigator with projects as root items. Inside the projects there should be mixed content, meaning real files and virtual objects. My situation seems similar to the one Daniel Berg describes in comment #9: I also have xml files which need to be parsed into objects and then displayed. Therefore I very much like the approach of extending the basic navigator via navigatorContent, navigatorViewer, and navigatorActions. Here is an example of what I would like my navigator to look like: -Project1 |-Run1 <-------- real directory in the workspace |-Queries <-------- real directory, but linked from outside workspace |-QueryList <-------- a xml file parsed into an object |-Query1 <-------- xml element now attribute of the list object |-Query2 |- ... For now I will probably use a simple tree viewer to display my xml-based objects in a fixed location, but the goal is to provide a navigator as described above to be flexible while conducting experiments maintaining a certain freedom to arrange files and objects in projects as needed.
I would like to try and move forward on this plan item in the 3.1 timeframe, but I am not sure of the best course of action. In reading past discussions and talking to people about this topic, I see three common goals: 1. Reduce the number of navigator-like views in Eclipse-based products. 2. Share code between navigator-like views. 3. Provide a system for content providers that can be used in Navigator-like views ("render this element and any children like the Java package explorer does"). Providing a single extensible navigator view attempts to reduce the number of views by having clients contribute to it rather than write a new view, and achieves code sharing by making it as featureful as possible. I am not entirely convinced that this is the best approach: it only achieves code sharing among navigator views that are willing to live with whatever limitations this generic view might have. As well, while content providers for this view could probably be extended for use by other views (such as rendering search results or when browsing CVS repositories), it is not clear to me that this problem is easily solved. However, this approach does have some clear advantages: - It allows plug-ins or RCP applications which need to provide navigatable resources to not have to provide another view. - It would be a cleaner base implementation for navigators over the existing resource navigator. - A good start is already posted on the UI homepage. So, my current plan is to revive this code and try to finish it, and if anyone wants to help they're more than welcome to. If you have any thoughts or ideas on this topic, please post them here or come talk to me on IRC. I am usually on #eclipse-dev at irc.freenode.net.
Billy, On the RAD J2EE Tools Team we have taken the base provided (the one that was abandoned previously and built a generic navigator on top of that, which provides much more functionality. We are in the process of releasing this under the Web Tools Platform Project because many of our dependent components now depend on the viewer we provide. We are the process of identifying the areas we would like to refactor early in the WTP release before there are many new dependent components. We are open to discussions in coordinating the development of this general navigator and pushing it down into Platform UI. Our current implementation allows clients to: -- contribute navigator extensions which add content based on action expressions, -- add actions (including some hooks for programmatic control of the menu which is displayed), -- vary action bar contributions on selection events (since different content extensions might need a different Copy/Paste/Delete etc implementation to be invoked by the workbench), -- implement pluggable drag and drop handlers based on action expressions -- provide link with editor support which is independent from the extensions (so activing a single editor might actually cause multiple items to be selected in the tree -- provide custom filters (from extensions) and absorb filters defined by other views (Resource & Java Package Explorer) -- enable/disable individual navigator extensions based on user preferences We have also implemented a resource extension and Java extension which each mimic the behavior of their respective viewers. We also have some support for delayed loading/display of content extensions using Jobs, but this should be revisited. At what stage are you currently with picking up the original prototype by Knut et al?
Michael, We are aware of the WTP navigator and have played around with it. I am still surveying work and have not yet committed to any particular codebase or approach. What are your thoughts on the success of your generic navigator? Do you believe that it has replaced what would have been even more navigator-like views? Also, do you believe that this is a good platform for replacing the Navigator and Package Explorer views in Eclipse?
+1 We have our own "navigator" as well, and being able to use a general navigator would be a great 3.1 present :)
Morten, can you provide more details? What model(s) does your navigator view present (feel free to abstract away from any confidential details)? Is it open-ended? Would you want to integrate with other models (e.g. projects in the SDK)? Are there any view-level settings (e.g. sorting, filtering, other modes) that might be problematic in a shared view?
Our model lives on a shared remote server; there are no physical files, but the structure is similar same as a file system. There are resources/objects in containers/folders of different types. Its not rocket science :) So we have our own navigator showing this remote repository which has similar features as the resource navigator does (filtering, connect to multiple servers [could be considered projects], cut/copy/paste, create "folders" etc). Many object types also have their own specialized contributions of course (some are runnable, possible to preview etc). A large part of our user base are very non-technical, so relying on any kind of sync scheme (like team providers would give us) just complicates their work. So although I can open/edit/save objects fine, since we have to have a separate navigator, it still currently doesn't feel like we've integrated with Eclipse. If people make other "projects" it ends up in this other resource navigator etc. Integrate the Navigator to have our servers right next to custom projects would make me feel we're 80% of the way of full integration. And of course, we had to build a lot of navigator code to get one working. So what I'd like to see is: - Create own top level Folders / Projects - Have full control over the data model (folders and elements) and get filtering and sorting interface for "free". - Have hooks for move/rename/copy/cut/paste etc .. so that if possible to copy/paste between these custom projects. - Not rely on extentions (but content-type) to open editors as we don't have extentions on our objects. Of course what I really would want probably, is to model our model as "logical resources" and integrate that way (whole other discussion on another bug :)), but I think this is a step in the right way (maybe even a better direction because it might be much simpler and solving 80% of the problem at least for me). Currently the "resource navigator" is forcing the use of Eclipse resources only, and by implementing this feature, there is one more thing I can integrate fully. I'll probably look into the WTP navigator if the code is in cvs..
See bug 69708 for some interesting ideas on grouping.
See also bug 109194.
The Eclipse BIRT project are also interested in having a more extensible version of the Navigator.
I recently completed some usability explorations that included this navigator. If the owner of this bug is interested, they are welcome to contact me directly for more information.
In case this bug is still active, let me just note that my former project had a requirement similar to that in https://bugs.eclipse.org/bugs/show_bug.cgi?id=36961#c20, and we wound up writing a huge amount of code; had we been able to subclass or otherwise customize a Nav View, we would surely have done so. Also, in my new project, having a simple NavView that filtered to show just our file-types might be handy (for now we will just use File -> Open and the file dialog, and hope users don't get tangled up by opening the wrong kinds of files).
A version of the new Common Navigator has been released to the 3.2M3 build. The current framework is composed of two plugins: org.eclipse.ui.navigator (Core Framework) org.eclipse.ui.navigator.resources (Resource Extension) An experimental navigator has been dubbed 'Experimental Resource Navigator' and released as well; you can find this viewer under the 'Basic' category. The current API needs further definition, so it's currently tagged as experimental. More documentation for the schema extension points is a top priority for this milestone. The framework is a port of the WTP Common Navigator framework. Interested parties can search for bugs that have "[CommonNavigator]" in the title (without the quotes).
The presentation slides from EclipseCon are available at http://eclipsezilla.eclipsecon.org/php/attachment.php?bugid=260.
fixed for 3.2
I have started a <a href="http://scribbledideas.blogspot.com">blog</a> to provide some tutorials for the adopter community. Please feel free to add comments and make requests (particularly on <a href="http://scribbledideas.blogspot.com/2006/05/where-do-we-go-from-here.html">this post</a>). Thanks.
I think it would be best to have all that data on the wiki? If everybody starts their own blog on the thing they work on, then the end user can find its way to the information.
Eventually, I'll boil down what's on the blog into the wiki or into the Eclipse Help system, but for now I would like a more interactive medium. Blogs lend themselves for users to easily add comments related to the material, without directly changing it. Also, the wiki pages don't easily expose rss feeds (if at all) whereas a blog does it automatically. I am happy though to add a pointer from the wiki to the blog, but in this phase, I feel like it's more valuable to have the user feedback loop as the tutorials grow. I added http://wiki.eclipse.org/index.php/Common_Navigator_Framework to add a pointer from the wiki to the blog, but there wasn't any obvious place on the wiki aggregating tutorial type information across all projects, so I added a pointer from the Platform/UI page (http://wiki.eclipse.org/index.php/Platform_UI).
> blogs lend themselves for users to easily add comments related to the material, without directly changing it. So do bugs (see articles about https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community) :-)
