Community
Participate
Working Groups
build I20040303 Nick says: > > We also need more control over the overall window layout. At > > minimum, we need to fully disable the banner curve for RCP apps > > (currently it only disappears if you turn off perspective bar and > > coolbar). Ideally I'd like to give the app full control over the > > window layout, but this will require opening up more API for things > > like TrimLayout, PerspectiveBar, FastViewBar, and DnD of trim parts. Chris responds: > i think we should try the minimum here for M8. i.e. the banner curve > off, even when perspectives are showing. > question: is this just a small look change (like make the curve into > a vertical line?), or a functional change e.g. be able to dock the > perspective bar in the regular coolbar area? Nick replies: At a minimum, we need to do just the look change. MVM was talking about functional improvements here too. I think making the perspective bar be a regular toolbar would be fine for RCP apps, even if DnD is not supported. This is probably better than making it be a special component. But this may complicate the story too much, particularly if functional improvements are coming down the pipe.
Also need control over separator lines between menubar, coolbar, main area, status line and fast view bar, which got removed in the new look.
As discussed, this is important for M8.
Released new API to allow the app to control the overall window layout directly, rather than just through the setShow* flags. See: - WorkbenchAdvisor.createWindowContents(IWorkbenchWindowConfigurer, Shell) - IWorkbenchWindowConfigurer.createMenuBar() - IWorkbenchWindowConfigurer.createCoolBarControl(Composite) - IWorkbenchWindowConfigurer.createStatusLineControl(Composite) - IWorkbenchWindowConfigurer.createPageComposite(Composite) The default layout is currently the SDK's, but with square tabs instead of curvy ones by default (an unrelated change, really). This may change for M9, but the intent is to have a high-function default layout that's still customizable. The setShow* flags are only honoured if the default layout is used. Still TBD (for M9): - expose the fast view bar and perspective bar - remove or clarify the setShow* methods
Created attachment 8682 [details] Screen shot of browser example with custom layout Released an update to the browser example to show this off. See attached screen shot.
In your browser example can you get rid of the "Browser" tab and the minimize and maximize buttons that are next to it? Also what components are needed from HEAD to get the new API?
The changes are in org.eclipse.jface and org.eclipse.ui.workbench. Generally for any RCP UI changes, you'll need to load the above plus org.eclipse.ui. For hiding the titlebar, and finer-grained control over min and max, see comments #3 and #4 of bug 53673 (still TBD).
I'm getting the following error when I don't create a CoolBar. java.lang.NullPointerException at org.eclipse.jface.action.CoolBarManager.refresh (CoolBarManager.java:560) at org.eclipse.ui.internal.WorkbenchWindow.updateActionSets (WorkbenchWindow.java:1893) at org.eclipse.ui.internal.WorkbenchWindow$5.run (WorkbenchWindow.java:1705) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:84) at org.eclipse.ui.internal.WorkbenchWindow.setActivePage (WorkbenchWindow.java:1680) at org.eclipse.ui.internal.WorkbenchWindow.busyOpenPage (WorkbenchWindow.java:419) at org.eclipse.ui.internal.WorkbenchWindow$4.run (WorkbenchWindow.java:968) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:84) at org.eclipse.ui.internal.WorkbenchWindow.openPage (WorkbenchWindow.java:965) at org.eclipse.ui.internal.Workbench.openFirstTimeWindow (Workbench.java:1082) at org.eclipse.ui.internal.Workbench.init(Workbench.java:915) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1400) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench (Workbench.java:261) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:139) at org.eclipse.ui.examples.rcp.browser.BrowserApp.run (BrowserApp.java:54) at org.eclipse.core.internal.runtime.PlatformActivator$1.run (PlatformActivator.java:260) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:173) at org.eclipse.core.runtime.adaptor.EclipseStarter.run (EclipseStarter.java:106) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:305) at org.eclipse.core.launcher.Main.run(Main.java:729) at org.eclipse.core.launcher.Main.main(Main.java:713)
I would like to set the background color of the page. Current the following has no effect: Control pageComposite = configurer.createPageComposite(shell); pageComposite.setLayoutData(new GridData(GridData.FILL, GridData.FILL, true, rue)); pageComposite.setBackground(pageComposite.getDisplay().getSystemColor (SWT.COLOR_RED));
I've added a check to CoolBarManager.refresh(). For the page background color, note that the WorkbenchPage has its own composite under the pageComposite (perhaps this should have been called pageParent), and colours are not inherited from parent controls automatically. We can either change it to copy the color down in WorkbenchPage.createClientComposite (you could try this), or change the Workbench to look up a theme color here. Alternatively, just reach in in the new postWindowCreate method and whack it (the page has been created by this time, but the window hasn't been opened yet). Might be nice to have different colors for different perspectives, but then we'd have to reintroduce per-perspective themes ;-(.
The perspective bar can now be moved to a separate toolbar, getting rid of the curve, but we still need RCP API for configuring this. And also for creating the perspective bar in a custom layout. For M9.
There is already an internal preference. We will make it an API preference on IWorkbenchPreferenceConstants, stored in the org.eclipse.ui preference store. The default for RCP will be for it to appear below under the main toolbar. The Eclipse SDK will override this to be on the right, as it is now.
Made changes described in comment #11. Between this and the support for allowing the app to take over the entire window layout (WorkbenchAdvisor.createWindowContents), this will have to suffice for 3.0.
Nick, can you give example code of how to achieve the items in Comments 11 and 12? I tried on M9 and cannot get it to change the location of the Perspective bar.
Try putting the following in the plugin_customization.ini file in the plugin for your primary feature: org.eclipse.ui/DOCK_PERSPECTIVE_BAR=topLeft (the default) or org.eclipse.ui/DOCK_PERSPECTIVE_BAR=topRight (the SDK does this) or org.eclipse.ui/DOCK_PERSPECTIVE_BAR=left (default for the R2.1 presentation) Note that this only overrides the -default- value. If there is an explicitly set value for the preference, this is used instead. You can also set the value programmatically, e.g. from your WorkbenchAdvisor's initialize method: PlatformUI.getPreferenceStore().setValue(IWorkbenchPreferenceConstants.DOCK_PERSPECTIVE_BAR, IWorkbenchPreferenceConstants.LEFT).
By the way, how can I hide the perspective bar? configure.setShowPerspectiveBar(false) didn't work in createWindowContents nor preWindowOpen method. I wonder why you had to show the perspective bar by default from M9.
I noticed if you have a plug-in preference like: org.eclipse.ui/DOCK_PERSPECTIVE_BAR=left even if you have turned off the perspective bar, you get a perspective bar. Comment it out and you don't get a perspective bar. Is this a bug?
The progress bar is still shown even if turned off by setShowProgressBar(false). (You would normally call this in preWindowOpen). This is a regression. Need to handle the different docking cases as well, but in all cases, if setShowProgressBar(true) is not called (the default is false), the progress bar must not be shown.
andrew do you have cycles to help out here?
also need to ensure that the banner when used works just like traditional tabs. i.e. 1) there is a more square version of the banner that is the default and should be used as such for RCP 2) the ide (currently a workaround in WorkbenchWindow hammers this value) should properly check for the traditional tabs preference to know if it should set the square (setSimple()) style on the banner or the curved style (for R3.0 or the !square tabs preference case.
WorkbenchWindow wasn't checking the value of #showPerspectiveBar, I've submitted a fix that only creates the bar if the setting is true. The submission also links the value of the SHOW_TRADITIONAL_TABS_STYLE to the square/curvey style of the perspective bar.
Andrew, we need to be careful with this approach. There was code in the past that assumed the perspective bar was always created.
I checked uses of the persepectiveSwitcher member in the WorkbenchWindow class, all cases checked for null before using it.
I also had a look. Previously, there were more callers of getPerspectiveBar(), and some assumed that this was non-null, but this is only referenced from run() now, and it checks for null.
"The submission also links the value of the SHOW_TRADITIONAL_TABS_STYLE to the square/curvey style of the perspective bar" - I don't think it should do that. It needs its own preference.
Unfortunately adding a preference was deemed an API change, which is now a no-no. Altering the behaviour of the existing preference was not considered an API change, since it fits into the existing description of what the preference does.
marking as fixed, please re-open with comments if you disagree
