Community
Participate
Working Groups
Build Identifier: Eclipse 3.7 I20110127-2034 and GEF 3.7 I201101272050 Open a GEF Editor based on GraphicalEditorWithFlyoutPalette with the Palette closed. Open the Palette, the PaletteToolBar space is too large for its child tools. Reproducible: Always Steps to Reproduce: 1. Open the Shapes example. 2. Create a new Shapes file. 3. Open the file so that the GEF Editor opens. By default the palette is closed. 4. Open the palette. The top palette toolbar has extra space. Resizing the palette corrects the problem.
Created attachment 187967 [details] Screenshot of palette Screenshot of the palette area.
Can I ping this one?
(In reply to comment #2) > Can I ping this one? Well, you may try... Where could you reproduce it? Is it reproducable on both, Cocoa and Carbon, or is it limited to one of the platforms?
Hi, it happens on all platforms. It's not a Mac thing.
(In reply to comment #0) > Build Identifier: Eclipse 3.7 I20110127-2034 and GEF 3.7 I201101272050 > > Open a GEF Editor based on GraphicalEditorWithFlyoutPalette with the Palette > closed. Open the Palette, the PaletteToolBar space is too large for its child > tools. > > Reproducible: Always > > Steps to Reproduce: > 1. Open the Shapes example. > 2. Create a new Shapes file. > 3. Open the file so that the GEF Editor opens. By default the palette is > closed. > 4. Open the palette. > > The top palette toolbar has extra space. Resizing the palette corrects the > problem. If the palette is open, close it, close the Shapes editor and re-open the Shapes file.
I investigated the problem and it seems to be caused by the combination of two things: 1) within FlyoutPalatteComposite#setState, a min size calculation with a width hint of 0 is performed (minWidth = Math.max(pViewer.getControl().computeSize(0, 0).x, MIN_PALETTE_SIZE);), which leads to a preferred size calculation within PaletteContainerFlowLayout (used in the ToolbarEditPart's figure) that yields a result of (23, 80), because it assumes not to be able to fill one the row with all provided figures. 2) the preferred size computed during this min width calculation does not seem to be updated when the palette becomes visible (no revalidation of the PaletteViewer's figures is performed). One can easily reproduce this, by changing the min size calculation to use a width hint of SWT.DEFAULT or by adding a dummy calculation (pViewer.getControl().computeSize(SWT.DEFAULT, SWT.DEFAULT);) before, so that the first preferred size calculation that is performed yields a result of (80, 23) and everything works fine. I will thus have to investigate, why revalidation does not take place, and - eventually - how and where to force it.
Thanks, Alexander. Of course this is only happening in Eclipse 3.7 + GEF 3.7 (latest builds). It works fine in 3.6. Now whether the problem is in Eclipse or GEF I don't know.
Good to know its a regression we are facing here. Maybe it has something to do with the changes related to OrderedLayout that I made. I will take a look.
As I had already assumed, the regression was introduced by bug #88884. It was introduced by pulling up differently implemented isSensitiveHorizontally and isSensitiveVertically methods into OrderedLayout, whereby the implementation of FlowLayout was lost (that of ToolbarLayout was taken). Fixed it by restoring both methods in FlowLayout and ToolbarLayout and by removing them in the OrderedLayout super class. Verified that the palette can no longer be reproduced with the fix in place. Committed all changes to cvs HEAD (3.7M6). Closing as fixed.
Confirmed working OK on Windows 7 in GEF I201102212050. Thanks, Alexander.
