Community
Participate
Working Groups
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" in workspace "C:\workspace". 2. Select "New->Project", then choose any any project except "General". 3. In "New ....Project" wizard type "ABC" (capital letters stands for Bidi characters) into 'Project name' field. This field now contains: "CBA". Result: The "Directory field contains "CBA\C:\workspace". The correct display should be of course: "c:\workspace\CBA". Remark. This problem has been resolved, for instance, for "General" project ('New Project' page of create project wizard 'New->Project->General->Project'). The built in mechanism for correct processing of complex expressions (like filepath) containing Bidi characters exists in Text processor. More information:
TextProcessor is only invoked for "iw", "he", "ar", "fa", and "ur" Also, the snapshots were marked as images, but our browsers complained they were corrupt. If they are something else (like a zip or archive) I think they need to be marked as such (or simply as binary streams) for us to see them. PW
1. This problem stems from right-to-left orientation of read-only "Directory field and has nothing to do with Text Processor. 2. The problem persists when startingg the eclipse with "-nl he" parameter as well. 3. I didn't provide any snapshot for this problem.
Created attachment 133610 [details] New Java Project I opened the new java project after launching with -nl iw I typed in some hebrew chars and I get the dialog. It looks correct to me (the chars in the text box are the same as the chars in the directory). PW
http://www.i18nguy.com/unicode/hebrew.html for info PW
Created attachment 133616 [details] New Project on Windows ... no good font This was on our normal install of windows. The chars ended up in the correct place, but the path is right-justified (not the same as on linux) PW
Shensis, which of the 2 pictures I attached is the correct behaviour? Felipe, I noticed on windows it is right-justified and on linux it is left justified ... is that simply a platform difference? Both pictures were taken with -nl iw (but no NL packs) PW
(In reply to comment #6) > Felipe, I noticed on windows it is right-justified and on linux it is left > justified ... is that simply a platform difference? Yes, see Bug 236513 comment 2. In the future we might decide make this behaviour consistent, maybe as part of the fix for Bug 230854 or Bug 273198.
(In reply to comment #6) > Shensis, which of the 2 pictures I attached is the correct behaviour? > Shensis, which of the 2 pictures I attached is the correct behaviour? PW
(In reply to comment #8) > Shensis, which of the 2 pictures I attached is the correct behaviour? The one in comment 5 is probably better for reading and more consistent across our UI.
Attachment 133610 [details] demonstrates the correct behaviour
(In reply to comment #0) > Result: The "Directory field contains "CBA\C:\workspace". > The correct display should be of course: "c:\workspace\CBA". Using the SDK, I could only reproduce this for the "New > Java Project" case. Moving to JDT UI. As for left vs. right-justified, on Windows, *all* fields containing file paths that I looked at are right-justified. Making them left-justified would be a sweeping change, I don't think we can do something like that this late in the cycle.
The proper display is illustrated on the image provided in comment #3. The general description of the problem with alignment and suggested guidance are available in bug 274829
(In reply to comment #12) > The proper display is illustrated on the image provided in comment #3. The > general description of the problem with alignment and suggested guidance are > available in bug 274829 Thanks for the pointer. I suggest that we use this bug for the broken path in New > Java Project (see comment 0: 'Directory field contains "CBA\C:\workspace"') and use bug 274829 for the potential sweeping change to the alignment of fields containing paths.
*** Bug 378813 has been marked as a duplicate of this bug. ***
Created attachment 228576 [details] Using the new BidiUtils.applyBidiProcessing API Hello Markus, Can you please review this patch ? Thank you very much for your review
Comment on attachment 228576 [details] Using the new BidiUtils.applyBidiProcessing API Please see bug 402981 for how to properly require the o.e.equinox.bidi bundle. Relying on an absolute path on your system is probably not the best solution for everyone. The patch only fixes the location field of the New Java Project wizard. We should just make a pass over all fields in Java element wizards and fix them all at once. E.g. open a type hierarchy on NewElementWizardPage and check the subtypes (e.g. source folder paths). Apart from the File > New... > Other... > Java compartment, also check: - build path actions (on a Java project: context menu > Build Path > ...) - preference pages (e.g. Classpath Variables) - Project > Generate Javadoc.... - other Java-related actions Hint: To quickly find the implementation for a dialog or wizard page, use the PDE Plug-in Spy (Alt+Shift+F1) and then click the active page class.
Created attachment 228849 [details] Using the new BidiUtils.applyBidiProcessing API Hello Markus, I made a pass over the Text fields used in JDT which need Bidi special treatment for File Path pattern. Can you please review this patch ? Thanks
Why do you use StructuredTextTypeHandlerFactory.FILE in the preference pages and in the NewType/PackageWizardPage for fields that hold qualified types or qualified names with wildcards? Wouldn't JAVA be more appropriate for a field that contains a qualified Java type? In the User Libraries preference page, you missed the Import.../Export... dialogs Why is the name in the Java project wizard and in the NewTypeWizardPage not processed the same as for general projects (bug 404234)? Same for other file/folder names in creation dialogs. The cell editor in NewTypeWizardPage#createSuperInterfacesControls(..) needs to override createControl: @Override protected Control createControl(Composite parent) { Control control= super.createControl(parent); BidiUtils.applyBidiProcessing(text, StructuredTextTypeHandlerFactory.JAVA); return control; }
Moshe, are you planning to provide an updated patch soon?
(In reply to comment #18) > Why do you use StructuredTextTypeHandlerFactory.FILE in the preference pages > and in the NewType/PackageWizardPage for fields that hold qualified types or > qualified names with wildcards? Wouldn't JAVA be more appropriate for a > field that contains a qualified Java type? OK. I changed the type to JAVA for type/package names > In the User Libraries preference page, you missed the Import.../Export... > dialogs OK. I added it to the patch > Why is the name in the Java project wizard and in the NewTypeWizardPage not > processed the same as for general projects (bug 404234)? Same for other > file/folder names in creation dialogs. I would prefer to handle the Java name project (and the other related fields) in a separate defect. This defect handles STT (Complex Expression) and not classic Base Text Direction. > The cell editor in NewTypeWizardPage#createSuperInterfacesControls(..) needs > to override createControl: > @Override > protected Control createControl(Composite parent) { > Control control= super.createControl(parent); > BidiUtils.applyBidiProcessing(text, > StructuredTextTypeHandlerFactory.JAVA); > return control; > OK I added it to the patch
Created attachment 230299 [details] Using the new BidiUtils.applyBidiProcessing API Hello Markus, I addressed your comments. Could you please review the patch Thanks
Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=7ea3eb6199fb573e91f0ec3833069a6f191ab9a4 I've added an upper bound "[0.10.0,2.0.0)" on org.eclipse.equinox.bidi and also added processing in the JavadocConfigurationBlock.
Verified using build I20130508-2000.
