Eclipse Tips

Eclipse Day in Bangalore - registrations open

2010-02-08T11:07:00.000+05:30

Today the registrations open for Eclipse Day in Bangalore. The entry is *free*, but you have to register to get the ticket. The tickets are limited, so hurry up.

The deadline for talk submissions are fast approaching and you have only one week left. Again, hurry up :-)

We also have a calendar published in the wiki. You can subscribe to it in your calendar, so you won't miss any dates.

Launching www.eclipse-tips.com ...

2010-01-23T00:03:00.001+05:30

Its due for a long time :-) Ever since I purchased this domain, I wanted to create a site as a resource for Eclipse Plug-in developers. With little bit of hacking over the two weekends, the website is up and running with bare minimum content. I'll be adding more content from this blog and elsewhere, meanwhile you can check out the layout and other stuff.

Coolest and most useful thing for the visitors would be Eclipse Search. Even though the results portion occupies a significant space in the prime area, I decided to have it because its very handy if you want to search for something. And the whole interface is very nice (courtesy: Google Ajax APIs) Whether you want to search for a particular class in the repository or search for an xml editor plugin or a blog entry about Tray Item, its available in few clicks.

Every article has a pdf & print icon. So if you need an offline copy, its available. This was not possible earlier with this blog.

And last, but not the least, for international visitors, the translate option is available in the bottom bar. With just two clicks you can translate to a language of your choice - without reloading the page. Again, done thru Google Ajax APIs. (you got to love this web stuff - esp when you can implement a feature without writing a single line of code :-) )

Mail me/leave a comment if you have any comments/suggestions

Eclipse Day in Bangalore

2010-01-19T10:58:00.001+05:30

About

Last year we had a successful Eclipse Demo Camp in Bangalore. In a post-event survey, many people said that they are willing to attend a full day event, and here we are.

Me and Ankur are planning for an Eclipse Day in Bangalore on April 9th. This year's theme would be "Eclipse Plug-in Development". It will be a full day event. Unlike the Demo Camp, there will be three types of talks (Long talk, Short talk and Lightning talk) and we have a committee (Ketan from ThoughtWorks, Anshu Jain from IBM & Madhu, an Independent Eclipse Consultant) to review the proposals. So you will get to attend only the best out of the proposals.

Want to attend?

Just like the Demo Camp, the entry is free. However you have to pre-register and the registrations open on Feb 1st. There are only 100 seats available, so you want to register as soon as its opens. Registrations can be done from here.

Interested in presenting?

Fill in this form and submit your proposals. The review team will get back to you.

Sponsoring:

Last but not least, sponsors. We are reaching out various companies for sponsorship. Your company can support the event by sponsoring it. It also had added advantage of:

* 5 reserved attendee seats
* One lightning talk
* Ads & stall space in the venue (banners and contact booth at sponsor's cost. We will help provide as much space possible.)
* Mention in various promotions on Eclipse websites as mentioned here.

Do contact me or Ankur if you have any questions.

Toggle Commands the toggle other contributions

2009-12-21T22:36:00.002+05:30

Found this one on Phil's blog. Republishing it with his permission. Thanks Phil!

Introduction

This is a follow up to Commands Part 6: Toggle & Radio menu contributions of fellow blogger Prakash G.R.. He described how to use command toggle and radio states. Here I will show you how to drive other contributions in the Eclipse Workbench using a toggle command.

What we want to achieve

I needed to show another toolbar button when a certain toggle command was executed. Imagine something like "Show clock" that will show or hide a little clock in the worbench window status bar.
Such contribution can be easily added using a menuContribution for the trim area. First create a toolbar in the trim area and then contribute controls/commands to this toolbar also using the menuContribution extension point.
Since we want the clock contribution

<menucontribution locationuri="toolbar:mytoolbar">
<control class="test.ui.clocl.internal.ClockControlContribution" id="test.ui.clock">
<visiblewhen checkenabled="false">
  <with variable="activeWorkbenchWindow">
    <test args="test.ui.clock.ToggleCommand"
      forcepluginactivation="true"
      property="org.eclipse.core.commands.toggle"
      value="true"/>
  </with>
</visiblewhen>

</control>
</menucontribution>

That will create a toolbar contribution that is only visible when the test.ui.clock.ToggleCommand is in the "true" state, when its checked.

Lets define the command:

<command defaulthandler="org.eclipse.core.commands.extender.ToggleCommandHandler" id="test.ui.clock.ToggleCommand" name="Show clock">
<state
  class="org.eclipse.ui.handlers.RegistryToggleState:true"
  id="org.eclipse.ui.commands.toggleState">
</state>

</command>

How this command works and what the state is you have already read in Prakash's blog entry. The default handler for this command does a little more than the one in the latter mentioned blog entry. It is defined like this:

/**
* Generic command that toggles the executed command and re-evaluates property testers for the
* org.eclipse.core.commands.toggle property.
*
*/
public class ToggleCommandHandler extends AbstractHandler {

public Object execute(final ExecutionEvent event) throws ExecutionException {
  HandlerUtil.toggleCommandState(event.getCommand());
  final IWorkbenchWindow ww = HandlerUtil.getActiveWorkbenchWindowChecked(event);
  final IEvaluationService service = (IEvaluationService) ww.getService(IEvaluationService.class);
  if (service != null) {
    service.requestEvaluation("org.eclipse.core.commands.toggle");
  }
  return null;
}
}

How do toggle the visibility of the clock contribution

The connection between toggling the command and making the clock contribution visible is hidden in a property tester, that the clock contribution uses:

public class CommandsPropertyTester extends PropertyTester {
public static final String NAMESPACE = "org.eclipse.core.commands"; //$NON-NLS-1$
public static final String PROPERTY_BASE = NAMESPACE + '.';
public static final String TOGGLE_PROPERTY_NAME = "toggle"; //$NON-NLS-1$
public static final String TOGGLE_PROPERTY = PROPERTY_BASE + TOGGLE_PROPERTY_NAME;

public boolean test(final Object receiver, final String property, final Object[] args, final Object expectedValue) {
  if (receiver instanceof IServiceLocator && args.length == 1 && args[0] instanceof String) {
    final IServiceLocator locator = (IServiceLocator) receiver;
    if (TOGGLE_PROPERTY_NAME.equals(property)) {
      final String commandId = args[0].toString();
      final ICommandService commandService = (ICommandService)locator.getService(ICommandService.class);
      final Command command = commandService.getCommand(commandId);
      final State state = command.getState(RegistryToggleState.STATE_ID);
      if (state != null) {
        return state.getValue().equals(expectedValue);
      }
    }
  }
  return false;
}
}

It is defined in plugin.xml like this:

<propertytester
class="org.eclipse.core.commands.extender.internal.CommandsPropertyTester"
id="org.eclipse.core.expressions.testers.CommandsPropertyTester"
namespace="org.eclipse.core.commands"
properties="toggle"
type="org.eclipse.ui.services.IServiceLocator"/>

That means we define a new property for the namespace "org.eclipse.core.command" and the property is named "toggle". It will operate on IServiceLocator variables. Such variable that is an IServiceLocator is the "activeWorkbenchWindow" variable. Now you should understand the visibleWhen expression of the clock contribution. It should be only visible when the toggle for the clock toggle command is "true". The re-evaluation of the property testers is triggered by the generic ToggleCommand.

A little tip at the end

If you put the ToggleCommand and property tester in a seperate bundle for easier re-use in all your projects and other bundles make sure you either start the bundle at the beginning or set the "test" expressions "forcePluginActivation" to true to let the Eclipse expression framework activate the bundle for you. Otherwise the property tester is completly ignored and the clock would be always visible.

Bonus

Since the state of the toggle is preserved in an instance preference value the visibility of all associated contributions that use the property tester to check for the toggle state of the command.

Of course you can also reverse the test expression for your contributions if you have a toggle command that says something like "Hide clock".

Click here for the original entry.

Reload your plugins without restarting Eclipse

2009-12-02T00:30:00.001+05:30

When you are developing Eclipse plugins, sometimes its annoying that the changes in the plugin.xml won't reflect immediately. You need to restart the target Eclipse to see the changes. This will be painful if you are playing with trial-n-error stuff like the menu urls. In this tip, I'll explain how to make Eclipse reread your plugin.xml without restarting the target.

Create a plugin, launch as an Eclipse Application (you don't even need to Debug, just Run would do)
Check the UI contributions of your plugin.
Make the desired change in your plugin.xml. Right now, I've changed a Command's name; added a Command contribution to an existing menu; added a new view and made changes to an existing perspective

In your target, open the Plug-ins Registry view and in the pull down menu, check the 'Show Advanced Operations'

Right click your plugin and select Disable.

Then right click again and select Enable.

Since you have made changes to the current perspective by adding a view, you would be greeted with this Dialog.

Say Yes. There you go. Now all the changes in the plugin.xml would reflect in the UI

While this may not be applicable for all the changes you make in plugin.xml, this should cover up for most the changes.

e4: First e4 RCP Application

2009-11-10T00:31:00.007+05:30

The next big thing in Eclipse is Eclipse 4.0 dubbed as e4. It will be released in 2010. That doesn't mean that the 3.x stream will be deprecated or discontinued. The 3.x releases will go on for "few" years till everyone boards the 4.0. But clearly the future of Eclipse is e4 and its already here. I'll be writing a series of blog posts on e4 and this will be the first. You can follow this blog in RSS, or email or even in twitter. I'm still learning about e4, so feel free to correct me if you find any mistakes :-)

First set up your e4 Environment:

1) Download e4 1.0 M1
2) Click e4->Generate e4 Example Project

3) Right click e4-examples.psf and click 'Import Project Set'. This should import the contacts and the photo projects from the CVS to your workspace
4) Open the contacts.product file and click the "Launch an Eclipse Application" link in the Overview page
5) Thats it. You should be running the Contacts demo.

You can play around with the css theme or code and check out the effects. When you are done, lets start an app from the scratch. The first app will have nothing more than a view (something like the 'RCP Application with a View', created by PDE Wizard). Note: If you find it hard to work with e4, you can grab a latest 3.6 build and set the e4 as the target platform and proceed with the following steps)

Step 1:
Use the New Plug-in wizard and create a new plugin. (No RCP - just plain old plugin)

Step 2:
You don't need an Activator. In the Overview tab, remove the Activator class and also delete the Activator.java file from the sources.

Step 3:
The default dependencies of this would have o.e.core.runtime and o.e.ui. In e4, we still need the core.runtime in e4, but not the o.e.ui. Remove it. Now add the following dependencies:

org.eclipse.swt,
org.eclipse.jface,
org.eclipse.e4.ui.workbench
org.eclipse.e4.ui.workbench.swt

Step 4:
Lets create a view. Instead of o.e.ui.views, now we have to use org.eclipse.e4.workbench.parts extension (which should now serve both the editors and views). The extension point would look like

<extension point="org.eclipse.e4.workbench.parts">
      <part class="com.eclipse_tips.e4.firstapp.MyFirstView" />
</extension>

The implementation class would be:

public class MyFirstView {

 public MyFirstView(Composite parent){
    
  // this shouldn't be there ideally, investigating
  if(parent.getLayout() == null)
    parent.setLayout(new FillLayout());

  Composite composite = new Composite(parent, SWT.NONE);
  composite.setLayout(new FillLayout());
  
  Button button = new Button(composite, SWT.PUSH);
  button.setText("Hello World");
  button.addSelectionListener(new SelectionAdapter() {
   @Override
   public void widgetSelected(SelectionEvent e) {
    MessageDialog.openInformation(new Shell(), "e4", "Hello e4 World!");
   }
  });
 }

}

Yes, what you are seeing it correct. It doesn't implement the IWorkbenchView or extend ViewPart. Further more, it appears that I've done one of the top 10 mistakes by not having a default constructor. Don't worry, e4 is smart. When it instantiates an object like this thru reflection, it identifies the parameters for the constructor and will pass them from the context. If more than one constructor is present, it can even identify the right one to use (more on this later)

Step 5:
Now, we have the view, lets create an RCP product that will use this view. Fire up the New Wizard and create a Product Configuration file with the basic settings. In the Product Configuration editor, give it some name and click the New for the Product. Specify some id and select 'org.eclipse.e4.ui.workbench.swt.application' for Application.

Step 6:
Go back to your plugin.xml. You should see the newly created application there. Now lets create the missing link between the product and the view - the UI model. In a typical 3.x RCP, you would have specified an application that has a run method, an initial perspective id, the layout for that perspective, the views, menus, actions thru the ActionFactory constants etc. This whole setup would require a little bit of both java coding and plugin.xml configuration. In e4, you can specify the entire UI in a model. Thats the applicationXMI. It can get as complex as your UI can be, but the simplest one looks like this:

<?xml version="1.0" encoding="ASCII"?>
<application:MApplication xmi:version="2.0" 
 xmlns:xmi="http://www.omg.org/XMI" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xmlns:application="http://www.eclipse.org/ui/2008/Application">

  <windows name="Main Window" width="200" height="100">
 <children xsi:type="application:MContributedPart" 
  id="MyView" 
  iconURI="platform:/plugin/com.eclipse-tips.e4.firstApp/icons/sample.gif" 
  URI="platform:/plugin/com.eclipse-tips.e4.firstApp/com.eclipse_tips.e4.firstapp.MyFirstView"/>
  </windows>
</application:MApplication>

There is nothing much to explain. It has got nothing more than a window and a view in it. (no menus,no tool bars, no status lines and even no stacks to hold the view) Specify this file in the parameter of the product extension:

<extension
       id="rcpProduct"
       point="org.eclipse.core.runtime.products">
    <product
          application="org.eclipse.e4.ui.workbench.swt.application"
          name="My First e4 RCP">
       <property
             name="applicationXMI"
             value="com.eclipse-tips.e4.firstApp/App.xmi">
       </property>
    </product>
 </extension>

Step 7:
You are all set to go. Switch to the Dependencies tab of the Product Editor and add your plugin. Click 'Add Required plugins' and launch. The launch will fail, because we have not included few more plugins that are required, but not specified in the dependencies (from databinding beans to renderers will be missing) The simplest way to get thru the error, is to edit the launch configuration and launch with 'all workspace and enabled target plugins'.

Now launch again, voila - there comes your first e4 RCP!

So what has happened till now? With the product & launch configuration, we are basically running the org.eclipse.e4.ui.workbench.swt.application. The application looks for the model of the UI in the applicationXMI parameter. It creates the Workbench, and asks it to render the UI from that model. Recursively, an appropriate renderer for every element in the XMI file is found, and its asked to create the UI. Finally you get the app:

Eclipse Tips on Twitter !

2009-11-03T15:20:00.000+05:30

Get (a different set of) Eclipse Tips in twitter: @Eclipse_Tips. If you are still in the RSS reader era, get the feed here.

Associating a Command with a Job

2009-10-28T00:29:00.001+05:30

Earlier we saw how to associate an Action with a Job. Now you can associate a Command. Its very similar - use the constant to set a property on the job:

ICommandService service = (ICommandService) serviceLocator.getService(ICommandService.class);
Command command = service.getCommand(commandId);
ParameterizedCommand parameterizedCommand = new ParameterizedCommand(command, null);
job.setProperty(IProgressConstants.COMMAND_PROPERTY, parameterizedCommand);

You have to specify either the ACTION_PROPERTY or COMMAND_PROPERTY, but not both. If you specify both, neither of them will get executed.

Note: You need a 3.6 M3 or a latest I-Build for this to work.

Eclipse Demo Camp, Bangalore

2009-09-23T11:24:00.000+05:30

Its back :-)

We are planning to organize a Demo Camp sometime in November. Date, time and venue to be decided. Since IBM's Eclipse team has grown since last Demo Camp, this time, you get a very good opportunity to learn right from the source, on whats coming up. From p2 to b3 and e4 (Am I the only one who thinks that things can be named better?) we can give a good number of demos/presentations. But we don't want to make it as the Big Blue show, so we need few contributions from the community as well. We are glad that Madhu and Anil have already signed up with some topics. I would encourage you to add a demo on what you are working on. Even if not sign up as an attendee, its a nice chance to meet other Eclipse plug-in developers and see what they are building with Eclipse.

http://wiki.eclipse.org/Eclipse_DemoCamps_November_2009/Bangalore

Catching up with Milestones and I-Builds

2009-09-22T12:51:00.007+05:30

Helios M2 is released. Now the biggest problem for the early adopters would be how to catch up with these milestones. Every time, you have to download the milestone build, and then update it with all your required plugins (svn, mylyn, etc). If you are on the I builds, then you have to do this on every week. If you feel that its a painful process, here is a tip.

The p2 repos for Eclipse are not only for the stable releases, but also for the Milestones, I Builds and Nightly builds.

Milestones: http://download.eclipse.org/eclipse/updates/3.6milestones
I-Builds: http://download.eclipse.org/eclipse/updates/3.6-I-builds
Nightly Builds: http://download.eclipse.org/eclipse/updates/3.6-N-builds

The build schedule is available here.

Go to your Preferences and add the required repo in your Available Software Site preferences (and disable all others, it will be slow to update).

Also enable the automatic updates. You are done. Whenever there is a new Milestone (or an I-Build), then your Eclipse gets updated automatically to it and you don't have to worry about installing other required plug-ins.

Enjoy with the latest and greatest without any pains :-)

Back to the basics: Display, Shell, Window ...

2009-09-15T22:39:00.002+05:30

Every Eclipse plugin developer has to deal with Shell and Window, but sometimes doesn't understand the difference between these two. In this tip, I'm trying to explain the basic things: Display, Shell, Window, Dialog, Workbench, WorkbenchPart, WorkbenchSite and WorkbenchPage. Yeah, I know, its probably the boring post you can read in this blog, if you are little bit experienced in these areas.

Display:

This class is the link between SWT and the underlying OS. It manages the interaction between widgets and the OS. The primary task for this class is to maintain the event loop (readAndDispatch()). Unless you are writing a plain SWT app, you won't be using that. The most common methods you would be using in this class are asyncExec(), syncExec() and timerExec(), which allows you to run a piece of code in the UI thread. (aka user interface thread or display thread)

Shell:

Shell is the "window" that you see in your desktop. The one that has a title, maximize, minimize, restore and close buttons. A shell can be either a top-level shell (no parent shell) or can be a secondary shell (will have a parent shell). The style that is passed in the constructor defines which of the above mentioned buttons are displayed and also whether the Shell is modal or not. If you are on a pure SWT app, then you should be create a Shell; create controls in it; open it; run the event loop; and dispose it. Speaking in code:

Shell shell = new Shell(display);
// set layout and create widgets 
 shell.open ();
 while (!shell.isDisposed ()) {
  if (!display.readAndDispatch ()) display.sleep ();
 }
 display.dispose ();

Window:

If you are developing plugins/JFace applications, its better to use Window rather than Shells directly, because it manages the above things for you. It is not, but think it of as a wrapper for Shell. When you use a Window, a Shell is not created until the open() method is called. Since the Shell is not created till the Window is open and windows can be reopened (yes, you can reopen it), configuration of the Shell should be done in the configureShell() method. Remember, this is an abstract class and so you cannot directly use it. You must either use Dialog or ApplicationWindow or your own concrete class.

Dialog:

When you need a specialized communication with the user, you should be using Dialogs. In all other cases, you will be using ApplicationWindow. Dialog are more of helper windows that are attached to another main window. PreferenceDialog, PropertyDialog, ErrorDialog, InputDialog & WizardDialog are some frequently used dialogs.

ApplicationWindow:

Window + menu support + toolbar support + coolbar support + status line support = ApplicationWindow :-)

IWorkbenchWindow:

WorkbenchWindow is Eclipse specific ApplicationWindow, which adds few services and a set of IWorkbenchPages to the ApplicationWindow. Although the javadoc says "Each workbench window has a collection of 0 or more pages", in reality it has only one page. I believe this is due to backward compatibility with Eclipse 1.0.

IWorkbenchPage:

The area that lies between the toolbar and the status line of the WorkbenchWindow is known as WorkbenchPage. Simply put, this is the body of the WorkbenchWindow, where all the editors and views are showed. IWorkbenchPage contains IWorkbenchParts, which are the the visual representation of the Views and Editors. Both IViewPart and IEditorPart derive from IWorkbenchPart

IWorkbenchSite:

IWorkbenchPart resides inside the IWorkbenchPage. So it has no direct access to the workbench itself. So when it needs to interact with the workbench, then it needs the IWorkbenchSite. For example to get the shell inside a view, you call getSite().getShell().

Excluding a view from Properties View

2009-09-10T12:19:00.001+05:30

In a previous tip, we saw how to make a Properties View to respond only to a particular View or Editor. In this tip, we are going to see how to exclude a particular View or Editor from the Properties View. This will be very helpful in RCP apps, where they don't want the generic view like Outline view or an editor that contributes to the Properties View. Last time we extended the Properties View to create our own view and added some code. But this time its simple. You just have to use the org.eclipse.ui.propertiesView extension point.

<extension
         point="org.eclipse.ui.propertiesView">
      <excludeSources
            id="org.eclipse.ui.views.ContentOutline">
      </excludeSources>
      <excludeSources
            id="com.eclipse_tips.editors.MyOwnEditor">
      </excludeSources>
</extension>

Yes, its that simple :-) Don't try with Galileo, you would need Helios (3.6) M2 to get this working.

Remember the State

2009-08-06T23:31:00.001+05:30

As a rule of thumb, your application should try to remember the state across sessions. So when a user hits the close button and then opens it after few mins/days, it should present exactly in the same way where he left. In this tip, I'm going to explain few things of how this could be achieved.

The first and foremost thing is the number of windows opened and current perspective and its state in each window. If you are writing a plugin for the IDE, you need not worry about this. Eclipse does that for you. If you are an RCP app, you have to do it yourself. You have to do it in the WorkbenchAdvisor.initialize() method:

public class ApplicationWorkbenchAdvisor extends WorkbenchAdvisor {
 
 @Override
 public void initialize(IWorkbenchConfigurer configurer) {

  super.initialize(configurer);
  configurer.setSaveAndRestore(true);
 }

 // other methods ...
}

Now this will take care of lot of things - the number of windows that are opened; location & size of those windows; perspective of each window; view & editors in each perspective; their locations,... All by setting that one boolean variable!

Now that our views and editors are restored by Eclipse, we need to ensure the state of them. Most of the views will be tree/table based. In these cases, the current selection is an important one to restore.

To store these items and anyother stuff you want to, Eclipse provides IMemento. An instance of this IMemento is passed to the view when its initialized and when workbench is closed. The information can be stored hierarchically with string keys and it will be persisted as an XML. If you are wondering why can't it be as simple as passing a Serializable Java object and the workbench persisting it, the answer is simple. The same class may not be there when Eclipse starts next time or even if the same class is available, it might have changed. IMemento avoids this problem by persisting the stae as an XML string.

So how do we use it? In the view, you have to override the init() and saveState() methods:

@Override
public void init(IViewSite site, IMemento memento) throws PartInitException {
 this.memento = memento;
 super.init(site, memento);
}

public void createPartControl(Composite parent) {
        // create the viewer
 restoreSelection();
}

private void restoreSelection() {
 if (memento != null) {
  IMemento storedSelection = memento.getChild("StoredSelection");
  if (storedSelection != null) {
   // create a structured selection from it
   viewer.setSelection(selection);
  }
 }
}

@Override
public void saveState(IMemento memento) {
 IStructuredSelection selection = (IStructuredSelection) viewer.getSelection();
 if (!selection.isEmpty()) {
  IMemento storedSelection = memento.createChild("StoredSelection");
  // store the selection under storedSelection
 }
}

Not just the selection, we can store any other information (which of the tree nodes are expanded, sorter & filter settings etc) which will be useful to restore the state.

Great. Now moving on from the views, the next item would be dialogs. Similar to the workbench windows, you can store the size, location and other elements of a dialog as well. The functionality for size and location is available by default, but you need to enable it by overriding the Dialog.getDialogBoundsSettings() method. The Dialog class stores & retrieves the size and location from IDialogSettings returned from that method. The original implementation returns null, so nothing is saved. We need to create an instanceof IDialogSettings and return it. Your plugin's Activator simplifies that. When required, it creates a dialog_settings.xml under your plugin's data area and store the dialog settings of all the dialogs. You have to create a separate section for each dialog.

private static final String MY_DIALOG_SETTINGS = "MY_DIALOG_SETTINGS";

@Override
protected IDialogSettings getDialogBoundsSettings() {
 IDialogSettings settings = Activator.getDefault().getDialogSettings();
 IDialogSettings section = settings.getSection(MY_DIALOG_SETTINGS);
 if (section == null) {
  section = settings.addNewSection(MY_DIALOG_SETTINGS);
 }
 return section;
}

In case you want to store only the location or size, you can specify it by overriding the getDialogBoundsStrategy() method.

Much like the IMemento, the IDialogSettings basically organizes the key-value strings in an hierarchical way. So along with the size & location, you can store any other information in this IDialogSettings. Its a good practice to store the values of the widgets (which radion button is selecte, checked state of a check box, etc) in the dialog, so its faster for an user who frequently repeats an operation.

Talking about the widgets, the trickier one is Combo. When the list of options are predefined and the user can't enter a new value, then its easy. But in places where the user can enter the values, (like File/Directory selection, search boxes), remembering them is not straight forward.

We shouldn't be storing every single value the user enters, but only the recently used ones. Probably with a limit of 5 or 10 items only. This can be done with the help of LinkedHashSet. It guarantees the order of the element, so whenever the user enters a new values, put the current value first in the set then add the rest of the elements (even if the first element is repeated, it won't change the position). Then take the first N elements and store it.

private static final String COMBO_STATE="COMBO_STATE";

private static final int HISTORY_SIZE = 5;

private String []comboState;

private void restoreComboState(IDialogSettings settings) {
 comboState = settings.getArray(COMBO_STATE);
 if(comboState ==null)
  comboState = new String[0];
 for (String value : comboState) {
  myCombo.add(value);
 }
}

private void saveComboState(IDialogSettings settings) {

 // use LinkedHashSet to have the recently entered ones
 LinkedHashSet<String> newState = new LinkedHashSet<String>();
 newState.add(myCombo.getText());
 newState.addAll(Arrays.asList(comboState));

 // now convert it to the array of required size
 int size = Math.min(HISTORY_SIZE, newState.size());
 String[] newStateArray = new String[size];
 newState.toArray(newStateArray);

 // store
 settings.put(COMBO_STATE, newStateArray);
}

One last piece. Look at this dialog:

Sometimes only for the first time you want to ask the question to the user. Thereafter if the user prefers, you can use the same answer. To simplify this, you can use the MessageDialogWithToggle. You need to pass the preference store and the key for the preference value. When the user selects the check box, the value will be stored. From the next time onwards, you can check the value from the preference and use it.

MessageDialogWithToggle.openYesNoQuestion(shell, "Remember me", "Is this tip useful?", 
  "Don't bug me with this question again", true, 
  Activator.getDefault().getPreferenceStore(), "BUG_USER_KEY");

There you go:

:-)

Eclipse Summit India - Day 2

2009-07-18T22:37:00.001+05:30

The second day, I was a little late and missed the Oracle's Plenary session. I was in time for IBM's session. Being an IBM-er nothing new for me there to see RAD or websphere. It was good.

The first session I took was by Ilya Shinkarenko. More than half of the hall had repeated audience. It was nice, just as yesterday. This time, I was able to attend till the end. After a heavy lunch, I felt very sleepy in the afternoon session. The presenter was partly responsible for that ;-) Then I moved to Anshu Jain's session called 'Eclipse as framework of frameworks', which was simply awesome. To quote Ankur, "a lot of meat added with a perfect aroma, the presentation was a feast". Of the ones I've attended, that was the best. Next was networking in the corridor. After many questions on Eclipse startup to command invocation, that marked the end of the day for me.

Some afterthoughts:

(*) The good thing about this conference is the focus. This is not an all-in-conference, which targets all the CEOs, CTOs, Managers, decision makers, IT guys and your office boys. This has complete focus on Eclipse plug-in developers and almost all of these sessions are well aligned towards this.

(*) Parallel tracks are good, but they could have been specific tracks like OSGi, EMF etc. Also there were instances like both the OSGi sessions were held in parallel, so if someone is interested in OSGi, they have to choose between these two. Probably the next time, it gets better.

(*) The venue was also much better, center of the city and well accessible. No need to talk about the food, it was great :-)

I believe that the photos, videos and the slides will be uploaded online soon. I'll post a link once its done.

Eclipse Summit India - Day 1

2009-07-17T14:44:00.002+05:30

Before I start, a question: How do you know you are in troubled economic times?

Today is the first day of Eclipse Summit India. Luckily, even after screwing up by taking a wrong road and going in a different direction, I did make it well before the keynote by Microsoft. Yes, Microsoft. They are one of the Platinum sponsors. Just like me, everyone was wondering what are they doing there, the answer told was "interoperability". I'm not going to summarize any of the topics presented, so I'll leave you to guess what how he positioned M$ in that.One thing that was interesting is they have PHP as a first class citizen in their IIS. That was surprising for me. Additionally they have some thing called a 'One Installer' which will download all that you want for a web site and install it on your server - not just PHP module for IIS or the latest .Net runtime, but Wordpress and Drupal as well! Wow!

After that it was Ilya Shinkarenko's workshop. It was good. Started a little slow and the pace moved up during the session. I've to cut it in the middle and rush to the other room. Adobe guys were just finishing their presentation. Both of them had a black Mac book and even before I said another 'wow', I noticed it was a windows machine with an Apple sticker. Good idea, I should say. The presentation was mine, and I hope it went well. I did get some good feedback during the lunch. Its definitely troubled ecomony now, but the buffet was good :-)

Post lunch, yeah, I'm in the EMF workshop and blogging this (yeah, we got free wi-fi). Got to run for Ankur's Presentation. Rest of the sessions in the evening/tomorrow.

Before I sign out, the answer: In the free goodies for attendees, you get a pencil instead of a pen ;-)

Keyboard accessibility thru Command Framework

2009-06-26T13:10:00.000+05:30

Keyboard shortcuts is usually much speedier than reaching out your mouse, moving it, pointing it to something and clicking. But there are some things which cannot be done that easily by keyboard shortcuts. For me, one of them is finding out a closed project and open it. Unfortunately, I've quite a large set of projects in my workspace and try to keep most them closed, when not used. In addition to that in the Package Explorer, I've the 'Closed Projects' filter on. So if I need to open a project, I've use the pull down menu, uncheck 'Closed Projects' navigate thru the working sets to find the right project and double click it. To enable keyboard access to this regular task, I decided to make use of Commands Framework.

The solution is to add a parameterized command, and in the values, I compute the projects which are closed. So when I press the awesome shortcut (Ctrl+3) it would display me the list of closed projects. With few keys, I can navigate to the project I want and open it. Lets see how to do it. First step is the command with the parameter:

<extension point="org.eclipse.ui.commands">
   <command
            defaultHandler="com.eclipse_tips.handlers.OpenProjectHandler"
            id="com.eclipse-tips.openProject.command"
            name="Open Project">
      <commandParameter
               id="com.eclipse-tips.openProject.projectNameParameter"
               name="Name"
               optional="false"
               values="com.eclipse_tips.handlers.ProjectNameParameterValues">
      </commandParameter>
   </command>
</extension>

And the handler:

public Object execute(ExecutionEvent event) throws ExecutionException {
 String projectName = event.getParameter("com.eclipse-tips.openProject.projectNameParameter");
 IWorkspaceRoot root = ResourcesPlugin.getWorkspace().getRoot();
 IProject project = root.getProject(projectName);
 try {
  project.open(null);
 } catch (CoreException e) {
  throw new ExecutionException("Error occured while open project", e);
 }
 return null;
}

For the parameter values, I look for closed projects and return them:

public Map<String, String> getParameterValues() {

 IWorkspaceRoot root = ResourcesPlugin.getWorkspace().getRoot();
 IProject[] projects = root.getProjects();
 Map<String, String> paramValues = new HashMap<String, String>();
 for (IProject project : projects) {
  if (project.exists() && !project.isOpen()) {
   paramValues.put(project.getName(), project.getName());
  }

 }
 return paramValues;
}

So finally, When I press Ctrl+3 and type OPN, I get the list:

This idea can be extended to provide keyboard accessibility to many functionalities. Say in an RCP mail application, you can add a command like 'Go To Mail' with parameter as the Subject/Sender:

Hmmm, if only the 'Built On Eclipse' mail app that I *have* to use, knows the existence of threads other than the UI thread :-(

Subtask in ProgressMonitors

2009-06-03T13:51:00.003+05:30

Here is a trivial tip. When inspecting a bug, I found a interesting thing on Progress Monitors. We know monitor.worked() increments the progress bar, but how do we change the text to update the current subtask? The initial text is set by the beginTask() method and it should be called only once. I digged into the IProgressMonitor and found the subtask() method:

IRunnableWithProgress operation = new IRunnableWithProgress() {

 public void run(IProgressMonitor monitor) {

  monitor.beginTask("Main task running ...", 5);
  for (int i = 0; i < 5; i++) {
   monitor.subTask("Subtask # " + i + " running.");
   runSubTask(new SubProgressMonitor(monitor, 1), i);
  }
 }

};

Now the question is what happens when the runSubTask() method sets another subTask on the SubProgressMonitor?

private void runSubTask(IProgressMonitor monitor, int subTaskId) {

 monitor.beginTask("Sub task running", 10);
  for (int i = 0; i < 10; i++) {
   monitor.subTask("Inside subtask, " + i + " out of 10");
   // do something here ...
   monitor.worked(1);
   if (monitor.isCanceled())
    throw new OperationCanceledException();
 }
  monitor.done();
 }

}

Basically the SubProgressMonitor's subTask() overwrites the parent's subTask(). Thats the default behaviour. You can customize it with the style bits provided in the SubProgressMonitor:

If you want to append the SubProgressMonitor's subTask info, use the style PREPEND_MAIN_LABEL_TO_SUBTASK:

new SubProgressMonitor(monitor, 1, SubProgressMonitor.PREPEND_MAIN_LABEL_TO_SUBTASK), i);

Else if you want to ignore it altogher then use the SUPPRESS_SUBTASK_LABEL style:

new SubProgressMonitor(monitor, 1, SubProgressMonitor.SUPPRESS_SUBTASK_LABEL), i);

Search menu in Mac - the implementation

2009-05-29T15:10:00.004+05:30

In the previous entry I mentioned about the Search Menu in Mac. Lets see what that search menu contains:

The first item is the "Clear" menu. It clears the recent search history. Next comes the recent searches. If you want to call it as "Search History", you can do it in the title field menu item. The title field & clear menu item are visible only when there is at least one entry in the recent searches. The menu can also have custom items, where you can include you own action items. Lets see how to add all these in an SWT app:

Text searchText = new Text(shell, SWT.SEARCH | SWT.ICON_CANCEL | SWT.ICON_SEARCH);
  SearchFieldSupport searchFieldSupport = new SearchFieldSupport(searchText);
  Menu menu = new Menu(searchText);
  
  MenuItem customItem = new MenuItem(menu, SWT.NONE);
  customItem.setText("Custom Action");
  customItem.addSelectionListener(new SelectionAdapter() {
   public void widgetSelected(SelectionEvent e) {
    MessageDialog.openInformation(shell, "Search Field", "Custom action is done here");
   };
  });
  
  MenuItem sep1 = new MenuItem(menu, SWT.SEPARATOR);
  
  MenuItem recentMenuItem = new MenuItem(menu, SWT.NONE);
  recentMenuItem.setText("Search History");
  SearchFieldSupport.setRecentSearchesTitle(recentMenuItem);
  
  // for the search history
  MenuItem recentsMenuItem = new MenuItem(menu, SWT.PUSH);
  SearchFieldSupport.setRecentSearches(recentsMenuItem);
  
  MenuItem sep2 = new MenuItem(menu, SWT.SEPARATOR);

  MenuItem clearMenuItem = new MenuItem(menu, SWT.PUSH);
  clearMenuItem.setText("Clear History");
  SearchFieldSupport.setClearRecents(clearMenuItem);

  searchFieldSupport.setMenu(menu);

Here is the result:

Its almost perfect except that when we clear the search history and see the menu, it looks like this:

Its because the separators are still shown even when there is no recent menu items. The hack is to set the separator as a resentSearches menu item:

MenuItem sep2 = new MenuItem(menu, SWT.SEPARATOR);
  SearchFieldSupport.setRecentSearchesTitle(sep2);

The Search Field also supports a custom menu item which tells that there is no recent search items. This menu item is automatically hidden when there search history is not empty. We can add that also before the second separator:

MenuItem recentsMenuItem = new MenuItem(menu, SWT.PUSH);
  SearchFieldSupport.setRecentSearches(recentsMenuItem);
  
  MenuItem noRecentMenuItem = new MenuItem(menu, SWT.NONE);
  noRecentMenuItem.setText("No Search History");
  SearchFieldSupport.setNoRecentSearches(noRecentMenuItem);
  
  MenuItem sep2 = new MenuItem(menu, SWT.SEPARATOR);
  SearchFieldSupport.setRecentSearchesTitle(sep2);

Now we are all set:

The last missing piece of the puzzle, the SearchFieldSupport class:

package org.eclipse.ui.cocoa.ext;

import org.eclipse.swt.events.DisposeEvent;
import org.eclipse.swt.events.DisposeListener;
import org.eclipse.swt.events.KeyEvent;
import org.eclipse.swt.events.KeyListener;
import org.eclipse.swt.widgets.Menu;
import org.eclipse.swt.widgets.MenuItem;
import org.eclipse.swt.widgets.Text;
import org.eclipse.ui.cocoa.ext.internal.NSSearchField;

/**
 * 
 * @author Prakash G.R.
 * 
 */
public class SearchFieldSupport implements KeyListener, DisposeListener {
 
 private final NSSearchField nsSearchField;
 private final Text text;

 public SearchFieldSupport(Text text) {
  this.text = text;
  text.addKeyListener(this);
  text.addDisposeListener(this);
  nsSearchField = new NSSearchField(text);
 }

 public Text getText() {
  return text;
 }

 public String[] getRecentSearchStrings() {
  return nsSearchField.getRecentSearches();
 }
 
 public void setRecentSearchStrings(String[] recentSearches) {
  nsSearchField.setRecentSearches(recentSearches);
 }

 public void setMenu(Menu menu) {
  nsSearchField.setMenu(menu);
 }

 public static void setNoRecentSearches(MenuItem menuItem) {
  NSSearchField.setTag(menuItem, NSSearchField.NSSearchFieldNoRecentsMenuItemTag);
 }

 public static void setClearRecents(MenuItem menuItem) {
  NSSearchField.setTag(menuItem, NSSearchField.NSSearchFieldClearRecentsMenuItemTag);
 }

 public static void setRecentSearchesTitle(MenuItem menuItem) {
  NSSearchField.setTag(menuItem, NSSearchField.NSSearchFieldRecentsTitleMenuItemTag);
 }

 public static void setRecentSearches(MenuItem menuItem) {
  NSSearchField.setTag(menuItem, NSSearchField.NSSearchFieldRecentsMenuItemTag);
 }

 public void widgetDisposed(DisposeEvent e) {
  text.removeKeyListener(this);
 }

 public void keyPressed(KeyEvent e) {
  // do nothing
 }

 public void keyReleased(KeyEvent e) {
  if (e.keyCode == '\r') {
   String[] recentSearchStrings = getRecentSearchStrings();
   int oldSize = recentSearchStrings.length;
   String[] newSearchStrings = new String[recentSearchStrings.length + 1];
   System.arraycopy(recentSearchStrings, 0, newSearchStrings, 0, recentSearchStrings.length);
   newSearchStrings[oldSize] = text.getText();
   setRecentSearchStrings(newSearchStrings);
   text.setSelection(0, text.getText().length());
  }
 }

}

and the custom NSSearchField class:

package org.eclipse.ui.cocoa.ext.internal;

import java.lang.reflect.Field;

import org.eclipse.swt.internal.cocoa.NSArray;
import org.eclipse.swt.internal.cocoa.NSMenu;
import org.eclipse.swt.internal.cocoa.NSMenuItem;
import org.eclipse.swt.internal.cocoa.NSMutableArray;
import org.eclipse.swt.internal.cocoa.NSString;
import org.eclipse.swt.internal.cocoa.OS;
import org.eclipse.swt.internal.cocoa.id;
import org.eclipse.swt.widgets.Menu;
import org.eclipse.swt.widgets.MenuItem;
import org.eclipse.swt.widgets.Text;

/**
 * @author Prakash G.R.
 * 
 */
@SuppressWarnings("restriction")
public class NSSearchField extends org.eclipse.swt.internal.cocoa.NSSearchField {

 public static final int NSSearchFieldRecentsTitleMenuItemTag = 1000;
 public static final int NSSearchFieldRecentsMenuItemTag = 1001;
 public static final int NSSearchFieldClearRecentsMenuItemTag = 1002;
 public static final int NSSearchFieldNoRecentsMenuItemTag = 1003;

 private static final int /* long */sel_setSearchMenuTemplate = OS.sel_registerName("setSearchMenuTemplate:");
 private static final int /* long */sel_setTag = OS.sel_registerName("setTag:");
 private static final int /* long */sel_setRecentSearches = OS.sel_registerName("setRecentSearches:");

 public NSSearchField(id id) {
  super(id);
 }

 public NSSearchField(Text text) {
  super(text.view);
 }

 public void setMenu(Menu menu) {
  try {
   Field field = Menu.class.getDeclaredField("nsMenu");
   field.setAccessible(true);

   NSMenu nsMenu = (NSMenu) field.get(menu);

   OS.objc_msgSend(this.id, sel_setSearchMenuTemplate, nsMenu.id);
  } catch (Exception e) {
   e.printStackTrace();
  }
 }

 public static boolean setTag(MenuItem menuItem, int tag) {
  try {
   Field field = MenuItem.class.getDeclaredField("nsItem");
   field.setAccessible(true);

   NSMenuItem nsMenuItem = (NSMenuItem) field.get(menuItem);
   OS.objc_msgSend(nsMenuItem.id, sel_setTag, tag);

   // no action for titles
   if (tag == NSSearchFieldRecentsTitleMenuItemTag || tag == NSSearchFieldNoRecentsMenuItemTag) {
    nsMenuItem.setAction(0);
   }
   return true;
  } catch (Exception e) {
   return false;
  }
 }

 public String[] getRecentSearches() {
  NSArray recentSearches = super.recentSearches();
  String[] recentSearchStrings = new String[recentSearches.count()];
  for (int i = 0; i < recentSearchStrings.length; i++) {
   recentSearchStrings[i] = (new NSString(recentSearches.objectAtIndex(i))).getString();
  }
  return recentSearchStrings;
 }

 public void setRecentSearches(String[] recentSearchStrings) {
  
  NSMutableArray recentSearches = NSMutableArray.arrayWithCapacity(recentSearchStrings.length);
  for (String aRecentSearcb : recentSearchStrings) {
   NSString nsString = NSString.stringWith(aRecentSearcb);
   recentSearches.addObject(nsString);
  }
  OS.objc_msgSend(this.id, sel_setRecentSearches, recentSearches.id);
  
 }
}

Enjoy!

Search menu in Mac

2009-05-26T17:24:00.001+05:30

In Mac applications, the little search box can have a pull down menu (similar to a View's pull down menu). It can have recent searches, user contributed menu entries, a menu item for clearing the recent searches etc. Here is the search box of Tweetie (the twitter app that I use):

Eclipse by default offers the SWT.SEARCH style which will bring this search box instead of the default text box. But there is no option to add the menu. For today's SWT-Cocoa hack, I tried to enhance the Search box with the search menu and here is the result:

The code is so ugly that I can't post it in public yet. Will post it with refinements tomorrow.

Update: The implementation is available here.

Badge label on Mac Dock icon

2009-05-23T01:17:00.002+05:30

I'm passionate on both Mac and Eclipse. Although Eclipse runs well on a Mac, its not a marriage made in heaven. Its really hard to get the complete Mac experience with a portable UI tool kit. If you think of features like this one, its actually endless list. One such thing is the badge on the Dock Icon. In Mac, the Dock icon can have a badge - like the number of unread mails in your inbox. How much effort does it takes to add a badge to our RCP mail sample? Not much. Since SWT doesn't have a NSDockTile, we need a NSDockTile class with two methods, one to get the DockTile for the application and the other to set the badge on it (there is an easier way by using the Mac Generator tool, but that will be a patch to SWT itself, which I wanted to avoid):

/**
 * @author Prakash G.R. (grprakash@gmail.com) 
 * 
 */
@SuppressWarnings("restriction")
public class NSDockTile extends NSResponder {

 private static final int sel_setBadgeLabel_ = OS.sel_registerName("setBadgeLabel:");
 private static final int sel_dockTile_ = OS.sel_registerName("dockTile");
 private static final int sel_display_ = OS.sel_registerName("display");

 public NSDockTile(int id) {
  super(id);
 }

 public static NSDockTile getApplicationDockTile() {
  NSApplication sharedApplication = NSApplication.sharedApplication();
  int id = OS.objc_msgSend(sharedApplication.id, sel_dockTile_);
  NSDockTile dockTile = new NSDockTile(id);
  return dockTile;
 }

 public void setBadgeLabel(String badgeLabel) {
   NSString nsBadgeLabel = NSString.stringWith(badgeLabel);
   OS.objc_msgSend(this.id, sel_setBadgeLabel_, nsBadgeLabel.id);
   OS.objc_msgSend(this.id, sel_display_);
 }
}

And a two line code to set the badge:

NSDockTile nsDockTile = NSDockTile.getApplicationDockTile();
nsDockTile.setBadgeLabel("6");

There you go in the dock icon and in the minimized window:

In case you were wondering how the GMail icon for the application is set, here is the code for that:

ImageDescriptor imageDescriptor = ImageDescriptor.createFromURL(iconUrl);
Image image = imageDescriptor.createImage();
NSApplication app = NSApplication.sharedApplication();
app.setApplicationIconImage(image.handle);

Oh, BTW, I've just started learning Objective C, Cocoa & related things. So stay tuned, you will see more Mac related posts here. Also what is your favourite Mac feature that you are missing in Eclipse?

Creating a custom Property View

2009-05-16T00:37:00.001+05:30

In an RCP application, you might need a Properties View, which shows only the properties of a specific view or a set of views. But the generic Properties View will show from all the other views that support it. Armed up with the knowledge of how a PageBookView works, lets see how to hack the Properties View to listen only to a specific view.

The isImportant() method is the one which decides whether to create an IPage for the specific IWorkbenchPart or not. The idea is to override that method and return false for all the workbenchPart that we are not interested in. Lets create the view first:

<view
            class="com.eclipse_tips.views.CustomPropertiesView"
            icon="icons/sample.gif"
            id="com.eclipse-tips.views.customePropertiesView"
            name="My Properties View">
</view>

The CustomPropertiesView should extend PropertySheet and override the isImportant():

public class CustomPropertiesView extends PropertySheet {

 @Override
 protected boolean isImportant(IWorkbenchPart part) {
  if (part.getSite().getId().equals(IPageLayout.ID_PROJECT_EXPLORER))
   return true;
  return false;
 }
}

In this case, I'm making the view only to respond to Project Explorer and ignore other views. Here is the CustomPropertyView in action:

If you are on 3.5 or above, you would see the Pin Action in your Custom Properties View. If you don't want the Pin action in your properties view, there is no way to prevent the PropertySheet to adding the action. The action is added to both tool bar and menu in the createControl() method. Only way to get rid of the action is to remove it after the PropertySheet adds it:

@Override
 public void createPartControl(Composite parent) {
  
  super.createPartControl(parent);
  IMenuManager menuManager = getViewSite().getActionBars().getMenuManager();
  IContributionItem[] items = menuManager.getItems();
  for (IContributionItem iContributionItem : items) {
   if(iContributionItem instanceof ActionContributionItem) {
    if(((ActionContributionItem) iContributionItem).getAction() instanceof PinPropertySheetAction) {
     menuManager.remove(iContributionItem);
     break;
    }
   }
  }

  IToolBarManager toolBarManager = getViewSite().getActionBars().getToolBarManager();
  items = toolBarManager.getItems();
  for (IContributionItem iContributionItem : items) {
   if(iContributionItem instanceof ActionContributionItem) {
    if(((ActionContributionItem) iContributionItem).getAction() instanceof PinPropertySheetAction)) {
     toolBarManager.remove(iContributionItem);
     break;
    }
   }
  }
 }

And don't forget to override the isPinned() method:

@Override
 public boolean isPinned() {
  return false;
 }

There you go:

How to create a PageBookView

2009-05-14T15:22:00.166+05:30

Think of Properties View. It displays the properties of the selected element in the active part. Whenever the selection changes or the active part changes, it tracks them and displays the properties (unless you used the 'Pin to selection' feature available from 3.5) There are many views like this, which update themselves when the active part changes. Outline view, Templates view, GEF Palette view, etc. If you want to create such view, its not a tough job - Eclipse provides you all the basic features in the class PageBookView. All you need is to extend this class and fill the void by implementing the abstract methods. Thats what we are going to see in this tip. The use case is to create a ActivePartTrackerView, which will display the name of the current active workbench part.

First lets create a View:

<extension
         point="org.eclipse.ui.views">
      <view
            class="com.eclipse_tips.views.SelectionView"
            icon="icons/sample.gif"
            id="com.eclipse-tips.views.pagebookview"
            name="Selection Provider View">
      </view>
   </extension>

The contents of the PageBookView is arranged in pages (IPage). There can be multiple pages, each of them is associated with a corresponding IWorkbenchPart. When the associated part becomes active, the PageBookView automatically switches to the respective page. When a PageBookView is created, it asks for a bootstrap part by calling getBootstrapPart() method. When no bootstrap part is found, it uses a default page. That default page is also shown when there are no pages for the currently active part. Lets start by creating this default page. To do that we need to implement the createDefaultPage() method, which returns the default page. Lets use the MessagePage which simply displays a string.

@Override
 protected IPage createDefaultPage(PageBook book) {
  MessagePage messagePage = new MessagePage();
  initPage(messagePage);
  messagePage.setMessage("No interested in this part");
  messagePage.createControl(book);
  return messagePage;
 }

Now our SelectionView is up and running, except that its showing a static content not creating any IPages for the active parts. Before we create an IPage, how to determine whether to create an IPage for a given IWorkbenchPart or ignore it? Its by the isImportant() method. Lets say, we want to respond only to the parts that are contributed by the Platform UI.

@Override
 protected boolean isImportant(IWorkbenchPart part) {
  return part.getSite().getPluginId().startsWith("org.eclipse.ui");
 }

So if a Package Explorer(contributed by JDT) or the Manifest Editor(contributed by PDE) is the active part, then our SelectionView will not create any page and use the default page. If its a TextEditor or Project Explorer, then it will create the page and show it.

To create an IPage for a given part, we need to override the doCreatePage() method. Unlike the createDefaultPage() method this doesn't return a IPage, rather a PageRec. Why? This Page Record stores additional information - the associated workbench part and action bars:

@Override
 protected PageRec doCreatePage(IWorkbenchPart part) {
  MessagePage messagePage = new MessagePage();
  initPage(messagePage);
  messagePage.setMessage("Page for "+part.getTitle());
  messagePage.createControl(getPageBook());
  return new PageRec(part, messagePage);
 }

When you are switching between the TextEditor and the ProjectExplore view, the PageBookView will track and find the page for the active part and automatically show it. When the page is no longer needed (the associated part is closed), it would call the doDestroyPage(). This is where you would ideally remove any listeners and dispose of the resources.

So the whole class goes here:

package com.eclipse_tips.views;

import org.eclipse.ui.IWorkbenchPage;
import org.eclipse.ui.IWorkbenchPart;
import org.eclipse.ui.part.IPage;
import org.eclipse.ui.part.MessagePage;
import org.eclipse.ui.part.PageBook;
import org.eclipse.ui.part.PageBookView;

/**
 * @author Prakash G.R.
 *
 */
public class ActivePartTrackerView extends PageBookView {

 @Override
 protected IPage createDefaultPage(PageBook book) {
  MessagePage messagePage = new MessagePage();
  initPage(messagePage);
  messagePage.setMessage("No interested in this part");
  messagePage.createControl(book);
  return messagePage;
 }

 @Override
 protected PageRec doCreatePage(IWorkbenchPart part) {
  MessagePage messagePage = new MessagePage();
  initPage(messagePage);
  messagePage.setMessage("Page for "+part.getTitle());
  messagePage.createControl(getPageBook());
  return new PageRec(part, messagePage);
 }

 @Override
 protected void doDestroyPage(IWorkbenchPart part, PageRec pageRecord) {
  pageRecord.page.dispose();
 }

 @Override
 protected IWorkbenchPart getBootstrapPart() {
  IWorkbenchPage page = getSite().getPage();
  if(page != null) {
   // check whether the active part is important to us
   IWorkbenchPart activePart = page.getActivePart();
   return isImportant(activePart)?activePart:null;
  }
  return null;
 }

 @Override
 protected boolean isImportant(IWorkbenchPart part) {
  return part.getSite().getPluginId().startsWith("org.eclipse.ui");
 }

}

Sheet support in SWT

2009-05-12T16:29:00.002+05:30

For those who have downloaded 3.5 M7 would have seen Sheets support has been added to SWT and Platform UI has used the API wherever applicable. For those who are wondering what a Sheet means, its an eye-candy in Mac. Here is a sample of a MessageDialog shown with and without Sheet style:

(in case you didn't notice the obvious, I'm back on a Mac :-P)

So what is a Sheet?

A Sheet is essentially a Dialog, which is tied to a parent window. It acts as a Modal Dialog, so the user cannot perform any operations on a window until the Dialog is dismissed. (He is free to work on other windows) The dialog is

always attached with the window until dismissed
placed in the center of the window
moves along when the window is moved

To Sheet or not to Sheet?

Use Sheets when the interaction is very short like the question "Is Eclipse a cool product? ". Opening a 15 step Wizard to choose your life partner is not right place to use Sheet.
Do not use Sheets where the user might still need to interact with the Window (like copy something from window and paste it in the Sheet). Since Sheets are Window Modal, it doesn't allow the user to interact with the associated Window
Sheets are not Application Modal. So if you want a dialog to be Application Modal, don' use Sheets
Unlike normal Dialogs, Sheets do not have title. Avoid Sheets where title provides valuable information.
Do not use nested Sheets (says Apple's UI guidelines)

How do I use Sheet?

Simple. Set the SWT.Sheet style to the Shell of the dialog. In case you are using the MessageDialog, pass on the style bit as the last argument to the MessageDialog.open() method

Commands Part 7: Adding standard commands

2009-05-12T14:57:00.003+05:30

In the earlier installments, we have seen adding our commands to menus and toolbars. But what about the standard menu items like Cut, Copy, Paste etc? We'll see how to add these to a context menu of the Sample View.

Create the Sample View through the PDE's Extension Point Wizard. In the SampleView class, notice these lines:

private void hookContextMenu() {

// rest of the code...
getSite().registerContextMenu(menuMgr, viewer);
}

private void fillContextMenu(IMenuManager manager) {

//rest of the code
manager.add(new Separator(IWorkbenchActionConstants.MB_ADDITIONS));
}

The first one registers this context menu, so that other plugins can contribute their commands to it. The second one adds a separator, which serves as a place holder/location where the contribution goes. So the SampleView is ready to accept the contributions, lets now contribute:

<extension
point="org.eclipse.ui.menus">
<menuContribution
locationURI="popup:com.eclipse_tips.commands.part7.views.SampleView?after=additions">
<command commandId="org.eclipse.ui.edit.cut"/>
<command commandId="org.eclipse.ui.edit.copy"/>
<command commandId="org.eclipse.ui.edit.paste"/>
</menuContribution>
</extension>

The id for the context menu, is by default the View's id, and we add our contribution after the separator. We can add any command, either the Platform defined or our own. Result:

Now we have the menu items, images, shortcut keys everything in place (you ought to love the command framework :-)), except that the items are not enabled. Its because there is no handler for these commands for the given context. There are multiple ways to contribute the handler, since we are adding this to our view, lets use the activePartId variable:

<extension
point="org.eclipse.ui.handlers">
<handler
class="com.eclipse_tips.commands.part7.handlers.CutHandler"
commandId="org.eclipse.ui.edit.cut">
<activeWhen>
<with
variable="activePartId">
<equals
value="com.eclipse_tips.commands.part7.views.SampleView">
</equals>
</with>
</activeWhen>
</handler>

Other commands also have similar handlers. Now:

There you go. In the similar way you can add all the standard commands to any menu/context menu you prefer. Just make sure that you have the handler for the commands with the right activeWhen & enabledWhen expression.

The standard command Ids can be found in the IWorkbenchCommandConstants class (available in 3.5)

[Off Topic] Thank you!

2009-04-07T11:20:00.001+05:30

When Google Web Tookit was released to the public, I played with it and realized that an Eclipse plug-in could simply few things. Since I didn't find any, I started learning Eclipse plug-in development to create one. I've fallen in love with Eclipse and its been a wonderful journey since then. I created this blog to publish the tips I've learnt. Shifted myself from server-side-runtime to IDE. I was the first guy to offer Eclipse Plug-in development training in India. With few like-minded-friends, we even started a company to do this training. The clientele includes several small companies and big companies as well. When IBM extended the Eclipse team in Asia, I was the first hire and moved to Eclipse Platform UI team. Last week my committer election successfully concluded and I've become a committer now! Its one of my happiest moments and this blog has been partially responsible for all of this. I've learnt so many things just for the sake of publishing tips.

I really thank all of the readers of this blog. Your comments, emails, queries kept me going. Thanks!