Community
Participate
Working Groups
I20041216-1200, Solaris, Motif, CDE If you close all perspectives and then open the Java perspective, the layout of the Java perspective is wrong. The editor area is given almost all of the space, and the outline/explorer/problems views are all squished.
And when you then Reset, the window adjusts itself. Odd.
Stefan, would you be able to look into this?
I believe the cause is the same as bug 69615: ever since views stopped resizing proportionally window, the initial ratios in a perspective are no longer deterministic.
The problem is in the initial layout of the perspective, which is specified as ratios, not in resizing. No resize is necessary to show the problem. I don't see why this can't be deterministic based on the current size of the window.
Does not occur in 3.0.1, so it's not directly caused by the resize change.
Occurs on Windows too. This looks really goofy. Please consider for M7.
Re: comment 5 You're right, this is different. I should have read the steps to reproduce more carefully.
The bug is in WorkbenchWindow. It creates the WorkbenchPage control and the "getWindowAdvisor().createEmptyWindowContents" control in the same composite, which has a FillLayout(SWT.HORIZONTAL) for its layout. This means that when the workbench page composite gets its initial size, it's sharing half the window with the "no perspectives" composite and the initial layout is computed for a thin, tall composite. This is the size used to compute the initial view sizes, which don't change when the page gets its final (correct) size. This could be fixed by using a WorkbenchWindow layout that makes all the children overlap and fill the window, or by disposing the "no perspectives" composite before creating the workbench page controls. If I recall correctly, Eclipse 3.0 didn't make use of createEmptyWindowContents, so the workbench page ended up alone in the window and was computed with the correct width.
I'll fix it up, as this was due to the createEmptyWindowContents change.
Created attachment 20310 [details] Patch to WorkbenchWindow I've changed the layout to be a StackLayout, since the empty window contents was not been created/disposed in the same place as the workbench page's controls. This may lead to extra layouts though. Stefan, could you please review this patch?
Nick: the patch looks okay to me. I verified that there are no extra layouts being triggered on perspective switches, and that it fixes this PR. There does seem to be 3 redundant layouts of a PartSashContainer when opening the first perspective, but I don't think that's due to your patch. Looking through the code, I think we may be able to squeeze out a small amount of extra performance like this: - Get rid of the pageComposite and the StackLayout - Create the page controls directly under the shell, and use the center control of the TrimLayout like a StackLayout. That is, rather than this: layout.topControl = newPage.getClientComposite() use this: defaultLayout.setCenterControl(newPage.getClientComposite()); This will eliminate one SWT Composite and one layer of layouts. This is a very minor optimization, so just take it as a suggestion.
Unfortunately I don't think we can get away with that optimization since the app has control over where the page composite is placed, if it has a custom layout. See IWorkbenchWindowConfigurer.createPageComposite. In the case of the default layout, we could do this, but then we'd have different code for the two cases. I suggest leaving as-is for 3.1.
I've released the patch.
Verified in I20050509-2010.
