Community
Participate
Working Groups
Build ID: Eclipse SDK 3.3.0, Linux Steps To Reproduce: 1. Enter ABCabc in the "Project name" textbox, such that ABC are characters affected by bidi (e.g. Hebrew characters). 2. Observe the "Location" textbox is updated, but the location shows up as abcABC. It is flipped from the text in the "Project name" textbox. 3. In WizardNewProjectCreationPage, createProjectNameGroup() adds a nameModifyListener, which sets the text in the "Location" textbox to a path processed by TextProcessor. However, the text in the "Project name" textbox does not appear to be processed by TextProcessor. This appears to be the reason behind the inconsistent rendering of the text.
Does this also happen on Windows? Eclipse does not currently support BIDI on Linux
The short version is that yes, the problem still occurs on Windows. The long version is that in Windows, the user has the option of specifying which control is RTL or not. So, if the "Project name" is set to RTL and the "Location" is not, the inconsistency is more forgivable as it appears to be because of the user's settings. However, in Linux, the user cannot specify the RTL setting on a control level.
If this is working on Windows in a BIDI locale then that is all of the support we currently have for BIDI. However we should have the same orientation for both boxes by default. if this is not the case we need to address it.
I have checked on Windows and it is in synch. The two controls are both RTL in an RTL environment and we are processing the text in the Location field.
Hi Tod, are you sure it is in sync? It works with only characters affected by bidi or with only characters not affected by bidi. But the problem occurs when you have a mixture (e.g. ABCabc). In a Windows environment, if you right click on the "Project name" textbox and choose "Right to left reading order" it's out of sync because the text in the Location field is being processed by TextProcessor, but the text in the Project name field doesn't seem to be processed. I'll attach a screenshot to clarify the problem.
Created attachment 74936 [details] Eclipse New General Project Wizard
Created attachment 75527 [details] Illustration of original problem
I would like to add several clarifications on the discussed here issue. First of all let us review the problematic pattern. project name: ABCproject location: /root/workspace/ABCproject Notice I am using capital Latin characters to represent Hebrew letters. The expected display is as follows: project name: CBAproject location: /root/workspace/CBAproject Notice that relative order of Hebrew characters displayed on the screen (e.g. CBA) is different from the order in which they were typed (e.g. ABC). First of all please notice that you should make sure not to mix environment paramters while conducting and comparing test results. It only confuses you. In this specific case Eclipse should be run in non-mirrore mode. This mode gives to all fields by default LTR orientation. You should not alter this orientation using <right click and "Right to left reading order">. If you do so, don't expect to have the same display, since changing the orientation of field changes the display. In other words, if on Windows you change the orientation of [Project name] field the way ABCproject value is displayed on this field and the way it is displayed on [Location] field will be different. This is a correct behaviour. The problem on Linux is that by default in non-mirrored Eclipse the orientation of fields is not always LTR as it is on Windows. Thus, by the way, the problem we see on Linux is not reproducable on Windows. Of course you can cause the string to look similarly on Windows, but for that to happen you need to take additional action (e.g. using <right click and "Right to left reading order">). The display on Linux is as follows: project name: projectCBA location: /root/workspace/CBAproject Why this happens ? This happens since in Eclipse on Linux the orientation of each field depends on the value and is dynamically changed based on the value. It is called "contextual order". This means that if string starts with English characters the order is LTR (e.g. like in case of [Location] field). However, if string starts with Hebrew characters the order is RTL ( e.g. like in case of [Project Name] field). Why orientation of Eclipse fields on Linux is contextual ? Eclipse user interface is comprised of the SWT WebSphere Integration Developer gets. On Linux platforms, the SWT widgets are based on the GTK2 library. Up to version 2.2, the GTK2 library provided support for left-to-right orientation (exactly what there is on Windows). Starting from version 2.4, the GTK2 library supports the contextual orientation. Please notice that Linux with GTK2 up to version 2.2 will behave exactly like Windows. However starting from 2.4 it will behaves inconsistently with Windows. How the problem can be resolved ? The problem can be resolved by enforcing LTR orientation for specific field. THis can be done either programatically or via introduction of invisible characters into buffer. For example by introduction of LRE at the beginning of the buffer and PDF at it's end you can enforce the orientation of displayed text. What role TextProcessor is playing here ? TextProcessor is not supposed to handle contextual order problem. It is supposed to handle a problem of complex expressions (e.g. file path). COnsequently it might be used in the context of [Location] field but there is no sense to use it in the context of [Project Name] field. This is because the syntax of [Location] is predefined - Folder Path, while there is no special syntax associated with [Project Name] path. However, as part of processing of string TextProcessor does insert LRE / PDF as explained above. Consequently if you use TextProcessor for handling [Project name] field it will resolve the problem in this specific case. Notice however, that TextProcessor is doing syntax based parsing (by default file path syntax based parsing) and introduce invisible characters between parsed out tokens. Those characters are not necessary for handling contextual orientation and affect the display. Bottom line is that using TextProcessor for handling contextual order on Linux should not be considered. I hope this clarifies the situation. Please let me know if you have any additional questions.
To stress the main point: Todd says: "we should have the same orientation for both boxes by default. if this is not the case we need to address it." On Linux, since orientation of text field depends on the value typed into this field it might happens that the orientation of [Location] and [Project Name] fields will not be synchronized by default.
This is actually a problem of us using TextProcessing in the location field. We don't text process user input as we don't want to fight the OS but showing the result processed results in this inconistency I think the obvious answer is to not process the location field on typing but only as a result of someone hitting the browse button.
First let me point out that BIDI is not supported on Linux in 3.3 or earlier so the Linux part of the discussion is not relevant until there is Linux support Looking deeper the problem is that the location field is correct and the name field is not due to the name field using the OS input which does not display correctly (you can correct me if I have that wrong). When the user types aaaAAA (in that order) they will expect a directory be created called AAAaaa as the BIDI characters should be placed on the end of the String. We are showing this correctly in the location field. I am reluctant to process input on the user typing because it will cause an inconsistency with the the rest of Eclipse where we do not fight the input mode. My feeling is that this should not be changed as the location field is correct. The only alternative is to make the project name field LTR orientation but that would seem to be a wierd look to me. Tomer are you suggesting that we don't mirror at all in this case?
Tod, Let me comment on the points you raise. 1. "First let me point out that BIDI is not supported on Linux in 3.3 or earlier so the Linux part of the discussion is not relevant until there is Linux support" This is a Linux specific defect which can't be reproduced on Windows ( as I explained earlier the problem stems from the way GTK2 works). If you don't fix any defects related to BiDi on Linux platform we should stop this discussion right away. 2. "the problem is that the location field is correct and the name field is not due to the name field using the OS input which does not display correctly " This is correct. But again please keep in mind that we are talking about Linux platform. So the problem and inconsistency between [Location] and [Project Name] fields is specific to Linux platform. 3. "When the user types aaaAAA (in that order) they will expect a directory be created called AAAaaa as the BIDI characters should be placed on the end of the String. We are showing this correctly in the location field." I am not sure to what you refer by aaaAAA. If aaa stands for Latin chars, while AAA stands for BiDi chars, then you would normally expect to see aaaAAA on your screen for non-mirrored LTR oriented GUI. Please keep in mind that we are talking about non-mirrored GUI in this defect (simply becasue the product from which this defects comes from has not been translated into BiDi language. Since product was not translated into BiDi language, it should not support mirrored mode). In location field (see an image I attached earlier) you indeed see aaaAAA, which is what is expected. For this specific pattern, by the way, you will see aaaAAA in the [Project Name] as well. This is since the problem of contextual order becomes apparent only when string starts from BiDi characters. In this case both [Project Name] and [Location] values start from Latin values. This actually makes me feel that you refer by aaa to Hebrew characters, while AAA stand for Latin ones. Please let us use the same standard suggested by Unicode. Namely, lower case letters refer to Latin characters, while capital letters refer to BiDi characters. We will never end this discussion if we don't use the same convention. Again, in case we have PROJECTname name (starts from Hebrew, ends with English), we would still expect it to be shown in LTR (e.g. TCEJORPname). This is how it is shown in [Project Name] field on Windows platform. However on Linux platform it is shown in RTL (e.g. nameTCEJORP) since on Linux the orientation is contextual and RTL mode for [Project Name] field is selected since value starts with Hebrew char. 4. " I am reluctant to process input on the user typing because it will cause an inconsistency with the the rest of Eclipse where we do not fight the input mode." This was discussed at length during BiDi testing of another IBM product (I don't want to mention its name in order not to disclose sensitive info here). The position of Eclipse team was "not to battle the platform" so to speak. This is completely understandable. 4. "My feeling is that this should not be changed as the location field is correct. The only alternative is to make the project name field LTR orientation but that would seem to be a wierd look to me." Of course, what we want to see on Linux is that [Project name] field has LTR orientation. This is since the product we are talking about was not translated and thus it was not mirrored. In non-mirrored GUI all resources should have LTR orientation regardless of content (e.g. fields including values starting with English chars and fields including values starting with Hebrew chars should both have LTR orientation). However, simply changing the orientation of field would be too swipping. First of all because this GUI can be used in a different product in which the translation is present and thus field might need to be mirrored. Second, setting direction should be applied only in Linux context since on Windows it is not necessary. However, adding platform dependant logic into a code might not be seen as a good practice in general. 5. "Tomer are you suggesting that we don't mirror at all in this case?" I am not sure what exatly you mean ? Do you mean by "don't mirror" - don't change the orientation of field ? If so, then this is what we want to happen in this specific application, on Linux platform with GTK2 library of version 2.4 or higher. However, to implement such condition might be not trivial. Strategically, it seems that the solution should come from GTK2. However, till then the only options we have are: a. Set orientation to LTR for this field, in this application, when it runs on Linux platform with GTK2 library of version 2.4 or higher. b. Battle the platform: use similar to TextProcessor preprocessing and introduce LRE in front of field value. c. Develop an alternative text field widget which deals with contxtual problem and hides the resolution from application programmer. As you can see, every solution has its advantages and disadvantages.
As it is a linux specific defect then we should defer until there is BIDI Linux support. I am going to mark this for 3.4 as Linix BIDI support may be a plan item for the 3.4 release. Thanks for the clarifications Tomer - this will be very useful when we have Linux support for us to verify.
Tod, I am not so sure I can agree with your statement: "Eclipse does not currently support BIDI on Linux" I just downloaded Eclipse 3.3.0 version from official site. Build: I20070625-1500. I am quoting from the readme_eclipse.html found in readme directory: BIDI support SWT fully supports BIDI on Windows. On Linux GTK, SWT supports entering and displaying BIDI text. Within these limitations, the Eclipse SDK tools are BIDI enabled. We are currently talking about display of BiDi text. According to readme display of BiDi text is supported on Linux. It is well known that mirroring and thus support for RTL orientation of GUI is not supported on Linux. However, basic display is supported in 3.3
Let me investigate if this canbe handled in our current support.
from comment 14 > We are currently talking about display of BiDi text. According to readme >display of BiDi text is supported on Linux. It is well known that mirroring and >thus support for RTL orientation of GUI is not supported on Linux. However, >basic display is supported in 3.3 So why do you think this is required for 3.3.1? The project wizard only shows up at the ide layer (it is resource based) and as we don't support most of the BIDI functionality required for the ide on Linux I can't imagine this being important to enough to anyone to be part of a 3.3 maintenance release. We need to be conservative with the changes we make - I'll still look at this one but I am not going to do anything except a trivial change in the 3.3.1 stream.
Moving milestone back to 3.4 as this will be part of the general Linux enablement.
*** Bug 200376 has been marked as a duplicate of this bug. ***
The current behaviour on 3.4 on Linux GTK (build 20080401) is the same as Windows now (i.e. they are inconsistent in the same way)
