Bugzilla – Full Text Bug Listing
| Summary: | [BiDi] Mutli page editors need mixed BIDI support | ||||||
|---|---|---|---|---|---|---|---|
| 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: | douglas.pollock, Ed.Merks, Kenn.Hussey, salexb, semion, steven.wasleski | ||||
| Version: | 3.1 | ||||||
| Target Milestone: | 3.1 M6 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 2000 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Emad Al-Agouz
The same behaviour occurs with the build properties editor. (To open this editor simply open the generated build.properties file) PDE team, please check how we create the source editor page. I suspect that we don't pass some important data to the source editor that would allow it to go into the BIDI mode. Eclipse Forms don't handle source in any interesting way. If you find out that MultiPageEditorPart is causing the problem, route this defect back to the Platform UI. Upon further investigation done by Ed, it seems that this style is inherited by the new API 'getOrientation()' on EditorPart that is set to LEFT_TO_RIGHT by default. Returning to Platform UI for comments. Is the default correct and if not, what should be done? Yes the default is correct. We are overriding on a editor by editor basis. If you think a particular editor should be overridden then the editor owner can change that. I feel strongly that this is wrong. An editor that doesn't want to pick up the workbench default setting should explicitly override to not use it, rather than to force all editors to jump through hoops just to pick up the workbench default. What is the justification for this design? The issue is the case where someone has designed thier editor with BIDI in mind or not. If the editor was designed LTR only and we go and flip orientations on them it may not be useful anymore. A good example is the Java editor which is pretty clearly best left RTL. If someone has gone to the trouble to check this out they can implement the method. What we want to avoid is RTL user being forced into not using RTL because some of thier editors are useless in that orientation. This statement just argues that the JavaEditor should force LEFT_TO_RIGHT regardless of the workbench setting because it can't support RIGHT_TO_LEFT, not that every editor should be assumed not to support RIGHT_TO_LEFT and hence every editor should take action to make normal inheritance from the container work. It's interesting to note that any editor that uses a multipage editor should at least have its tabs right to left if not the contents within the tabs. Any other behavior is simply wrong and having wrong default behavior is not really justifiable. So I still feel very strongly that a hard coded LEFT_TO_RIGHT default for all editors is inappropriate. I did not design any of my (EMF) GUI with RIGHT_TO_LEFT in mind yet everything, including wizards, dialogs, the overviews, work, BUT NOT the editor. Please reconsider. >This statement just argues that the JavaEditor should force LEFT_TO_RIGHT
>regardless of the workbench setting because it can't support RIGHT_TO_LEFT,
>not that every editor should be assumed not to support RIGHT_TO_LEFT and
>hence every editor should take action to make normal inheritance from the
>container work.
Perhaps the Java Editor was not my best example. The case I am concerned about
is that a user who had been happily using an editor in the pre-BIDI days wants
to take advantage of the new BIDI features but they cannot because the editor
does not work in this case.
There is little the user can do about it except to turn the BIDI support off.
As the workbench is a framework we have to make decisions based on backwards
compatibility in an unbounded space - i.e. I have no idea about all of the
editors out there currently so I must assume the case I mention above is
possible.
When we first put the BIDI support in many Hebrew users were upset because we
were too aggressive with changing orientation because thier work environment
was set up for that. If this feature has to be abandoned by someone because of
compatibility issues we will have made the wrong decision.
This problem is described in general in the bug 82951, and there can be found some of our suggestions. "Problematical" editor from this bug can be used as a good example for them. Plug-in manifets editor is multi-page editor, which contains 8 pages. First 6 pages are not editors(it means, they are not WorkbenchParts) and generally speaking they are simply containters(Composites) with more or less complicated contents. Text from these pages can be translated, therefore it will be correct, if they will inherit orientation from workbench window. 2 remaining pages contain real text editors, which should not be rtl (at list by default). It will be correct for these 2 pages, if they will be loaded with ltr orientation. We already have mechanism, which allows us to load "mono-page" editors with editor-specific orientation. We need to use the same mechanism for loading editors on the pages of multi-page editor: In MultiPageEditorPart.addPage(IEditorPart editor, IEditorInput input): ... int orient = SWT.NONE; if (editor instanceof WorkbenchPart) orient = ((WorkbenchPart)editor).getOrientation(); Composite parent2 = new Composite(getContainer(), orient); ... In addition, we need override WorkbenchPart.getOrientation(), and not in the superclass of all editors - EditorPart - but in the superclasses of such editors, wich are designed as LTR only or should be LTR by the default. The best candidates for this, as far as I currently see, are AbstractTextEditor and GraphicalEditor. Expected results are: all text and visual editors are ltr, just as all other inherit orientation from workbench window. The next step can be searching the editors, which should not use these rules and adding to them methods getOrientation() with specific return. Using suggestions below, in the case of plug-in manifets editor and with rtl orientation of workbench we will receive 6 pages (which contain collections of labels, text entries, tabels, trees etc.) with rtl orientation, and "real" text editors in the remaining two pages in ltr orientation. As far as I understand, it is exactly, what we need. Created attachment 17381 [details]
LTR and RTL pages of multi-page editor
I have added comments on the general editor issue to Bug 82951. Ed you likely will be interested in the discussion there. I have renamed this report so that we can use it to focus on the MPE issues here and the general orientation issues in Bug 82951. Any progress on this bug? I have implemented essentially what Semion suggested in build >20050223 Verified on build I20050315-1100 Closing... |