Community
Participate
Working Groups
Build 20020611 1. Size the workbench and Reset Toolbar Layout so that you have two rows of items, with only a couple of items on the second row. 2. Size the workbench smaller and smaller vertically. When the items on the first row can no longer fit (due to minimum size reached for all), the platform widget will start to wrap items from row 1 to row 2. Notice that you "lose" the original second row items. The WorkbenchWindowLayout is being called during the resize and the size of the coolbar recomputed, so this appears to be an SWT bug. If you Reset Toolbar Layout, the problem will be fixed, but that is because wrap indices are explicitly being set.
Felipe, please investigate. It's very late to be putting changes in, but this seems quite bad to me. We should try to fix it if possible.
I'm testing on Eclipse 20026012 On the step 2 I think you mean resize it horizontally ? When you resize to workbench smaller and smaller in some point the items on the right side to row 1 will be moved to left side of the row 2, so the original items (the "loses" items) goes to the right where they are not visible. I could reproduce this same behavior on IE, the difference is that IE will auto wrap the items to next row in order to have them visible. Lynne, The problem I saw is the one you've reported ? Note, if you resize the workbench to be wider again all the items return to the right place.
Yes, horizontally is what I meant and yes this is the problem I am referring to. This is not a big issue for Eclipse, but it may be for WSAD, which has many, many cool items as I understand it. It seems like a computeSize problem (i.e., the larger height is not being answered when the coolbar is auto-wrapped by the platform) or it could be a problem in Eclipse with the WorkbenchWindow (though I did investigate far enough to verify that the size of the coolbar is being recomputed and reset during resize).
I was wrong when I said that the original items on the row 2 are located on right of the row. Actually, they are moved to a (new) third row. The problem is, when autobreak happens the last item of the row 1 becomes a break, so the first item of row 2 who already has the break flag set, will be lay out in a third row (it's, the OS is respecting the break flag for all). But, the CoolBar should have its height adjust to 3 row, what doesn't happened! That's why you can't see the problem when you have only one row. Try this same scenario starting if 3 rows (eventually the items on the row 2 will be dislocated to row 3, and the items on row 3 to row 4, and so on). On windows XP the OS provides a callback when a autobreak happens, I believe can use this to workaround this problem, but for windows 98 and windows 2000 I have no clue how to fix this problem so far.
Also note that this behavior (i.e., auto-wrapping items when the minimum size of all coolitems on a row is reached) is not emulated on Linux. It probably should be to be consistent.
The emulated Coolbar does the autowraps. BTW, there is a PR about that - 19654 (it does not undo the autowraps when the main windows gets wider again).
It doesn't do the autowrap in the F3 build on Linux. I just tried it. Close All Editors and Perspectives. Open a Java Perspective. Size the window smaller horizontally. No wrapping occurs. The coolbar stays one line and items are clipped.
The above was Linux-Motif, RH 7.2, KDE.
Ok, after you got the first item clipped keep resizing the window to be smaller. At some point the autobreak will happens. I think the emulated autobreak is not considering the last item of the coolbar. It's another bug.
Ack to the above. If you keep resizing smaller auto-wrap will occur. However, when you resize bigger you do not get back to the state you were in (unlike windows which will undo the auto-wrap it did if you resize the window bigger).
Yes, on the emulated coolbar the items do not return to the original state (bug 19654). When I tested the fix for this probem (fix for: 19654) I could see (on Linux) the same problem described on 20190, tag --Felipe Heidrich 2002-06-13 17:39--
fixed > 20020709
Fixed in 2.0.1
