Community
Participate
Working Groups
Normally, this would be filed as a cool bar bug, but this change in behaviour was introduced by the new look work. It seems as though someone might ignoring an event that they should be paying attention to. STEPS TO REPRODUCE: 1.) Grab one cool item in the cool bar, and try to drag it to a new row. OBSERVED RESULTS: The cool item goes into a new row, but that row is obscured by the views. DESIRED RESULTS: The views should be aware of the new limitations on their size and resize appropriately.
Mike, Is this a dup of bug 51655?
nope, does not look related to bug 51655
*** Bug 53522 has been marked as a duplicate of this bug. ***
Veronika: this is the bug we were talking about.
The UI worknbench has lost some code that looked like this: coolbar.addControlListener(new ControlAdapter() { public void controlResized(ControlEvent e) { Rectangle area = shell.getClientArea(); FormData data = (FormData)(banner.getLayoutData()); Point size = banner.computeSize(area.width, SWT.DEFAULT); data.height = size.y; shell.layout(true); } });
Maybe Tod remembers where he put this code originally.
tod see last comment
stefan, this looks related to layout changes, could you comment on comment #5?
This was a hack that was put in in the old layout due to the toolbar not resizing properly. It was in WorkbenchWindow.configureShell(). It was removed when the cool bar work was done as it was a hack to get around a resize problem that appeared to have been fixed.
This bug no longer appears here. Coolbars can now be moved to new rows successfully.
Agreed, this has worked for a while. Closing.
Problem still exists in I200405111600.
*** Bug 61659 has been marked as a duplicate of this bug. ***
This is not a bug in SWT. The UI code has to detect the resize of the coolbar and cause a layout on the whole shell. Moving to Platform UI.
stefan, can you look through here and note why this code is gone if you are aware of why..
*** Bug 62411 has been marked as a duplicate of this bug. ***
Fixed in head. There was caused by a combination of two bugs: 1. WorkbenchWindow was calling LayoutUtil.resize on the coolbar's parent, although it should have been calling it on the coolbar itself. 2. LayoutUtil.resize was relying on SWT triggering a layout whenever setBounds is called. However, SWT does not re-layout if the new bounds are the same as the old one (this is the correct behavior when the layout is triggered by the parent being resized, but not when the change is triggered by a child). I've added a check to force a layout in this situation.
This is better but still not fixed in I200405200800. The first time I drag a coolitem to a new row, the new row is not created. If I take a second coolitem and drag it down, then the row is created, and after that point everything works fine. The first one does not work. Reproducable on both Gtk+ 2.2 and Gtk+ 2.4.
Please consider improving the fix for 3.0.
I can no longer reproduce this on windows.
Billy, can you investigate the GTK issues? I suspect the problem is in the coolbar resize listener in WorkbenchWindow, which compares shell sizes to determine if a resize was triggered by a window resize or a change in the CBanner or coolbar. The very first time, it may erroneously believe that the shell size has changed because it hasn't recorded a previous size yet.
Created attachment 10910 [details] Patch to use the client area instead of the shell size The problem is actually because asking for the shell size is unreliable in the X Window System due to difficulties with window manager policies. This patch fixes the problem by using the shell's client area instead of its size.
Checked in Billy's patch to WorkbenchWindow.
Verified in 20040520 - 21:14
Verified on I200405210010 using both Gtk+-2.2 and Gtk+-2.4.
Verifid with Build id: 200405210800 on Windows XP.
Verifid with Build id: 200405210800 on Mac OS 10.3.3.
I can still recreate this on R3.0 RC1 on Win XP.
Michael: what are you doing to recreate it? I can't reproduce this using the steps in the original PR.
I can't recreate this any longer.
