Bugzilla – Full Text Bug Listing
| Summary: | [Help]TVT33:TCT441: IW: Help path in preference is RTL | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | CDE Administration <cdeadmin> | ||||||||||||||
| Component: | User Assistance | Assignee: | Adam Archer <agarcher> | ||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||
| Severity: | major | ||||||||||||||||
| Priority: | P2 | CC: | agarcher, camle, cgold, eclipse.felipe, kitlo, snorthov, Tod_Creasey | ||||||||||||||
| Version: | 3.3 | Flags: | cgold:
review?
(Tod_Creasey) |
||||||||||||||
| Target Milestone: | 3.3.1 | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | Windows XP | ||||||||||||||||
| URL: | 441 | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Bug Depends on: | 87368 | ||||||||||||||||
| Bug Blocks: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
CDE Administration
Created attachment 69847 [details]
TRL_help_path.JPG
<cde:tctdetail> Testcase: 03.001260 Project: WSW33 Component: CDE - Platform/UI Priority: 2 Subject: IW: Help path in preference is RTL Article ID: 441 Originator: gpelleg@il.ibm.com </cde:tctdetail> <response_by> Gaby Pelleg at 2007.06.02.19.40.21 </response_by> Reopen Marking for review in 3.3.1. Changed severity to major because tester has identified this as a must fix for TVT. Moving to UA (sorry folks, just realized that this isn't one of our pages). <response_by> Noha El Ghannam at 2007.06.07.09.55.24 </response_by> Hi, Same problem for Arabic. I agree with the 3.3.1 target - I would not like to try to push this into 3.3 but it should be fixed. This cannot be reproduced on I20070607-0010 using -dir rtl. I have not tried reproducing with languages yet as I don't have the environment setup for it. Created attachment 70523 [details]
screen capture
I recreated the problem by start eclipse with -dir rtl.
Created attachment 70524 [details]
language options
Not sure if it's related. But, make sure in XP's "Regional and Language Options", the "complex script and righ-to-left languages" option is selected.
<response_by> Gaby Pelleg at 2007.06.12.17.47.31 </response_by> So is this deferred? Yes, until 3.3.1. Assigning to Adam. (In reply to comment #11) > Created an attachment (id=70524) [details] > language options > > Not sure if it's related. But, make sure in XP's "Regional and Language > Options", the "complex script and righ-to-left languages" option is selected. Able to reproduce once these options were installed. Investigating. After doing some debugging, I discovered that the text in the box is still "/help" when it leaves our code and goes down to SWT. I tried setting the default text on the "Documentation URL" field on the Ant preference page to "/help" and discovered that it behaves the same way. I discovered that by calling pathText.setOrientation(SWT.LEFT_TO_RIGHT); on the textbox it can be forced into left to right mode, but this also makes the text align to the left. After a bit more testing of the org.eclipse.swt.widgets.Text behaviour, I think this stems from a bug in SWT's rendering of text in right to left fields. It seems that when the text in a box under rtl orientation, slash characters at the start or end of the String do not render correctly. I will attach a small SWT sample to demonstrate the behaviour. Created attachment 71643 [details]
sample demonstrating Text bug
After a bit more testing I discovered that this seems to apply to all (or at least most) non letter characters.
Attached is a small SWT sample. It is a shell with a few text boxes demonstrating the problem.
Moving to SWT. See the sample attached in comment 17 to reproduce the problem. Note that you must have the Windows regional and language options installed as shown in comment 11. I have not tested this outside Windows. This looks like the BIDI algorithm in a text control. Is it? to embedded english text in a RTL component you need to use bidi control characters (LRE). see bug 191415 or bug 190740. I'll close this as duplicate of bug 87368 because in bug 87368 we discuss other alternatives to this same problem. *** This bug has been marked as a duplicate of bug 87368 *** The difference here is that it's a text control. Embedding BIDI control characters doesn't seem right. (In reply to comment #21) > The difference here is that it's a text control. Embedding BIDI control > characters doesn't seem right. I still think it is the right answer. In the native text widget if you open the (native) context menu there is option "Insert Unicode control character", from the list you can pick "LRE - start left-to-right embedding", type you text, insert a PDF at the end. This problem for UA is targeted at 3.3.1 as it is a large usability problem for languages that encounter the issue. Can we have bug 87368 targeted at 3.3.1 as well if this is a duplicate? > Can we have bug 87368 targeted at 3.3.1 as well if this is a duplicate? Note: we still don't have a solution for bug 87368. Personally I believe people should use bidi control characters - which means there is no code involved in fixing bug 87368, we will probably just write a faq or howto for it. Reopening, this is not an exact duplicate. We have decided to workaround the issues reported in Bug 87368. Reopening, this is not an exact duplicate. We have decided to workaround the issues reported in Bug 87368. How are you going to workaround this problem ? Will you add bidi controls characters to your text ? That's right.
if (pathText.getOrientation() == SWT.RIGHT_TO_LEFT)
path = LRE + path + PDF;
pathText.setText(path);
Just testing now.
Created attachment 72087 [details]
Patch
This patch wraps the LRE/PDF characters around the text in the path field every time it is set while the textbox is in RTL mode. It then parses off the characters before updating the preferences.
I tested the bug and the proposed fix on Linux and found that the bug does not occur and the fix does not cause any adverse effects. We discovered that similar problems arise when trying to type in an IP address under the hostname field. When augmenting the patch to include this field, I discovered that the fix does not seem to work anymore. I think it's because the machine I'm working on now is on Sun JRE v6.x, but I will need to investigate further. It seems that when the Text widgets contain strings with the BIDI control characters and the user manually edits the values, their text is entered outside the BIDI characters, causing incorrect functionality. One potential way to workaround this issue would be to add listeners to ensure the BIDI characters are on the outside of the string at all times but this seems extreme. >It seems that when the Text widgets contain strings with the BIDI control
>characters and the user manually edits the values
Yes. The user can actually delete the control characters using backspace or delete.
You can make it a bit easier on yourself by not adding PDF at the end of string but still have the problem of making sure the LRE mark stays in the rigth place.
On GTK, you don't need the patch because GTK has a different algorithm to determine the paragraph level of a string.
I attempted to improve this solution further by adding listeners, but the complexity is too great for such a trivial issue and the functionality is still not even ideal. In order to do this properly we need SWT to provide native support for situations like this. Even if they provided some mechanism to instruct the textbox to always wrap the contents in the LRE/PDF characters, but make them transparent to the user and uneditable, this would be an adequate solution. As is, I think the best we can do is to make the Text elements render in SWT.LEFT_TO_RIGHT mode. This makes the alignment incorrect for RTL languages, but at least makes the preference page usable under this circumstance. I will upload a patch. Created attachment 73053 [details]
temporary fix
Forces the host and path fields into SWT.LEFT_TO_RIGHT orientation.
Does the "temporary fix" replace the previous patch? Yes. I didn't mark the other one as obsolete because the two patches take different approaches. The older one has revealed itself to be too buggy to use at this point. We need further support from SWT. See comment 32 and bug 87368. Tod can you give an opinion on the latest patch? If a field does not need to support RTL then make it a LTR field and do not process. We are not processing text input anywhere in Eclipse in any locale right now as we try to not fight the experience the user is accustomed to. For instance in Chinese we take the input from whatever input method editor (IME) is installed and don't do anything special ourselves. When there is an OS that supports BIDI better we will get this better support for free by not fighting the OS. if it is comment 33 you are referring to Chris this is the right approach. Yes, I was referring to comment #33. Fixed in 3.3 maintenance stream. Fixed in HEAD also (using the patch from comment #33). |