Community
Participate
Working Groups
Created attachment 133429 [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. In some folder (say "temporary") create new empty files "123.doc" and "ABC.xml" where capital letters stands for Bidi (Hebrew/Arabic) charactes. 3. Open "Import->General->File System". Press "Browse" (From Directory) button and choose "temporary" folder. Result: File names shown in the leftmost panel are shown distorted due to panel right-to-left text orientation (inherited from top level frame). (see import-file.jpg) 4. Create General project "abc" and folder with Hebrew name inside it "ABC" where capital letters stands for Bidi (Hebrew/Arabic) charactes. 5. Press "Browse" (Into Folder) button and choose "ABC" folder. Press "OK". Result: The "Into Folder" field contains the following path "ABC\abc". Correct path should be shown as "abc\ABC". The resason of incorrect display is the same right-to-left text orientation . (see import-file.jpg) The rule of thumb should be that controls which are supposed to hold non Bidi data should have left-to-right orientation and be left justified. More information: Note that 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.
(In reply to comment #0) > More information: > Note that the problem has nothing to do with Text Processor but rather with > incorrect To us this means that we shouldn't be looking at TextProcessor at all. I don't believe this is correct, if TextProcessor is not being used and a path is involved this needs to be corrected (as that is the support that the platform offers for BiDi paths). It has nothing to do with text orientation, which is determined from the parent (and for the moment is supposed to be the same as its parent). PW
I'd like to stress out that 2 possible problems shouldn't be messed up. 1. The first one is the problem of 'complex expressions' like full path consisting of chain of subdirectories containing Bidi characters like: 'c:\ABC\DEF\QWR.txt (upper case stands for Bidi) Such path will be displayed completly messed. The Text Processor is able to take care of similar problems. 2. The problem of data intrinsically supposed to be displayed in left-to-right text direction. It may even not contain Bidi characters but when shown in controls having right-to-left orientation it prone to be displayed incorrectly (for instance neutral characters at the beggining or at the end of a string will be shown in wrong place etc.) In many cases the lenient approach is appropriate, i.e. not to take care of 'complex expressions' (when bidi characters are not expected or in case of editable controls when developer still have no out-of-box solution to dynamically apply Text Processor - the task involving the event handlers processing the text change) but setting controls to have 'left-to-right' orientation is a must at the very least. The point I'd like to make - in many cases the controls shouldn't inherit the right-to-left orientation from mirrored GUI.
I personally see 3 problematic contexts on this dialog: 1. From directory field - we have following 2 problems: a. Problem of complex expressions. This problem won't be resolved until we get resolution of bug 230854. b. Alignment problem - since the text has syntax with strong LTR direction (File path) the alignment is supposed to be strong LEFT. This is applicable for dynamic portion of drop down combo box. Please notice, that 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). For static portion (drop down list) I also believe that alignment should be set to LEFT. This is since in this case (as opposed to Interface list case in New Java Class wizard dialog discussed in bug 273731) change in the alignment does not affect the entire screen layout, while significantly improves readability. 2. List of files (123.doc, ABC.doc) - This problem should be resolved by applying TextProcessor. We have static text and thus usage of TextProcessor is adequate. 3. Info folder field - This is a similar to From directory field context. We have following 3 problems: a. Problem of complex expressions. This problem won't be resolved until we get resolution of bug 230854. b. Alignment problem - since the text has syntax with strong LTR direction (File path) the alignment is supposed to be strong LEFT. Since in all 3 contexts we can currently address problematic aspects of text display, I believe that 3 separate defects should be opened to track each context.
*** This bug has been marked as a duplicate of bug 178081 ***
