Eclipse Demo Camp, Bangalore

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

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 ...

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

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.