Community
Participate
Working Groups
Build ID: Version 3.3 Steps To Reproduce: Note: treat Caps Lock latin letters as BiDi letters Hebrew\Arabic. 1. Run eclipse with -dir rtl flag. 2.Create a jave project. 3.Create a Java Class with BiDi name. as - EMANSSALC. 4. declare a function with 2 parameters when the method and the variables names are Bidi names. 5. Move your mouse on the function name. 6.Pay attention to the order of the function name and it's variables. Consider the function CLASS.NAME.FUNC( int VAR1, int VAR2) Actual Res: (2Var int, 1VAR int)FUNC.CLASSNAME return_type Ex_Result: return_type CLASSNAME.FUNC(int VAR1, int VAR2) More information: Note: The same problem happens with "Content Assist" on rtl. Also presented in Outline,Project Explorer view, etc'.
Can you attach a little test file? Thanks.
>The same problem happens with "Content Assist" on rtl. Also presented in >Outline,Project Explorer view, etc'. Project Explorer is a different component. You'd have to file a seprate bug. Tod, should the Java Outline and code assist stay LTR? What about Javadoc: I think we once said that in RTL countries the Javadoc might be written in RTL too (is this available from Sun) and hence we have to use RTL for Javadoc hovers. As this is the browser widget I can only specify it for the whole document and hence the method name is wrong.
BTW: this is not a regression - it behaves as in 3.2.
All java text should be LTR - the language is not tied to English even though it is English readable. I would consider java an LTR language so we should show it that way. So by implication the java content in the outline view should also be LTE. Javadoc is stickier - I suppose it could be LTR as the rest of the language is but as it is documentation I am not sure that the answer is as clear. We would need to make a judgement call on that one. As a point of reference most java developers in RTL locales prefer LTR layout - this is why we won't change your orientation unless you specify it. Because of that I would say that would mean the javadoc should be LTR for usuability reasons.
Ed, I thought you might be interested in where the Java and Javadoc discussion in this bug goes as it may affect you EMF Bidi issues.
There are many problems that are far more basic than this. Even the simple case of class called XyzImpl where Xyz are bidi doesn't show in the outline view the way testers assert it should show. Consider the attachments in https://bugs.eclipse.org/bugs/show_bug.cgi?id=178290, e.g., https://bugs.eclipse.org/bugs/attachment.cgi?id=61713. It's just a mess and I've got the impression that we could chase these problems in circles forever and still not make everyone happy. After all, if XyzImpl is showing up as ImplzyX, from a RTL point of view one could argue and say, hey, the Xyz is showing up first, in the proper RTL character order, followed by the Impl after, also in the proper LTR order. So a person might reasonably argue it's displayed correctly, which is probably why windows displays it this way. But if we now argue that this isn't correct, what exactly are the rules for correct verses incorrect? If I have foo(goo), where foo and goo are bidi characters, and it's displayed a )oog(oof in RTL, is that right? It certainly looks awful... I think we need to take a step back and deeply understand what's right and what's wrong, with some very simple examples...
.
Fixed Java outline in HEAD but won't touch Javadoc. If they really want to develop Java and see the stuff in LTR then they shouldn't explicitly set it to RTL. No further changes planned until there is a guideline compiled from real world scenarios. Fixed in HEAD. Available in builds >= I20070327-0800.
Created attachment 63839 [details] Java class whicj contain a function that describe the bug
Hello. Run eclipse with -nl iw flag to get BIDI support. The bug still exist, plaese find "test.java" file to see the problem. Regards.Tamir.
Works for me in Java Outline.
Created attachment 63882 [details] The function appearance in the outline view Discard this image- got confused, thank you.
(In reply to comment #12) > Created an attachment (id=63882) [details] > The function appearance in the outline view Daniel, Please take a look at the image attached, you can see the bug exist still. there are 2 functions encircled by Red rectangles. thank you.
OK, this is *not* the Java Outline but code assist. This happens if you report several bugs in one bug report. Currently there are no plans to hard-code LTR for code assist as code assist is not Java specifc. Feel free to file a new bug report though.
Created attachment 63884 [details] This image describe the problem in the outline view
My apologies, i got confused. But still take a look on the new attached image. The bug still exist. Thank you
Sorry, I can't see what you see. Are you sure you are using the latest build i.e. I20070410-1043?
This looks like an example of running the IDE itself in RTL mode which I thought we'd agreed is not a mode used by real users of the JDT. (Of course these same types of display problems will occur in the text editor itself when showing RTL text in normal LTR mode.)
The Java Outline has been set to LTR so -dir rtl should (and does not in my latest version) affect this. Sorry, but I am not able to reproduce this in latest build. Pleae provide more detailed steps before reopning again.
Ed, I am simply following instructions given by Cam. Cam told us to test the product in mirrored mode. Thus my team is covering the mirrored mode. Please talk to Cam if you think that product should not be tested in mirrored mode. By the way, since I am not a customer (and I don't represent a customer) I can't agree on whether real users are using JDT in RTL or LTR mode. You should reach an agreement with GCoC on that point. What we for sure agreed is that the problem (as you rightly point out) will occur in both modes (LTR and RTL).
Created attachment 63897 [details] Outline Tree is not mirrored when eclipse is in RTL view
Hello Daniel. I used the latest stable stream build - eclipse-SDK-3.3M6-win32.zip. I downloaded the build you mentioned and verified the Java Outline text has been corrected, but the tree is now in LTR orientation. It should stay in RTL orientation. Regarding the text, the bug still remain in tool tip text and in content assist. Thank you.
>I downloaded the build you mentioned and verified the Java Outline text has >been corrected, but the tree is now in LTR orientation. It should stay in RTL >orientation. Sorry this can't happen. You either get the fixed LTR or the RTL with the known limitations from the OS. We won't patch that. >Regarding the text, the bug still remain in tool tip text and in content >assist. As said before separate bugs and still to discuss wether we'll fix that. For now no action planned on this.
Given that this widget is displaying an outline of a LTR language, it's really not usable when displayed in RTL mode, so folks just finished making changes to ensure it's always displayed in LTR. But now I'm reading an assertion that the widget should remain in RTL mode, i.e., that the changes just made should be undone again. I continue to get the sense that there is no clear direction being given... :-(
You are saying that "it's really not usable when displayed in RTL mode" and solves the problem by changing the direction of Outline widget to LTR. However, this type of solution was never suggested by BiDi team. So, I am not sure to what you refer by " no clear direction being given " . Mati will correct me if I am wrong, but as far as I see it the expected behavior is as follows: * Outline widget including the tree should remain RTL since we are talking about RTL mode Eclipse and Outline widget does not fall into the category of widgets which should stay LTR in RTL Eclipse mode (to this category fall various editors like Java code / SQL , fields holding File Paths / URI etc.). * Depending on the internal structure of textual resources displayed in the tree the direction of each branch label might be different. Since in our case the branch label display a piece of Java code, the order of branch label should be LTR. This is easily achieved by using invisible directionality characters. Having said all this, I would like to emphasis that there is no pressure on your team to resolve the issues. If you think that your strategy is different, it is OK. What is expected, is that if issues are fixed, the fix is compliant with expected behavior. In this particular case I would prefer the integrated fix to be removed, since it results in unexpected behavior.
I think we all agreed that the problem of complex expressions is independant from mirroring mode. Meaning, making widget LTR does not solve the problem. For example following function will appear incorrectly in LTR: RETURN_TYPE FUNCTION(int abc, MY_TYPE VARIABLE) Will appear as follows: NOITCNUF EPYT_NRUTER(int abc, ELBAIRAV EPYT_YM) instead of: EPYT_NRUTER NOITCNUF(int abc, EPYT_YM ELBAIRAV)
This defect has been verified with eclipse-SDK-I20070430-1300 Stream Integratin Build. The defect still exist. the outline tree is in RTL mode, but the function name is being seen also in RTL mode when the prototype text of the function is to be seen in LTR mode. The defect was run with -nl iw flag. For this prototype: FUNCmy_func(int,int) Actual Res: (my_func(int, intCNUF Exp Res :CNUFmy_func(int ,int) This Third image attached describe the problem. Attached a java file for check.
Created attachment 65461 [details] The java file contain a function for the defect's description.
Reopen the bug.
I changed to Outline view to LTR (see comment 19) and then then you wanted it back to RTL (comment 23). Now you say you want it again in LTR. I'm puzzled and can only repeat: you either get hard-coded LTR or RTL with known limitations.
We should make a clear distinction between orientation of GUI and the text or content displayed by this GUI. Those are 2 different things especially in the context of complex GUI widgets such as trees. Orientation of GUI was also called mirrored / non-mirrored mode. To clarify the terminology: LTR GUI orientation = non mirrored mode (in this mode the tree's branches grow from top to bottom and from left to right) RTL GUI orientation = mirrored mode (in this mode the tree's branches grow from top to borrom and from right to left). Notice in our case what was changed is GUI orientation (specifically tree widget orientation). It must remain RTL in the mirrored mode in which Eclipse is ran according to this defect description. The orientation of text (aka content) as part of GUI (in our case text labels which appear as tree's branches) is quite different things and it can be independant from GUI orientation depending on the text purpose. In our case the text displayed as part of tree's branches is Java code and thus it must have LTR orientation. This can be easily achieved if you prepend the text with LRE and append it with PDF characters. This is explained in design published via bug 179191 (section 2.4 Text Analysis). However, this only will not resolve the problem, since the problem is with complex expression and this problem in general can't be resolved by changing the text orientation. This is what Mati wrote on this subject recently: ========================================================== A well known guideline is that a product whose interface is translated to Arabic or Hebrew should run in RTL mode. A product whose interface is in English must run in LTR mode. For a development tool, the language used at development time may be different from the language used in the developed component. However, note that there are cases where the distinction between development time and run time is blurred. Take for example a HTML editor: in source view (where the HTML code is presented), LTR is probably preferred. In WISIWYG view, RTL is mandatory if the displayed page has a RTL direction. In run-time view (e.g., embededded browser window), RTL is also mandatory in that case. Other example: a dialog editor. The tool itself can (should?) be in LTR mode, but its realization window must be in accordance with the target environment, RTL for Arabic and Hebrew users. What we have called "mode" (LTR or RTL) corresponds in fact to the orientation of the outermost container used by the application. Orientation Inheritance ------------------------ By default, the orientation of an outer component should be inherited by all its inner components. However, there may be exceptions. For instance, an application running in RTL mode may display on part of its user area a Java scrapbook page. This page should have a LTR orientation. Other example: an application running in RTL mode presents a list of Arabic or Hebrew terms in the right column of a 2-column table and their English translations in the left column. Although the table itself should have a RTL orientation (first logical column is on the right), the cells with the English terms in the left column should have a LTR orientation. Component Orientation and Text Orientation -------------------------------------------- In many cases, the component orientation and the text orientation (for a component with textual content) are the same, which blurs the distinction between the 2 concepts. A good example to illustrate this distinction is a tree component. If a tree is part of an application running in RTL mode, it is natural for it to flow from right to left, and this would be expected by users. However, if the leaves of the tree are text strings, they don't necessarily have an RTL orientation. For instance, the leaves could be chemical formulas, which must be displayed in LTR orientation. Or the leaves could be names of books, which must be displayed in LTR orientation for English books and in RTL orientation for Hebrew or Arabic books. Or the leaves could be file paths or URLs, which should be displayed according to the rules for complex expressions.
Sorry no plans to do this. See also Tod's comments in bug 179191, comment 11.
Although problems with display will exist for mixed text in either orientation, that's not the same as saying the problem is independent from mirroring mode. The same type of problem will occur in different places and a solution that inserts orientation control characters only as needed will need to know the orientation to do that job effectively. I.e., we need to know the orientation to know whether or not to insert LRE as suggested below. I also find it very surprising to see the assertion that the outline must remain in RTL orientation. What is the basis for that assertion? Given that we are asking for real world scenarios and that those aren't forthcoming, it seems all the statements are subjective anyway. There appears to be no more reason to believe the assertion that the outline must be RTL than there is to believe an assertion to the contrary that it should be LTR. I.e., what's the basis for making this assertion about what the orientation should be? Let me make an argument to back the contrary assertion. Java, being a LTR script will predominantly consist of LTR text and it seems reasonable therefore that all widgets displaying Java-related artifacts should always be LTR.
>Java, being a LTR script will >predominantly consist of LTR text and it seems reasonable therefore that all >widgets displaying Java-related artifacts should always be LTR. That would also be my take on this.
Ed, Just wanted to make sure you understand the design in bug 179191. Adding LRE and PDF does not affect the display in LTR and at the same time does solve the problem for RTL. Thus ALWAYS adding LRE and PDF for expressions having predominantly LTR orientation (e.g. File paths) solves the problem regardless of GUI component orientation. Regarding the real customers I think you were copied on Mati's response. Here it is again: "You ask about "real Hebrew and Arabic end user and product scenarios", and this is a legitimate request. Ideally, we could submit it to a usability lab and get documented answers about how Hebrew and Arabic end users use Eclipse and the products based on Eclipse. Unfortunately, we don't have access to such facility, and I don't dream for a moment that funding can be found for that kind of study, despite its potential benefits. Thus we have no choice but to trust our subjective perceptions and our experience, with the hope that they have some basis in reality." If this approach is not acceptable I would suggest to talk to GCoC.
Did you test the suggested approach in combination with the label decorators that can be plugged in via extension points?
*** Bug 215455 has been marked as a duplicate of this bug. ***
*** Bug 224085 has been marked as a duplicate of this bug. ***
*** Bug 226913 has been marked as a duplicate of this bug. ***
Looking at this for M6.
>Looking at this for M6. M7 that is.
Fixed in HEAD. Available in builds > N20080416-2000.
Thank you so much Daniel for fixing the issue !!! Please notice, that the problem was fixed for English sample. To complete the fix for Bidi sample (on which the defect was actually opened) we need to fix bug 229654. I believe ( according to comment 4 in bug 229654) Martin kindly agreed to handle bug 229654 after M7. Again, thanks a lot for addressing this issue !
Using I20080513 build I see correct display for specific instance reported in this defect. The display is correct for both English and Bidi text. A minor issue is still present for slightly different pattern: FUNC(TYPE1 VAR1, TYPE2 VAR2) Actual display: CNUF(1RAV 1EPYT, 2RAV 2EPYT) Expected display: CNUF(1EPYT 1RAV, 2EPYT 2RAV) Notice that Java code editor shows this pattern correctly. The problem is only in the tooltip. It appears that a blank space (which appears between function argument type and function argument name) should be also part of separators passed to TextProcessor in tooltip context. I will follow up on this issue via separate defect.At this point this defect can be closed. I am not sure Tamir can do it since he is not working with us anymore. Again, thanks a lot to Daniel / Martin for fixing this issue !!!
Setting to verified as per last comment.
