Community
Participate
Working Groups
Created attachment 216732 [details] Error in NewProject wizard Location path in New Project wizard is corrupted (when Hebrew characters appear in the path) Reproducible: Always Steps to Reproduce: This is Hebrew specific problem 1. Create a directory and subdirectory with Hebrew names 2. Open Eclipse with workspace under subdirectory from the previous step 3. Navigate to File->New->Project->General->Project 4. Uncheck "default location" checkbox 5. Press Browse button and navigate workspace directory (from step 2) result: error saying 'invalid character in resource name' (see attachment) 6. Select Location field content and copy it 7. Try to paste it into explorer result: error appaers (see attachment)
Created attachment 216733 [details] Error in Explorer
Created attachment 216734 [details] Patch for org.eclipse.ui.ide plugin Please find attached patch that fixes reported problem Ira
Changes are at the UI level, so moving to UI to review and commit. The approach is correct in that UI should do the work in the SegmentListener since it knows that the string represents a path (note that we have not reviewed the changes in detail).
Setting target milestone based on previous commitment. If this is a problem then UI will adjust it.
We could add this kind of utility support to JFace, if we're saying it needs to be applied to Text widgets or StyledText widgets. But JFace doesn't currently consume TextProcessor, so it would involve adding a requirement on the new o.e.equinox.bidi that currently doesn't exist. Other alternatives are adding it to o.e.ui.workbench, but that pushes the bar for use up higher (in RCP apps, never in JFace text apps). Or we create a small utility bundle, on par with JFace (o.e.jface.bidi), that can provide all of the functionality we want. But another new bundle means build and feature churn, and it seems pretty small (but I don't know the scope of combining the bidi functionality with SWT/JFace to make it consumable). PW
(From bug 378813 comment #18) > Regarding the API you suggested - where do you think this should be > implemented? I thought to add this to org.eclipse.equinox.bidi plugin (this > plugin handles Bidi-specific issues), but it currently has no dependency on SWT > and I am not sure that is good idea to add such dependency. Is org.eclipse.equinox.bidi really independent from SWT, i.e. could it also be used with Swing or headless? If yes, then I'd say the API should go to org.eclipse.ui.workbench, e.g. into package org.eclipse.ui.swt. The API should be a static method that takes a Text and an expert type (an argument for STextExpertFactory#getExpert(String)). I wouldn't put it into JFace, since JFace is intended to be usable as a standalone JAR, just together with SWT. The first part of the change that deals with locales should be made API in the bidi plug-in, see bug 378813 comment #16: > Another point to consider: The check whether bidi support is needed must be > somewhere in the bidi bundle, and its result must be cached so that the bidi > enhancements have zero overhead on LTR platforms. > See org.eclipse.osgi.util.TextProcessor.IS_PROCESSING_NEEDED.
(In reply to comment #6) > (From bug 378813 comment #18) > Is org.eclipse.equinox.bidi really independent from SWT, i.e. could it also be > used with Swing or headless? > I believe it IS, but would ask Oleg or Mati to please confirm. > If yes, then I'd say the API should go to org.eclipse.ui.workbench, e.g. into > package org.eclipse.ui.swt. The API should be a static method that takes a > > Text and an expert type (an argument for > > STextExpertFactory#getExpert(String)). > > I wouldn't put it into JFace, since JFace is intended to be usable as a > standalone JAR, just together with SWT. > I think a neat approach would be creating a series of implementors for SegmentListener and BidiSegmentListener and putting them at a place accessible to various projects. Consumers would then make calls like: - Text#addSegmentListener(Java_SWT_UI_SegmentListener) - StyledText#addBidiSegmentListener(FilePath_SWT_UI_BidiSegmentListener) - etc. > The first part of the change that deals with locales should be made API in the > bidi plug-in, see bug 378813 comment #16: > > Another point to consider: The check whether bidi support is needed must be > > somewhere in the bidi bundle, and its result must be cached so that the bidi > > enhancements have zero overhead on LTR platforms. > > See org.eclipse.osgi.util.TextProcessor.IS_PROCESSING_NEEDED. There is such an API already, please see STextEnvironment#isProcessingNeeded().
I believe we need at least 2 APIs. 1. Addressing structured text in Text ---------------------------------------- handleSText (Text, String) * first argument is a Text widget * second argument is type of structured text which is used for generation of handler (STextExpertFactory#getExpert(String)). 2. Controlling base text direction in Text -------------------------------------------- enforceBTD(Text, String) * first argument is a Text widget * second argument is a value of base text direction. It can be LTR, RTL or Contextual. The second API will provide a partial solution for problem reported in bug 273198 . Partial, since proposed solution is for Text fields only and not for all widgets. In the same defect (bug 273198) the concept and sample solution for resolution of Contextual base text direction is provided. I also believe the the logic for invocation of support should be part of either API or the implementation of SegmentListener. Ideally they should depend on a separate property (not locale) as was suggested in bug 307307 . I believe it is better to open a separate defect to track the API discussion. By copy to Ira can you pleas open a new one for the APIs discussed here ? Thanks.
I opened bug 383185 to track the API related discussion
See bug 402981 for how to add this now. And let's expand this bug to complete treatment of bidi-affected text fields in the Platform UI and IDE plug-ins. Other cases that come to mind: - Linked Resources preference page - Linked Resources properties page (on a project) - Resource Filters properties page (on a project)
CreateLinkedResourceGroup#createLinkLocationGroup(Composite, boolean) currently hardcodes type FILE. But this is only correct for the default file system. If you e.g. have org.eclipse.ui.examples.filesystem from http://git.eclipse.org/c/www.eclipse.org/eclipse.git/tree/platform-ui/plugins/org.eclipse.ui.examples.filesystem in your workspace, then you get a chooser for other file system types. Those use a URL, not a FILE path. The fix will use BidiUtils#getSegmentListener(String) and add/remove the right listener dynamically. ProjectContentsLocationArea#createUserEntryArea(Composite, boolean) needs the same dynamic STT.
FYI: I've released a private BidiUtils.DEBUG flag. If you set it to true in your workspace, then bidi-processed Text fields get a glaring background color and show the STT as message and/or tooltip.
*** Bug 407419 has been marked as a duplicate of this bug. ***
Created attachment 230734 [details] Enforcing STT using BidiUtils.applyBidiProcessing API Hello Markus, I followes your suggestions Can you please review this patch ? Thank you for your review Best Regards
Moshe, this is the last time I waste time fiddling with a patch that has been created against an old commit. WizardNewProjectCreationPage has already been fixed with your patch for bug 404234. The code in CreateLinkedResourceGroup#createLinkLocationGroup(Composite, boolean) is at the wrong place. The segment listeners only have to be touched when the selection in the fileSystemSelectionArea is changed, not on every modification of the linkTargetField text. I guess the easiest solution is to pass the linkTargetField to createFileSystemSelection(..) and then apply the bidi processing there. If a fileSystemSelectionArea is created, then pass the linkTargetField to fileSystemSelectionArea.createContents(..) and do the segment listener magic in a selection changed listener on the fileSystems ComboViewer. The duplicated code in ProjectContentsLocationArea should get the same fix. And the BidiUtils.getBidiSupport() check should be outside of the selection changed listener.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
