Bugzilla – Full Text Bug Listing
| Summary: | BIDI:Eclipse editors should be RTL except those that are generally used for typing English text | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Emad Al-Agouz <agouz> |
| Component: | UI | Assignee: | Tod Creasey <Tod_Creasey> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P2 | CC: | aboualy, camle, Ed.Merks, jeffliu, kai-uwe_maetzel, Kenn.Hussey, semion, steven.wasleski, Tod_Creasey |
| Version: | 3.1 | ||
| Target Milestone: | 3.1 M6 | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 82067, 86326, 86328 | ||
|
Description
Emad Al-Agouz
Tod, I think, we need "hardcoded" orientation only in the level of pure text
editors. In addition we can ask orientation of each editor, which is added to
the MultiPageEditorPart - if it is text editor, it should appear ltr.
We suggest:
1) remove method getOrientation() from EditorPart
2) add this method (witch returns SWT.LEFT_TO_RIGHT) to AbstractTextEditor
3) change method MultiPageEditorPart.addPage(IEditorPart editor, IEditorInput
input), for example, as following:
...
int orient = SWT.NONE;
if (editor instanceof WorkbenchPart)
orient = ((WorkbenchPart)editor).getOrientation();
Composite parent2 = new Composite(getContainer(), orient);
...
This us a UI/Text issue not SWT (they just provide the widgets). The text editors are owned by Text but I want to make the right decision here - right now this can be overridden easily enough if required. What about graphical editors for instance? What would be the right decision there? I think LTR as a general default is a good idea as editors are not designed generally to handle both and should only say they support RTL if they have actually tried it. AbstractTextEditor is subclass of EditorPart, it inherits method getOrientation () and can override it. From this point of view it is SWT Composite. Note,we try to find the "not very bad" solution for GUI, that currently can't be mirrored in runtime - therefore solution can't be good enough. It is correct, that getOrientation() method was added with purpose to override it, when it is needed. Question here - where it can be overriden by the most simple way? Using current solution, what we can do with translated contents of multi-page editors? getOrientation() is not meant to be overridden. This is getOrientation() from WorkbenchPart, and it is already overriden (see EditorPart). *** Bug 82946 has been marked as a duplicate of this bug. *** I think the other thing we need to consider is the option for a user overide. I'll use the TextEditor as an example. I could use it for either reading a Java file (in which case I would want LTR) or reading some notes for a colleague in Egypt in Arabic (RTL). We would need a way for the user to go into the Editors preference page and set the orientation based on how they use an editor. This would solve my concern about flipping an editor and making it unusable (as the user could flip it back). So I think Semions suggestion is less risky if we do this. From my point of view, only dynamic orientation change can make editor really
useable for bidi users. But we have what we have. As far as I understand, if
editor is already loaded, change in the preferences page can't help - is this
correct? Do you mean, that we need preferences page for each editor? What do
you think about properties, which can be set/edit by user before start eclipse
('key' can be id of editor or view)? If such property will be, as usually,
merged with system properties, every plugin will receive ability to change it
even in the runtime... Again, it can't help, if view or editor is already
loaded.
The GEF Flow Diagram editor is not RTL mirrored in the N20050203-0010 build. And this editor affects the translation support in another product. Please provide fast RTL orientation support for this editor. Emad please log a problem report to the GEF component as we do not handle that editor I have implemented this as suggested - i.e. editors will take the default orientaton now unless overridden by getOrientation. Ficed in build >20050223 Tested on Build I20050315-1100.... The Java Editor is the only editor from the list of editors that is LTR oriented. Please Take the appropriate action to apply LTR orientation on the other editors listed in the description... Note that by including XML editor we also address similar editors(HTML, XSD editors,etc...) Emad we need to have these components know individually about the need to slip orientation - if you find one that needs to be retored to LTR please log a new report (the other teams don't track Platform UI reports). *** Bug 84323 has been marked as a duplicate of this bug. *** The XML and HTML editors need to be LTR oriented... Please apply the changes needed on these two editors... Emad we need to have these components know individually about the need to flip orientation - please log a report to whoever supplies the xml and html editors you found (the platform does not have any). I need to leave this one fixed to make sure that it gets picked up in our M6 test pass for the platform. Please do not reopen it. *** Bug 84323 has been marked as a duplicate of this bug. *** Closed... |