org.eclipse.ui.views
A view is a workbench part that can navigate a hierarchy of information or display properties for an
object. Only one instance of any given view
is open in a workbench page. When the user makes selections or other changes in a view,
those changes are immediately reflected in the workbench. Views are often provided to support a corresponding editor.
For example, an outline view shows a structured view of the information
in an editor. A properties view shows the properties of an object
that is currently being edited.
The extension point
org.eclipse.ui.views
allows plug-ins to add views to the workbench. Plug-ins that contribute a view must register the view in their
plugin.xml file and provide configuration information about the view, such as its implementation class, the category (or group) of views to which it belongs, and the name and icon that should be used to describe the view in menus and labels.
The interface for views is defined in
IViewPart
, but plug-ins
can choose to extend the
ViewPart
class rather than implement an
IViewPart
from scratch.
We implemented a minimal view extension in the hello world example. Now we'll look at one that is aware of other workbench views and responds to user navigation and selection
changes in the workbench. First,
let's take a look at the declaration of the extension in the plugin.xml.
<extension
point="org.eclipse.ui.views">
<category
id="org.eclipse.ui.examples.readmetool"
name="%Views.category">
</category>
<view
id="org.eclipse.ui.examples.readmetool.views.SectionsView"
name="%Views.ReadmeSections"
icon="icons/view16/sections.png"
category="org.eclipse.ui.examples.readmetool"
class="org.eclipse.ui.examples.readmetool.ReadmeSectionsView">
</view>
</extension>
This should look pretty familiar. We see that a new view, ReadmeSectionsView, is contributed to the workbench. The
view id, name,
and
category are specified as we've seen before. An icon is also provided
for the view, using a path relative to the plug-in's installation directory.
Let's look at the ReadmeSectionsView. You can show any view in the
workbench by choosing
Window > Show View > Other...
and selecting the view from the Show View list.
When we show the ReadmeSectionsView, a view with a list in it pops up.
The list is empty unless we click on a file with an extension of .readme, in which case
the list is populated with sections from the readme file.
How does the plug-in recognize the readme file and how did it know about selection changes? If we can track down
the answers to these questions, we are well on our way to understanding how to build integrated workbench plug-ins.
We'll start with the familiar createPartControl
method. As we saw in the Hello World example, this is where the widgets
that represent a view are created. We'll ignore some of the code to get
started.
public void createPartControl(Composite parent) {
viewer = new ListViewer(parent);
...
// add myself as a global selection listener
getSite().getPage().addSelectionListener(this);
// prime the selection
selectionChanged(null, getSite().getPage().getSelection());
}
The view creates and stores a ListViewer and registers itself as a selection listener
on its page. It obtains the page from an
IViewSite
, which contains information about the view's context, such as its workbench window,
its containing page, its local services, and its plug-in. When we are notified of a selection change, what happens?
The following code is executed:
public void selectionChanged(IWorkbenchPart part, ISelection sel) {
//if the selection is a readme file, get its sections.
AdaptableList input = ReadmeModelFactory.getInstance().getSections(sel);
viewer.setInput(input);
}
It looks like the ReadmeModelFactory class is responsible for turning the selection into readme
sections and these sections are input for
the viewer that we created in the createPartControl
method.
But how did the viewer populate its list widgets? For now, let's assume that once the viewer was told its input element, it knew how to populate
its list widget with the information - it is a ListViewer, after all. If you must know right now what this viewer is all about, go to Viewers.
We still do not know how readme files are detected or where the file's section
information comes from. A quick look at the
ReadmeModelFactory sheds some light.
public AdaptableList getSections(ISelection sel) {
// If sel is not a structured selection just return.
if (!(sel instanceof IStructuredSelection))
return null;
IStructuredSelection structured = (IStructuredSelection)sel;
//if the selection is a readme file, get its sections.
Object object = structured.getFirstElement();
if (object instanceof IFile) {
IFile file = (IFile) object;
String extension = file.getFileExtension();
if (extension != null && extension.equals(IReadmeConstants.EXTENSION)) {
return getSections(file);
}
}
//the selected object is not a readme file
return null;
}
We check the selection to see if it is a structured (multiple)
selection. (The concept of a structured selection comes from JFace
viewers.)
For the first object in the selection, we check to see whether it is a file (
IFile
)
resource. If it is, we check its extension to see if it matches the ".readme"
extension. Once we know we have a readme file, we can use other methods to
parse the sections. You can browse the rest of ReadmeModelFactory,
MarkElement, and DefaultSectionsParser for the
details about the file parsing.
We've covered a lot of common workbench concepts by studying this extension. Now we'll move on to some other workbench extensions and examine how your plug-in can further contribute to the workbench UI.
