Bugzilla – Full Text Bug Listing
| Summary: | [BIDI] Eclipse 3.1M3 shows in Right-To-Left orientation | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Genady Beryozkin <eclipse> |
| Component: | UI | Assignee: | Tod Creasey <Tod_Creasey> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | darin.eclipse, pascal, salexb, semion, wassim.melhem |
| Version: | 3.1 | ||
| Target Milestone: | 3.1 M4 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 79232 | ||
| Bug Blocks: | |||
|
Description
Genady Beryozkin
Are you using -dir on the command line? I'm not using it. I simply clicked the eclipse executable. What are the options? Why is right-to-left the default? Please trust me that no hebrew (not sure about arabic) speaking java developer will ever want to have his Eclipse in this orientation. It isn't the default... I can't imagine why this is happening to you. As far as I knew, the only way to get this orientation was to supply a command line argument. Until we get to the bottom of this you can run with eclipse -dir ltr to get back to the proper orientation. Upping priority. What is your Locale? If your language is Arabic, Hebrew, Farsi or Urdu right to left is the default. My system is non-localized WindowsXP (English interface) with Hebrew input installed. The default locale is "English (United States)". I would like to stress that even if the default locale is Hebrew or Arabic, Eclipse should start in left-to-right direction. RCP applications that target BIDI customers should be able to manually switch the interface direction, but this should not be enabled as the default. OK that explains it. It is the language that the java Locale class believes you are in that is the issue here - it looks like Java believes that your language is Hebrew although it is just your input mode that is Hebrew if I am not mistaken correct? Adding Alex and Semion (the Eclipse RTL experts) here as perhaps we want to make the choice to right to left default more restrictive - i.e. only if both language and country match as this is the second person we have had who uses an English locale with a BIDI language selection. I think java is indeed the issue. JDK1.5.0 correctly detects the "US" locale while JDK1.4.2 detects "iw" locale. I still think that the default (under any combination of language and country) should be LTR+english UI. User preference should control the direction or at least some kind of manually installable UI patch. Just use -dir ltr on the command line and this overrides all Locale based settings. Thanks for the heads up on JDKs - this will help us a lot in making our decision. I can't recreate situation, when Java isn't correctly react on the changes in
the system locale. We all works in not localized XP, and don't have such
problems. As far as I know, change of keyborad language can cause some changes
in behaviour of AWT widgets, or in the alignment of the windows title's
contents, but it is all... Can you confirm, that even simple progarm like this:
...
static public void main(String[] s) {
System.out.println(Locale.getDefault().toString());
}
gives you unexpected result?
Tod, anyway, I would like remind you about one more our suggestion, which can
be useable in those cases: additional editable property in the properties
file, like eclipse.ini.
Finally, in the sequence of priorities, can be used:
1) parameter DIR
2) orientation property (which can be LTR as a default; but user can change
it, if he/she whant)
3) parameter NL (which is used to change default locale)
4) system locale.
If additional property will be used, we don't need system locale as a default to determine program orientaion. In this case default orientation can be always LTR. We have a property (eclipse.orientation) in M3 that can be used. I am pretty sure that -nl will change the Locale for you but I should double check. We are already using the order you outline below. Genady has identified a bug in the 1.4.2 JDK that appears to be fixed in 1.5 - which are you using? If we don't use the Locale than no one will ever get rtl from a freshly downloaded Eclipse. I am not sure about the usage patterns of people in bidirectional langugages so I am not sure what thier expectations would be. If this is acceptable we should consider doing away with the Locale test as it is not consistent. Yes, parameter NL changes the default locale - it probably means, that he/she wants to use corresponding resource bundles. Note, that rtl orientaion make sence only, if product is translated or created using one I use Java 1.4.1 of IBM and 1.4.2 of Sun, but neither with this, nor with other known versions of JDK (1.3,1.4.0) I can't recreate this problem on our computers. Probably, we need more information about Genady's specific situation. As far as I understand, freshly downloaded Eclipse will contain editable eclipse.orientation property, which symply should be updated by user, that want work with workbench in rtl orientation. Given the inconsistency that users are having with the Locale determined by the JDK we have decided that the best option is to only do the locale check if the -nl command line parameter has been set. Fixed in build >20041110 I will try to provide more info and steps to reproduce later today. will freshly downloaded eclipse start in LTR now? static public void main(String[] s) {
System.out.println(Locale.getDefault().toString());
}
prints "iw_IL" on my machine. The precise config is
Windows XP SP2, Regional settings: "United States". Country set to "Israel".
Hebrew keyboard input is installed.
(pressed commit too early) more details, java properties: java.vm.version=1.4.2_05-b04 sun.os.patch.level=Service Pack 2 file.encoding=Cp1255 user.language=iw java.version=1.4.2_05 Genady Tod, I checked integration build from 11/17. Unfortunately, orientation isn't
set, as we planned, and workbench, as previously, appears rtl-oriented, when
is starts in Hebrew locale. As far as I understand, problem here is in the
method Workbench.checkCommandLineLocale():
.........
boolean abortCheck = false;
//Do not process the last one as it will never have a parameter
for (int i = 0; i < commandLineArgs.length - 1; i++) {
if(commandLineArgs[i].equalsIgnoreCase(NL_COMMAND_LINE)){
abortCheck = true;
break;
}
}
if(abortCheck)
return SWT.NONE;
........
NL_COMMAND_LINE, as far as I can see, can't appear in this stage in the
commandLineArgs, and SWT.NONE can't be returned from this part of the code.
However, if -nl parameters was used, default locale was already set in
accordance with value of this parameter. Therefore,
Workbench.checkCommandLineLocale() can return correct orientation in case,
when -nl parameter is used, but it can't return SWT.NONE in opposite case.
I suggest to set additional system property, which will indicate, that -nl
parameter was really used:
1)EclipseStarter.processCommandLine():
........
// look for the nationality/language
if (args[i - 1].equalsIgnoreCase(NL)) {
System.getProperties().put(PROP_NL, arg);
System.getProperties().put("osgi.nl.user", arg);
found = true;
}
........
2)Workbench.checkCommandLineLocale():
........
if (System.getProperties().get("osgi.nl.user") == null)
return SWT.NONE;
Locale locale = Locale.getDefault();
String lang = locale.getLanguage();
if ("iw".equals(lang) || "ar".equals(lang) || "fa".equals(lang)
|| "ur".equals(lang))
return SWT.RIGHT_TO_LEFT;
return SWT.NONE;
......
One more minor I problem I see in the default parameters of the run-time
workbench. As far as I understand, -nl parameter is always set - probably, in
accordance with current osgi.nl property. I think, that -dir parameter should
always be set too - in accordance with orientation of the base workbench.
Reopening as requested Adding Pascal for the OSGI input on this. Thanks Semion - your analysis seems correct. I don't think we should set the - dir property however - the whole problem with this is that locale is being determined by the virtual machine which is wrong for many users. If this is how the osgi support is setting the locale we should remove this functionality all together. I have logged Bug 79232 so that we can see about finding out this information from the OSGI team. Until we have it however I will turn off this feature so as not to cause more trouble. I have changed the Workbench to use the querying of the system property implemented in Bug 79232. Fix is in builds >20041208 Help windows still open in the wrong orientation in build 200412081200 I don't think help is using our fixed mechanism. I have logged Bug 80802 for this. Is it only help you have this problem with? I will check the next integration build for more inconsistencies. Genady It seems to be ok now (build I-200412141321). I'm not sure whether the following is related or not, but the title of the first column (the one with the icons) in the problems view appears to me as a square box. How should it appear to you? Also in all properties pages (e.g., project properties), the area on the left is missing a border. Thanks Genady. The icon title problem is likely a rendering issue with your locale and the spacing problem on the properties page is likely unrelated. I'll add them to my test pass today. Remarking fixed. Verified in 20041214 I have found some problems with PDE launches. I have checked it earlier, but for some reason didn't see it. I hope to provide a reproducible test case later. Tod, I again have question about parameters of run-time workbench. In the latest builds they don't appear in the "Program arguments" field of the configuration dialog, but in fact parameter -nl with the value of default locale is always added to command line (see WorkbenchLaunchConfigurationDelegate, method getProgramArguments() ). As result default orientation of run-time workbench depends on locale and is not always ltr, as expected. This is the problem I was experiencing, but I cannot reproduce it anymore. The parameter set form -nl shows up as osgi.nl.user in the system properties. osgi.nl and the -nl command parameter are always set regardless of what you entered on the command line. "-nl command parameter are always set regardless of what you entered on the command line" only for run-time workbench. Therefore problem appears only in run-time workbench. Here is example: you start eclipse in Hebrew locale without -nl parameter (it appears in ltr orientation), configure run-time workbench without -nl parameter too, and suddenly it appears in rtl orientation - wich is wrong. If this is done with purpose to pass to run-time workbench the same locale, in which general workbench is running, we need use instead locale from osgi.nl.user property(it means, that user set locale explicitly), and not from org.eclipse.pde.ui.nl, which is actually used (its default value is set in the PDECore as Locale.getDefault().toString() ). In case when osgi.nl.user isn't set, -nl parameter should not be added. Darin is the Run Tinme Workbench doing this? It is a pain for people who don't want to set locales. Semion if this is an issue we should log another PR to debug. The runtime workbench launcher is owned by PDE. As of 3.1M4, we don't pre-set the launcher with any program args. If you have existing launch configurations with "-nl xxx" just delete this arg from the program args text field. I don't have existing launch configurations with "-nl xxx". I work with some
build after M4 (more exactly - N20050111).
And with this build, when run-time workbench is configured and parameter -nl
isn't defined by user in the configuration dialog, it is added to the command
line by WorkbenchLaunchConfigurationDelegate in the method getProgramArguments
():
...
if (!programArgs.contains("-nl")) { //$NON-NLS-1$
programArgs.add("-nl"); //$NON-NLS-1$
programArgs.add(TargetPlatform.getNL());
}
...
As far as I understand, this code works exactly when I use configuration
without -nl xxx.
Method getNL() from TargetPlatform returns value of
the "org.eclipse.pde.ui.nl" property. Default value of this property is set by
PDECore in the method initializeDefaultPluginPreferences() as following:
...
preferences.setDefault(NL, Locale.getDefault().toString());
...
Therefore, was used -nl parameter in configuration of general workbench or was
not used, run-time workbench receive it in the command line.
guilty. we do implicitly add program arguments, but -nl should not be one of them. |