Community
Participate
Working Groups
The style-constants SWT.LEFT_TO_RIGHT and SWT.RIGHT_TO_LEFT are missing. In SWT at least one of these bits is set for each Control (typically inherited from the parent, see javadoc of these constants for further details). Actually also the method Widget.checkOrientation() is missing (which is typically called from the constructor of each control) which inherits the styles from the parent. If there is no parent from where the bits could be inherited (as it is the case for each Shell) the bit SWT.LEFT_TO_RIGHT is set automatically (see the also missing method Widget.checkBits()). Thus it is guaranteed, that each control has at least one of those bits set. It looks as if all the mentioned methods could just be copied from SWT without further RAP-adoption. We consider this bug as major, because we use a LayoutManager which checks these orientation hints and gets totally confused because neither bit is set (which can't happen in SWT). I don't know whether other LayoutManagers would get confused as well.
Since officially supporting SWT.RIGHT_TO_LEFT would mean some work on certain widgets (e.g. Menu, MenuItem, Text, ...) we could also live with supporting only SWT.LEFT_TO_RIGHT as a first step. This is just a matter of enabling this style-constant, since all existing widgets are implemented with a LEFT_TO_RIGHT orientation anyway. As you only want to provide API that is implemented, you wouldn't get into a conflict as well. Nevertheless with enabled SWT.LEFT_TO_RIGHT, RWT would behave more like SWT because at least one of those orientation style-bits is always set and other classes don't get confused if this is missing. As a programmer you still can't set SWT.RIGHT_TO_LEFT, which is totally ok. Attached is a patch, which implements the orientation as SWT does. We checked all SWT and JFace-Code for occurrences and adapted it to the appropiate widgets as well if they existed in RAP (wasn't too much of work). Testcases are adapted as well, one new is provided. Still uncommented is all code that accesses SWT.RIGHT_TO_LEFT. Is it possible to get this fix in RAP 1.1.1 ?
Created attachment 108496 [details] patch for enabling SWT.LEFT_TO_RIGHT correctly
May I ask if there are any points, why this patch couldn't be integrated in 1.1.1 ? Since this patch is very important to us, we'd like to contribute more if there are any open points not considered by us. Currently we have to use '1<<25' as style-constant on each widget that needs to use the existing SWTForms-layoutmanager. very ugly.
Sorry for pushing this, but I get a bit disappointed, because there is no reaction. What's the sense of contributing patches if there's not even a comment about if they are correct or can't be applied by some reason or whatever ?
Sorry for the late response. The patch in general looks very good, only Shell_Test#testConstructor() fails in line 95. My first thought was, that createWidget() and thus checkOrientation() isn't getting called. Though this is true, adding the call to the Control(Composite) constructor didn't fix it. Exchanging the assertion in line 95 with this does the trick: assertEquals( shell.getStyle() | SWT.LEFT_TO_RIGHT != 0 ); It is getting late and I will continue to investigate the next days. Any insights are welcome.
this is strange, for me all tests are working. Did you apply the patch to Shell_Test as well ? Or do you have other local changes not yet in CVS ? line 95 should look like this after applying the patch: assertEquals( SWT.SHELL_TRIM | SWT.LEFT_TO_RIGHT, shell.getStyle() ); Your version is a self-fulfilling prophecy. I'll upload the patch again for current CVS-HEAD - maybe something just went wrong when applying it.
Created attachment 112868 [details] Updated to current CVS-HEAD
Thank you for the second patch - this one works. Committed the patch to CVS HEAD with minor changes: * Moved Control#createWidget up in the source file, close to the constructors * The constructor call hierarchy of Shell and the way parent and display are assigned is a bit messy and doesn't align well with SWT. To make later refactorings safer, I added test cases to Control_Test and Composite_Test that asserts the LEFT_TO_RIGHT flag is always set. * Enabled two places in the Workbench code where mentioning/using the style flag made sense Unfortunately the changes won't make it into 1.1.1. The builds are already on the way to the Ganymede Service Release.
Created attachment 112950 [details] Patch against CVS HEAD before commit
Rüdiger, I think your two new testcases are wrong: >> assertTrue( ( control.getStyle() | SWT.LEFT_TO_RIGHT ) != 0 ); Will always be true, because with this code you 1) get the style 2) set SWT.LEFT_TO_RIGHT 3) test against != 0, which will always be true, because you just set the bit in step 2 I think you want to do this: assertTrue( (control.getStyle() & SWT.LEFT_TO_RIGHT)!=0 ); or assertEquals( SWT.LEFT_TO_RIGHT, control.getStyle() & SWT.LEFT_TO_RIGHT );
Stefan, thanks forthe hint. I fixed the tests accordingly. Changes are in CVS HEAD.
