Lots and lots has already been told about the Common Navigator framework. I'm not going to add any more explanation about the framework, but will tell you a tip on how to easily create one with the Workspace resources as the default contents.
Open your plugin.xml and go to Extensions tab. Click on Add and select the Extension Wizards. Select 'Common Navigator' and click Next.
Configure the options and press Finish.
You are done. Can it get any simpler than this?
In case you didn't find the Common Navigator in the list of Extension Wizards, you may want to download the Cypal Eclipse Utils and drop the jar into your plugins/dropins folder.
For those who are interested the background:
Few days back, I was working on creating a Common Navigator for an RCP application. Just like most of the RCP apps out there, I want to start with Workspace resources first. It didn't work as expected. I spent around 30 mins debugging only to find out that I've missed the "org.eclipse.ui.navigator.resources" in the dependencies. That is when I thought how good if some has already implemented a template for this extension. Instead of complaining, I thought why not to create on. Less than an hour of hacking existing PDE Extension Wizards, the base code was ready. Another half-an-hour at Google Project Hosting, the download is ready to serve. Thanks to PDE guys and Google for making things much simpler.
I plan to add few other handy utilities like this. Let me know the usefulness of this one.
[Update] This funcationality has been checked into Eclipse CVS. You should be seeing this wizard in 3.5 from M1 onwards. To have this wizard in 3.3 or 3.4 you can download from the above link and use it.
Jun 30, 2008
Jun 22, 2008
Honoring Macs with SWT.SEARCH style bit
I love both Eclipse and Mac, but the combination of these two some how comes out with glitches. Although UI components are native, there are several things a Mac user will be missing in Eclipse to have the native experience. Installer shipped as .dmg or the application in a single .app file or lack of Sheet support in SWT - just to name a few.
But on the other side, SWT provides support for native search fields with the SWT.SEARCH and SWT.CANCEL. The workbench already uses these flags in many places, but not in the FilteredItemsSelectionDialog. So If you use the Open Resource or Open Type or any other derived dialogs, you would get something like:

Had our workbench used the sytle bits, it would look like:

Adding the SWT style bits to the text field doesn't make any difference on other OS, but it does adds a little difference in Macs. So next time you are coding for a search field, do remember to add these style bits and make your Mac users happy.
Note 1: Whenever someone reads a complaining post like this one, the first comment would be "did you raise a bug?". So before anyone comments, yes, I did raise a bug and submit a patch. Its accepted and should be available in M1 of 3.5. Yeah, you read it right. I'm blogging about Eclipse 3.5. See Ganymede is yet to hit the download servers, but its already history now :-)
Note 2: My bug was not the first resolved bug for 3.5, but certainly this blog post will be the first on 3.5 :-)
Note 3: What is the official name for 3.5 release train? I tried to make a guess, but couldn't. Anyone?
But on the other side, SWT provides support for native search fields with the SWT.SEARCH and SWT.CANCEL. The workbench already uses these flags in many places, but not in the FilteredItemsSelectionDialog. So If you use the Open Resource or Open Type or any other derived dialogs, you would get something like:

Had our workbench used the sytle bits, it would look like:

Adding the SWT style bits to the text field doesn't make any difference on other OS, but it does adds a little difference in Macs. So next time you are coding for a search field, do remember to add these style bits and make your Mac users happy.
Note 1: Whenever someone reads a complaining post like this one, the first comment would be "did you raise a bug?". So before anyone comments, yes, I did raise a bug and submit a patch. Its accepted and should be available in M1 of 3.5. Yeah, you read it right. I'm blogging about Eclipse 3.5. See Ganymede is yet to hit the download servers, but its already history now :-)
Note 2: My bug was not the first resolved bug for 3.5, but certainly this blog post will be the first on 3.5 :-)
Note 3: What is the official name for 3.5 release train? I tried to make a guess, but couldn't. Anyone?
Jun 4, 2008
Opening an editor without IFile
When we use Eclipse, we are used to the notion of editors operating on a workspace file. But workspace and resources are optional for an RCP application. You might have to invoke an editor on a non-file object like a database record or an in-memory object. So one of the frequently asked questions is how to open an editor with a file? This tip explains how to do that.
For this I'll be using a simple sting as the model to be edited and use the default text editor to edit it. You can switch the model or editor with whatever you prefer (say a result of a database query edited in a form based editor).
Editors in Eclipse know nothing about the files/actual objects they edit. They always operate on IEditorInput. There are standard implementations like FileEditorInput (for workspace files), FileStoreEditorInput (for files on disk). In our case we have to create our own implementation. I have extended the IStorageEditorInput to make things easier:
public class StringEditorInput implements IStorageEditorInput {
private final String inputString;
public StringEditorInput(String inputString) {
this.inputString = inputString;
}
public boolean exists() {
return false;
}
public ImageDescriptor getImageDescriptor() {
return null;
}
public IPersistableElement getPersistable() {
return null;
}
public Object getAdapter(Class adapter) {
return null;
}
public String getName() {
return "input name";
}
public String getToolTipText() {
return "tool tip";
}
public IStorage getStorage() throws CoreException {
return new IStorage() {
public InputStream getContents() throws CoreException {
return new StringBufferInputStream(inputString);
}
public IPath getFullPath() {
return null;
}
public String getName() {
return StringEditorInput.this.getName();
}
public boolean isReadOnly() {
return false;
}
public Object getAdapter(Class adapter) {
return null;
}
};
}
}
In a command, I've opened the text editor with this call:
workbenchPage.openEditor(new StringEditorInput("text to be edited"), "org.eclipse.ui.DefaultTextEditor");
The output:
Hope the above picture shows where the various strings I've used in the class goes into. I'm returning null for the getPersistable() method. So you cannot Save the contents of this editor. If you want to do that, you have to return an instance of IPersistableElement. Write back to the database or send a Http Post message - the implementation is left to your application.
For this I'll be using a simple sting as the model to be edited and use the default text editor to edit it. You can switch the model or editor with whatever you prefer (say a result of a database query edited in a form based editor).
Editors in Eclipse know nothing about the files/actual objects they edit. They always operate on IEditorInput. There are standard implementations like FileEditorInput (for workspace files), FileStoreEditorInput (for files on disk). In our case we have to create our own implementation. I have extended the IStorageEditorInput to make things easier:
public class StringEditorInput implements IStorageEditorInput {
private final String inputString;
public StringEditorInput(String inputString) {
this.inputString = inputString;
}
public boolean exists() {
return false;
}
public ImageDescriptor getImageDescriptor() {
return null;
}
public IPersistableElement getPersistable() {
return null;
}
public Object getAdapter(Class adapter) {
return null;
}
public String getName() {
return "input name";
}
public String getToolTipText() {
return "tool tip";
}
public IStorage getStorage() throws CoreException {
return new IStorage() {
public InputStream getContents() throws CoreException {
return new StringBufferInputStream(inputString);
}
public IPath getFullPath() {
return null;
}
public String getName() {
return StringEditorInput.this.getName();
}
public boolean isReadOnly() {
return false;
}
public Object getAdapter(Class adapter) {
return null;
}
};
}
}
In a command, I've opened the text editor with this call:
workbenchPage.openEditor(new StringEditorInput("text to be edited"), "org.eclipse.ui.DefaultTextEditor");
The output:
Hope the above picture shows where the various strings I've used in the class goes into. I'm returning null for the getPersistable() method. So you cannot Save the contents of this editor. If you want to do that, you have to return an instance of IPersistableElement. Write back to the database or send a Http Post message - the implementation is left to your application.
Labels:
guidelines,
RCP
Subscribe to:
Posts (Atom)


