Bugzilla – Full Text Bug Listing
| Summary: | Unified toolbar: filling separator causes preferred size to be at 1200 pixels | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Thomas Singer <eclipse> | ||||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | lshanmug, Silenio_Quarti | ||||||
| Version: | 3.8 | Keywords: | triaged | ||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Mac OS X | ||||||||
| Whiteboard: | stalebug | ||||||||
| Attachments: |
|
||||||||
Created attachment 220187 [details]
screenshot
With macOS 10.14 and SWT 4.922 I'm getting following output in the terminal: 2018-10-01 15:07:53.781 java[905:32461] It's not legal to call -layoutSubtreeIfNeeded on a view which is already being laid out. If you are implementing the view's -layout method, you can call -[super layout] instead. Break on void _NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future. I'm reporting this because I have found another width-related bug with the unified toolbar solely with macOS 10.14 (width is excessively large), but I can't reproduce in a tiny snippet - only with SmartSVN 9.3 when opening the log or revision graph. (In reply to Thomas Singer from comment #0) > Created attachment 220186 [details] > test case to reproduce > > Using SWT 3.833 (taken from the org.eclipse.swt.cocoa.macosx.x86_64*.jar) we > found out that the preferred size of a toolbar is - indepedent of its > content - 1200 pixels wide, if it contains at least one filling separator. > Usually, the computation of the preferred size returns the minimum size > where the control is fully visible. This contract is broken for filling > separators, because the toolbar returns a much larger width. The large width of the toolbar is due to setWidth(SWT.SEPARATOR_FILL) on line 18. Using setWidth(0) or setWidth(SWT.DEFAULT) doesn't cause this. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Created attachment 220186 [details] test case to reproduce Using SWT 3.833 (taken from the org.eclipse.swt.cocoa.macosx.x86_64*.jar) we found out that the preferred size of a toolbar is - indepedent of its content - 1200 pixels wide, if it contains at least one filling separator. Usually, the computation of the preferred size returns the minimum size where the control is fully visible. This contract is broken for filling separators, because the toolbar returns a much larger width.