Community
Participate
Working Groups
Background ------------ There are certain text types which have predefined direction of syntax. For example, Java code and file path have syntax with strong LTR direction. Editing / displaying of such text types is expected to be consistent with their natural syntax direction. In other words, editing Java code, file paths and similar text patterns is expected to occur in LTR oriented control, with LTR text direction and LEFT alignment. How things work by default --------------------------- By default top level GUI orientation (aka mirrored or not mirrored mode) is propagated to the lower levels affecting both text direction and text alignment. For example, mirrored table enforces RTL text direction shown in the cells and their RIGHT alignment. What is the problem ? ---------------------- When Eclipse is running in the mirrored mode (aka RTL orientation) by default all controls assumes RTL orientation (+ RTL text direction + RIGHT alignment). However, this is not desirable for controls used for editing / displaying text with syntax having strong LTR direction. General guidance ----------------- 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 always LTR (it should not be mirrored) and the text alignment should be LEFT. 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). Please notice that for simple controls (i.e. single line input field, StyledText based editor), "hardcoding" control orientation to LTR usually resolves the problem. However in more complex cases (i.e. tables) a more fine tuning is required. For example: * in case of tables (see bug 273738) changing text direction / alignment for selected columns (LTR/LEFT) without affecting control's orientation (the table itself remains mirrored). * in case of combo boxes (see bug 273926) text alignment and text direction should be LEFT/LTR without affecting control's orientation (the combo box itself remains mirrored). Text types with syntax having strong LTR direction --------------------------------------------------- Following text types fall into this category: * File path * Email address * URL * Java code * XML content * Java class full name * Java package name * etc. Dynamic cases vs. Static cases ---------------------------------- 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 always set to LTR (+ text direction = LTR + alignment = LEFT). In some cases (i.e. tabular data) changing alignment / orientation for static cases is also desirable since it enhances readability. But it can occur only if it does not negatively affects the entire page layout. For example: * Static cases in which enforcement of text alignment is not desirable: a. Interface list on New Java Class wizard dialog is a good example for static case in which alignment should not be enforced (see bug 273731). b. Name column in the Switch To Editor dialog (see bug 273738). Changing alignment of Name column to LEFT will affect relative position of icons and text which would look not naturally for mirrored table (icons will have to appear on the left side of the text). As opposed to paths, readability of file name is not negatively impacted by alignment to a great extent since file names are shorter and include only 2 tokens (name and extension) while file paths are much longer and include usually many tokens (sub-folders). * Static cases in which enforcement of text alignment is beneficial: a. From directory drop down combo box in the Import dialog (see bug 273926). Change in the alignment does not affect the entire screen layout, while significantly improves readability. b. Workspace drop down combo box in the Workspace Launcher dialog c. Path column in the Switch To Editor dialog (see bug 273738). Paths appear in one column. All rows in Path column display only paths. Alignment of text in one column does not affect other columns and does not affect the layout of entire screen, while greatly enhance the readability. Text direction + alignment vs. Complex expressions --------------------------------------------------- Please notice that changing the orientation of control (+ text direction + alignment) does not always resolve the problem of proper display. This is because displayed text might have internal structure which should be enforced. Thus for static cases TextProcessor should be used for handling the problem of complex expressions, while for dynamic cases either BidiSegmentListener mechanism should be used (for StyledText based editors) or a resolution of bug 230854 should be used (for single line input fields).
The position for Arabic is summarized below: By default, text direction and text alignment follow the UI orientation. In some exceptional cases, text direction will be set based on the readability needs regardless of the window layout (e.g. if the text field contains a file path, it will be always set to LTR even in mirrored interface) while text alignment will follow the window layout for the sake of consistency with the whole layout. One special case is the case of source code and source-code-like editors (e.g. Java editor, SQL editor), they should be forced to LTR text direction as well as being left aligned. In all cases, all fields (both dynamic and static) need to have means for controlling the fields text direction and alignment (e.g. Ctrl + Shift in Windows) and the developer should try to preserve the user-set text direction and alignment.
