Setting the layout of the Workbench in any Eclipse RCP application can be a daunting task if your application needs any control over the placement of views and editor area that is not directly exposed through the RCP interface.
But some techniques can be used to provide (relatively) more control over the layout by managing the perspective settings and hinting the view size.
In the class implementing IPerspectiveFactory (the class that implements the Perspective to the org.eclipse.ui.perspective extension point), you can:
Enable or disable the Editor area, if you are to design an Editor, this setting should be kept to true
layout.setEditorAreaVisible(true);
You can also use the Fixed Layout option, this removes he ability o maximize and minimize views and the editor area (through the min/max buttons and through the double clicking on the view title.
This keeps the ability to resize single views (as if they are included in Resize composites, but without the ability to reorder the views, or stack them or minimize them as fast views)
layout.setFixed(true);
The order of the views to be added decides who gets the full layout to take part of it and what views get the remaining of the layout to take further parts of it
Views
Views can be standard views, stand-alone views or fast views:
layout.addStandaloneView(MyOwnView.ID, true, IPageLayout.TOP, 1f, editorArea);
Standard view is a simple view in the Workbench that can be docked, stacked, minimized, maximized or detached inside the Workbench window
layout.addView(SampleView.ID, IPageLayout.LEFT, 0.5f, editorArea);
Fast views are shortcuts to the actual views put in the toolbar at the bottom of the Workbench window and shares the status bar if visible
layout.addFastView(SampleView.ID, IPageLayout.DEFAULT_VIEW_RATIO);
Views and hinting its size (in Eclipse 3.4 and upwards)
By implementing the ISizeProvider Interface in the ViewPart class that is creating the view, you can get the view to set its minimum and maximum size, given that the view doesn't get docked into other views (which can be easily made by using stand-alone views), the simplest implementation would be:
@Override public int computePreferredSize(boolean width,
int availableParallel, int availablePerpendicular, int preferredResult) {
return width ? 100 : 110;
}
@Override public int getSizeFlags(boolean width) {
return (SWT.MIN | SWT.MAX);
}
I've started in my quest to learn the Eclipse RCP Platform, the Java Rich Client Platform built on the Eclipse foundation softwareand using the Standard Widget Toolkit (SWT).
While I think that Swing and the Swing Application Framework (JSR 296) would be a more pure Java approach, I personally prefer the Eclipse RCP approach for large scaled projects, where it can provide high degree of modularity to the system (this can be also achieved in the NetBeans Platform, but I prefer the look and feel of the Eclipse-based applications).
Also I think that the NetBeans IDE is better in the more broad Java picture, where I assume it is better in handling the Java EE and Java ME applications and provide a higher of community participation in its code base (this may not be correct, but I got this impression, maybe because I was a close watcher for the NetBeans news earlier than Eclipse).
But the Eclipse RCP won because of its large base of implemented applications, one for example was the main reason that I tried the Eclipse RCP in the first place, uDig, the internet-friendly desktop GIS application, and i don't know until now if I'm gonna to run inside it with my plug-ins, or that I will embed its plugins inside my application(s).
Also the Eclipse SWT library is more responsive and native-looking than Swing (personally I love the Java Metal look and feel, but thats just me, everybody else hates it).
So, in the next few days, I will start posting about my findings in the Eclipse RCP world and the Java world in general.
