Community
Participate
Working Groups
Created attachment 255116 [details] Zipped sample project This issue has originally been raised by me in the SWT community forum [1]. While I found a workaround in the meantime, I still consider this a bug, as Mac OS X and Windows 7 render the same wizard page vastly different. The wizard page under Mac OS X has "normal" sizes, while under Windows 7 it vertically extends all the way to the edges of the screen. I have attached a sample project. Just start the plugin (I tested under Eclipse Mars) and select "Example Wizard" from the "Wizard" menu. That opens the single-page wizard demonstrating the problem. Two screenshots illustrating it will follow. [1] <https://www.eclipse.org/forums/index.php/m/1701180/#msg_1701180>
Created attachment 255117 [details] The problematic wizard page under Windows 7
Created attachment 255119 [details] The problematic wizard page under Mac OS X (Yosemite)
In the attached snippet(which is JFace based), size for Label with SWT.WRAP style is calculated and applied via below code: GridDataFactory.fillDefaults().grab(true, false).hint(convertHorizontalDLUsToPixels(IDialogConstants.MINIMUM_MESSAGE_AREA_WIDTH), SWT.DEFAULT).applyTo(label); This snippet doesn't highlight the exact problem with SWT, if possible please narrow down the problem to an SWT snippet ? Sharing with UI team for initial investigation.
Created attachment 256358 [details] The problematic wizard page under Ubuntu Linux FWIW, the example project also exhibits this problem under Ubuntu Linux, as illustrated by the attached screenshot (again, tested under Eclipse Mars).
(In reply to Niraj Modi from comment #3) > This snippet doesn't highlight the exact problem with SWT, if possible > please narrow down the problem to an SWT snippet ? Sorry, I wasn't able to produce an SWT-only sample project, carving out the relevant parts of the JFace Wizard. The WizardPage itself, however, is rather simple: @Override public void createControl(Composite parent) { Composite container = new Composite(parent, SWT.NONE); GridLayoutFactory.fillDefaults().applyTo(container); Label label = new Label(container, SWT.WRAP); label.setText( "Some very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very, very loooooong label which should wrap."); GridDataFactory.fillDefaults().grab(true, false) .hint(convertHorizontalDLUsToPixels(IDialogConstants.MINIMUM_MESSAGE_AREA_WIDTH), SWT.DEFAULT) .applyTo(label); setControl(container); } The problem goes away as soon as the vertical size hint is some value other than SWT.DEFAULT, but guessing the *vertical* size of a text with line with line wrapping is pretty much impossible. Hence, using SWT.DEFAULT for the "control's preferred size" (Javadoc of Control.hint) should work.
(In reply to Andreas Sewe from comment #5) > GridDataFactory.fillDefaults().grab(true, false) > > .hint(convertHorizontalDLUsToPixels(IDialogConstants. > MINIMUM_MESSAGE_AREA_WIDTH), SWT.DEFAULT) > .applyTo(label); FWIW, for Windows there exists a workaround: GridDataFactory.swtDefaults().align(SWT.FILL, SWT.BEGINNING).grab(true, false) .hint(convertHorizontalDLUsToPixels(IDialogConstants.MINIMUM_MESSAGE_AREA_WIDTH), SWT.DEFAULT) .applyTo(label); Unfortunately, this does not work unter Ubuntu Linux. There, I get a wizard page filling all the vertical screen space either way. :-( Anyway, I hope this helps you guys narrowing down the issue.
(In reply to Andreas Sewe from comment #6) > (In reply to Andreas Sewe from comment #5) > > GridDataFactory.fillDefaults().grab(true, false) > > > > .hint(convertHorizontalDLUsToPixels(IDialogConstants. > > MINIMUM_MESSAGE_AREA_WIDTH), SWT.DEFAULT) > > .applyTo(label); > > FWIW, for Windows there exists a workaround: > > GridDataFactory.swtDefaults().align(SWT.FILL, > SWT.BEGINNING).grab(true, false) > > .hint(convertHorizontalDLUsToPixels(IDialogConstants. > MINIMUM_MESSAGE_AREA_WIDTH), SWT.DEFAULT) > .applyTo(label); > > Unfortunately, this does not work unter Ubuntu Linux. There, I get a wizard > page filling all the vertical screen space either way. :-( Should I open a separate bug for Linux (as it may be a different issue there, given that my workaround doesn't work)?
(In reply to Andreas Sewe from comment #7) > Should I open a separate bug for Linux (as it may be a different issue > there, given that my workaround doesn't work)? FYI, the Linux problem still exists under Neon M7. Could you please have a look at my example project? I know it's not a SWT-only example, but it is rather minimal. It's just frustrating spending time to distill your code into a minimal example that reliably reproduces the problem and then being told "not minimal enough". :-(
(In reply to Andreas Sewe from comment #8) > (In reply to Andreas Sewe from comment #7) > > Should I open a separate bug for Linux (as it may be a different issue > > there, given that my workaround doesn't work)? Opened Bug 498756. This bug can now be "Windows only".
@Patrick: FYI, this is the bug we talk about today in Darmstadt.
Andreas, thanks for putting me in c/c. Assigning to me as I will be investigating 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.
