Community
Participate
Working Groups
Build Identifier: 3.4.2.20091204_r352 On creating a new RCP application and had used setShellStyle on Windows to disable the maximise button of the application, and found that when the application launches in Bi-direction supported languages, the main application bar and menu bar retains its LTR rendering while the rest of the view works fine. I tried this using SWT.MIN,SWT.MAX and SWT.CLOSE to set the shell style and when any of them were used the Bidi support was breaking for Application title bar and Menu bar. Reproducible: Always Steps to Reproduce: 1. Write a new RCP application 2. In ApplicationWorkbenchWindowAdvisor override the preWindowOpen method. 3. use theIWorkbenchWindowConfigurer object's setShellStyle method to set to SWT.MIN/MAX/CLOSE. 4. Launch the application on a environment where a bi-directional support language is supported (eg. Arabic) 5. See that the view is coming in RTL mode while the menu bar and Application title bar do not come in RTL but in LTR mode. 6. Now go back to the sample application and comment the line to do the SetShellStyle and re-launch the application in Arabic locale 7. See that the application title and Menu bar appear correctly in RTL mode. This needs to be fixed since we cannot do away with disabling the Maximise button for small view applications.
Moving to Platform UI
Does this problem happen with regular SWT shells?
(In reply to comment #2) > Does this problem happen with regular SWT shells? I am not sure but I had tested developing a simple RCP app and was able to reproduce this issue everytime.
Can you reproduce the problem with 3.8M2? http://download.eclipse.org/eclipse/downloads/drops/S-3.8M2-201109151308/index.php
(In reply to comment #4) > Can you reproduce the problem with 3.8M2? > http://download.eclipse.org/eclipse/downloads/drops/S-3.8M2-201109151308/index.php Hi, I was able to reproduce the same issue using Eclipse Indigo, so let me know if you want me to try with the build specified by you here. Thanks
Hi Shankar, if you force RTL with the '-dir rtl' argument to your application, does the menu bar stay in shell's title bar and menu bar RTL mode?
(In reply to comment #6) > Hi Shankar, if you force RTL with the '-dir rtl' argument to your application, > does the menu bar stay in shell's title bar and menu bar RTL mode? Hi the -dir RTL also was not successful in getting the Menu bar and application title bar to RTL. It was in LTR mode.
Passing on to SWT for a look to see if there's a relationship between the flags...
I can see a screenshot ? do you have a simple snippet that reproduce the problem ?
For the record, I tried this on Windows XP but was not able to reproduce the problem. However, this might be because my OS is in English.
Created attachment 205095 [details] Sample app and how to reproduce the problem Hi, I am not sure if you have checked it in a Eclipse environment which can support Arabic/Hebrew kind of languages. Can you please check if the Eclipse runtime in which you have tested has the capability of launching the RCP with -dir RTL or -nl ar so that all of the APP comes in RTL. Why I am asking this is because, the problem is reproducible in all Windows environments. Here I am attaching the basic RCP application which you should be able to see the issue on launch, if the application launches in RTL mode using the Eclipse runtime. Once you see this behavior, in ApplicationWorkbenchWindowAdvisor, in preWindowOpen() method there is a method added configurer.setShellStyle(). Please comment the line and relaunch the application and you would notice the issue is gone. Let me know if you need any other input.
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. If you have further information on the current state of the bug, please add it. 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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
