Community
Participate
Working Groups
Created attachment 133256 [details] Snapshot illustrating the problem. Build ID: I20090313-0100 Steps To Reproduce: Use the Bidi (Arabic/Hebrew) enabled version of Windows. 1. Start eclipse with following arguments: "-nl en -dir rtl". 2. Creat Java project. 3. Select "New->(Java)Class". 4. On Java Class wizard page add any Interface. Result: - parenthesis in signature of 'main' method are shown incorrectly. - entries in interfaces list are right justified (have to be left aligned since the expected text there should only contain English characters) (see javaclass.jpg). The same is true for "Superclass" field. More information:
TextProcessor is only invoked for "iw", "he", "ar", "fa", and "ur" Also, the snapshots were marked as images, but our browsers complained they were corrupt. If they are something else (like a zip or archive) I think they need to be marked as such (or simply as binary streams) for us to see them. PW
The problem has nothing to do with Text Processor but rather with incorrect text orientation attribute setting for pertinent controls. Many other components in Platform are aware of this problem and takes care of it. BTW. The problem exists with "-nl he" eclipse argument as well. I am reattaching not archived snapshot.
Created attachment 133413 [details] Snapshot illustrating the problem.
> - parenthesis in signature of 'main' method are shown incorrectly. English strings with -dir rtl are not supported, see bug 271484 comment 2. > - entries in interfaces list are right justified (have to be left aligned since > the expected text there should only contain English characters) (see > javaclass.jpg). > The same is true for "Superclass" field. How is the interfaces table different from e.g. the Outline or the Package Explorer? In RTL mode, all widgets that can contain RTL characters are RTL. Package and interface names can also contain RTL characters. The superclass too. It would be strange if we forced some fields to be LTR. Where would you draw the line? Is e.g. a path name also always LTR? Or a file name? We can't do much there unless we get real BIDI support for text input widgets from SWT (bug 230854). *** This bug has been marked as a duplicate of bug 271484 ***
Event though the 'Interface' and 'package' might contain bidi characters in theory, the java source file assumes with no doubt the left-to-right orientation (arguably proved by the fact that java source editor has left-to-right orientation). Therefore all the controls which are supposed to have any bearing on java source related data should inevitably have left-to-right orientatin.
Tomer, do you agree that we should start forcing some text fields to be LTR? Do you have some guidelines that tell which controls should be treated like this? If you look at the screenshot, I would e.g. find it strange if the "Interfaces" table was LTR, but the Outline stayed RTL. If we decide to do something here, we should do it consistently all over the SDK for 3.6.
Let us first start from explaining the problems I see on the dialog itself. First of all the mirrored dialog is supposed to be translated. Showing not translated screen in the mirrored mode is not a valid scenario. For some reason we can't get the dialog in the translated form (neither for Hebrew nor for Arabic). Please notice that in bug 271484 we also see not translated dialog. When the dialog appears in the translated form the following problem should disappear: (here Do you want to add comments ?(Configure templates and default value Having said that, we should be well aware of the fact that not all translatable text is going to be translated. Specifically, following text is most probably won't be translated: (public static void main(String[] args The expected display is of course as follows: public static void main(String[] args) This specific problem can be resolved using either one of following methods: 1. In Arabic / Hebrew translation of appropriate text resource we need to enforce LTR direction of this text by prepending it with LRE and appending PDF to its' end. 2. Programmatically we can apply TextProcessor using following list of separators: "()[]". Regarding the Superclass field. There are 2 separate issues in this field. a. Complex expression problem. If you use something like java.lang.objectMINE you will see on the mirrored screen something like: ENIMjava.lang.object For resolution of this issue TextProcessor will not help. We will have to wait for resolution of bug 230854. b. Alignment of text is expected to be strong LEFT on both mirrored and not mirrored screens. This is very similar to the way Java code editor works. Since Java language have syntax with LTR direction the editor used for editing Java code is supposed to be not mirrored (aka with LTR orientation). Suprclass field is very similar to Java code editor since it is used for editing class path which has a syntax with strong LTR direction. I believe the problem of alignment can be resolved already now. Finally, the problem with Interfaces list. a. What is for sure is that there might be a problem of complex expressions. This is very similar to the Superclass field. However, in this case we have static text and thus we can use TextProcessor to properly display the paths. Please notice that if you have class path like: java.lang.objectMINE you will see ENIMjava.lang.object instead of: java.lang.objectENIM b. The orientation and alignment are controversial. What is certain is that alignment and orientation should be consistent. For mirrored list the alignment should be right while for not mirrored list the alignment should be left. The question is if the Interface list should be mirrored or not. On the one hand, since list displays tabular data (only one column) and since this data has syntax with strong LTR direction, it is desirable to have the list not mirrored since this enhances readability of the data. However, on the other hand, having not mirrored component on the mirrored screen might negatively affect the layout. In my humble opinion in this specific case resolution of complex expressions problem in the Interface list is much more important. The main question you might ask: Why alignment in static context (i.e. Interface list) and dynamic contexts (i.e. Superclass field, Java code editor etc.) for text with syntax having strong LTR direction may be different ? The answer is quite simple. In static contexts the alignment may be preserved (to be consistent with GUI orientation) since otherwise it might negatively affect how the entire page layout looks like. However, in the dynamic case, since end user might or need to modify the text, it is much more convenient if alignment is consistent with text direction. Namely, for text with syntax having strong LTR direction the alignment should be LEFT, while for text with syntax having strong RTL direction the alignment should RIGHT. It is very inconvenient to edit text with syntax having strong LTR direction when it is aligned to the right (and similarly to edit text with RTL direction when it is aligned to the left). Now regarding the questions you asked earlier: " ...How is the interfaces table different from e.g. the Outline or the Package Explorer ? " It is not. All of them should be mirrored (when the platform is mirrored) - this is how it works now and this is my preference too. Problem of complex expressions should be resolved. It is resolved in the Outline view of JDT, but I believe it has not been resolved in Interface list. "... In RTL mode, all widgets that can contain RTL characters are RTL..." Not all widgets which can contain Bidi characters should be mirrored. For example Java code editor is not. In general for all dynamic (editable) widgets which display text with syntax having strong LTR direction (i.e. File path, URL, Java code, XML content, email address etc.), the widget should not be mirrored (i.e. scroll bar should appear on the right side). This means that orientation of editable widget should be set to LTR and alignment to left. " ...Package and interface names can also contain RTL characters. The superclass too. It would be strange if we forced some fields to be LTR. Where would you draw the line? Is e.g. a path name also always LTR? Or a file name? ..." The purpose is to make text editing experience as convenient as possible while preserving the entire layout of the screen as much as possible. That is why in editable contexts when the purpose of the field is to edit text with syntax having strong LTR direction (i.e. File path, URL, Java code, XML content, email address etc.) the orientation of the field should be LTR (it should be not mirrored) and the text alignment should be LEFT. In some cases (i.e. tabular data) changing alignment / orientation for static cases might also be desirable. But it can occur only if it does not affect negatively the entire page layout (as in case with Interface list).
(In reply to comment #6) > > If we decide to do something here, we should do it consistently all over the > SDK for 3.6. I agree, this is a policy change and an enhancement from what we support in BiDi. (which is currently assume the parent orientation and then support what TextProcessor will do). Of these bugs that have been opened, some of them (like bug 273738) can clearly be fixed (they miss text processor calls). These bugs show up as mangled paths. Bugs about some fields/text boxes not assuming the RTL orientation (like a Path or the Ant editor example) should be marked as enhancement requests and collected as blocking another bug that captures your guidelines about when a field should be strongly LTR so much so as to override the parent orientation. PW
Tomer just to clarify: - the string in the superclass field is only wrong when typed in right? When I have an existing type then the rendering is done right, isn't it? - you suggest to not mirror the superclass filed i.e. have it left aligned. If so, I guess this would apply to all similar kinds of fields like e.g. the entry field in the Open Type dialog, right?
"... the string in the superclass field is only wrong when typed in ..." It does not matter if the text is typed or preselected via Browse button. I guess it is possible to introduce a library (jar file) into the path such that custom (not standard) classes will show up in the Superclass Selection dialog. In this case it will be possible to introduce custom class with Bidi name (i.e. IBM.COM.MYCLASS) into superclass field without direct typing. In this case the display will be mixed up as usual to complex expressions cases. Regardless of method used for introduction of text into superclass field handling similar to TextProcessor (but for dynamic case) should be used to enforce proper display. "... I guess this would apply to all similar kinds of fields like e.g. the entry field in the Open Type dialog ..." Yes, indeed. All entry fields used for editing text with syntax having strong LTR direction should not be mirrored. This is applicable for file paths, URL, email address, Java code, XML content, package name, full java class name etc.
> All entry fields used for editing text with syntax having strong > LTR direction should not be mirrored. This is applicable for file paths, URL, > email address, Java code, XML content, package name, full java class name etc. That would be most of the fields in JDT dialogs then. What about file, folder, and project names? E.g. file extensions probably don't use RTL characters, so if the extension is always at the right (as in attachment 133750 [details]), does that mean the whole name field should be LTR in a Rename Resource or Open Resource dialog? Note that the Interfaces table is also editable (you can add generic type parameters there, e.g. java.util.List<String>). If the table should stay RTL like the Outline, Package Explorer, etc. we should maybe still make the cell editor LTR, since there's really no difference between editing an interface and editing the superclass. On the other hand, wouldn't it even make sense to make the Java outline page and the quick outline (Ctrl+O) LTR? After all, the structure of the Java text is always LTR, so why should the outline not take over that orientation?
We should first of all clearly distinguish between: a. Control Orientation - relates to direction of graphics. For example LTR tree grows to the right, while RTL tree grows to the left. b. Text Direction - direction of text shown as part of control. It can be LTR or RTL. c. Text Alignment - to which boundary the text is shifted. In general not all those 3 parameters can be realized in the context of a single control. For example: * In the context of single line input field Control Orientation is almost not realized besides the shade. * In the context of tree only Control Orientation and Text Direction are realized * In the context of table all 3 parameters are realized. Columns order is affected by Control Orientation. Text direction and alignment in the cells is apparent visually. At this point the important thing to understand is that Text Direction and Text Alignment properties are used exclusively for convenient work with text per-se. They should not in general take over Control Orientation. They can be different from Control Orientation, however, Control Orientation should not be overwritten for the sake of text IN GENERAL. The case discussed in bug 274829 and in this one is special. Please notice that Control Orientation is expected to be overwritten always for only editable controls for which change in Control Orientation has minimal effect (i.e. scroll bar position change in multi-line editor and zero effect in the single line edit field). For not editable controls (aka static cases) care must be taken in order not to negatively affect the entire screen layout. Please notice that for static cases we never suggest to change the Control Orientation. Only alignment and only in those cases in which entire page layout is not visibly affected. Regarding file, folder, project names and name field in a Rename Resource or Open Resource dialog. If the name is plan text (i.e. single folder name, project name etc.) there is no need to change the alignment/direction. If the text is structured one and the associated syntax has LTR direction (i.e. file name) then the direction / alignment should be set to LTR/LEFT. Regarding file name extensions. Yes, indeed using G11N char as part of file extension is rare. However, notice that if file name ABC.txt is shown with RTL direction you will see: txt.CBA while the expected display if CBA.txt . Consequently it is required to enforce text direction for file name to be LTR (and alignment to be LEFT). Regarding Interfaces table. Indeed each single interface can become editable. Platform Input field is used for the editing. I agree that the cell editor created on the fly for editing interface should be LTR as well.
(In reply to comment #7) > The purpose is to make text editing experience as convenient as possible > while preserving the entire layout of the screen as much as possible. That is > why in > editable contexts when the purpose of the field is to edit text with syntax > having strong LTR direction (i.e. File path, URL, Java code, XML content, email > address etc.) the orientation of the field should be LTR (it should be not > mirrored) and the text alignment should be LEFT. This contrasts with how the Windows Explorer's address bar looks like: http://msdn.microsoft.com/en-us/goglobal/bb688119.aspx This looks like RTL and right-aligned. I don't have an RTL install of Windows, but it would be interesting to see how they deal with - paths that contain RTL characters - file names that contain RTL characters - editing file names (e.g. when you rename a file with a bidi name via F2).
First of all Windows is not always a good place to look for Bidi standard. For example, Windows does not support complex expressions. If you check how Windows Explorer on regular OS displays this path c:\ABC\DEF\123\Aa (capital characters represent Bidi letters), you will realize that the display is completely messed up. Please also notice that the alignment (and this is mostly what is discussed in the current context) has very little to do with Bidi characters. In other words, the alignment is supposed to be independent from the presence of Bidi characters in the path. Namely, even if path includes only English characters, it is still more convenient to edit it when it is left aligned. There is another subtle point I would like to attract your attention to. Please notice that when we have a simple input field, setting its orientation to LTR or RTL does not affect its appearance. It does affect how the text inside this field is displayed, but the field's graphics is almost not affected (besides probably a shadow). As opposed to that in case of combobox (another editable control in which file path can appear - for example in the Workbench Launcher dialog), changing control orientation may affect the way it looks (the button invoking drop down list will appear on the left or right side of the control). Consequently in this case, the suggestion is NOT to change the orientation of control, but only text direction and alignment. This is actually what Microsoft do in File Open dialog (except that they don't change the alignment).
Created attachment 134386 [details] File paths on MS Open File dialog Please observe following points: 1. The combobox showing file path is mirrored (aka has RTL orientation). This is exactly my preference as well 2. The direction of text in the combobox is LTR (notice that dot appears on the right side of abc in the "abc." text typed into File Name field). This is exactly my preference as well. 3. The alignment is right in both input field and the drop down list. I would prefer left alignment since it enhances readability and makes editing more convenient. 4. There is no support for complex expressions. The path: c:\ABC\DEF\123_\Aa\NEW FOLDER\a.txt is shown as c:\A\123_\FED\CBA\REDLOF WEN\a.txt instead of c:\CBA\FED\123_\Aa\REDLOF WEN\a.txt
*** This bug has been marked as a duplicate of bug 407070 ***
