Comment 1 Thomas Singer 2011-07-26 04:32:38 EDT

Created attachment 200343 [details]
Sample to reproduce the bug

Comment 2 Felipe Heidrich 2011-07-26 12:12:36 EDT

Lakshmi, please take a look at this problem.
Maybe the fix is that Composite#getChildren() needs to be reimplemented in Shell to exclude the toolbar shell.

Comment 3 Lakshmi P Shanmugam 2011-09-08 10:35:04 EDT

Created attachment 202999 [details]
patch

Removed Shell._getChildren() as native toolbar shouldn't be considered during layout. But, it is part of the trim so modified computeTrim() to consider its width. Also, modified getToolBar() to return null when the shell has style SWT.NO_TRIM.
Silenio, can you please review the patch?

Comment 4 Silenio Quarti 2011-09-13 09:54:50 EDT

With this patch, is the toolbar being disposed when the shel is disposed? I have not tried, but I expected it would not since the release cycle (releaseWidget/releaseHandle) is called on all controls returned by _getChildren().

Comment 5 Lakshmi P Shanmugam 2011-09-15 15:41:47 EDT

Created attachment 203447 [details]
patch-2

I checked for the references of _getChildren() and included toolbar in the required methods. The modified patch disposes the toolbar when shell is disposed.
Silenio, please review.

Comment 6 Silenio Quarti 2011-09-23 18:01:05 EDT

- releaseChildren() should call toolBar.release(true) instead of dispose() to keep it consistent with the other releaseChildren() implementations.  It is actually better to move the code into releaseWidget() (and call dispose()). It is similar to Control.releaseWidget() where it disposes the menu.

- The code in computeTrim() does not make sense. The trim width does not grow because of the toolbar.   The code should go in computeSize().  This is similar to the TabFolder case: the trim width is fixed as you add items and it only accounts for the left and right borders (paddings). But the computeSize changes.

Comment 7 Lakshmi P Shanmugam 2012-03-26 06:59:47 EDT

Created attachment 213170 [details]
patch-3

Modified the patch based on above comment. The trim width of the native toolbar is now computed in the Toolbar's computeTrim().
Silenio, can you please review?

Comment 8 Thomas Singer 2012-03-26 11:41:23 EDT

I'm a little bit confused about 3.8 vs. 4.2 - where I can find all 4.2 downloads (<http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M6-201203151300/index.php>) similar to those from 3.8 (<http://download.eclipse.org/eclipse/downloads/drops/S-3.8M6-201203141800/index.php>), especially the deltapack?

Comment 9 Silenio Quarti 2012-03-26 14:27:16 EDT

(In reply to comment #7)
> Created attachment 213170 [details]
> patch-3
> 
> Modified the patch based on above comment. The trim width of the native toolbar
> is now computed in the Toolbar's computeTrim().
> Silenio, can you please review?

Patch looks fine.

Comment 10 Bogdan Gheorghe 2012-03-26 14:33:55 EDT

Thomas, in response to your question in Comment 8, we are in the process of transitioning the 3.8 build to 4.2. Currently we are only producing the 4.2 SDK but once we finish transitioning the build, it should contain all of the other build artifacts as well. 

If you want to keep an eye on this work, checkout Bug 355430.

Comment 11 Lakshmi P Shanmugam 2012-03-27 06:29:19 EDT

Thanks Silenio!
Fixed in master > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=33615efba6b3b14d1b8ee0928c8a1f12f629315a