Summary: | [BiDi] cannot change the form's layout separately from the workbench settings | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | elhanan Maayan <elh.mailgate> |
Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | bokowski, daniel_megert, eclipse.felipe, remy.suen, Silenio_Quarti |
Version: | 3.6 | Keywords: | ui, usability |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=295868 | ||
Whiteboard: |
Description
elhanan Maayan
2009-11-28 14:13:45 EST
>the swt widets (at least >the text area one) do not seem to support this functionality This has been fixed in 3.6. M3, see bug 289752. For textual editors this has been currently disabled because it would also mean to reorder the rulers and other information (see bug 291950 and bug 291949). (In reply to comment #1) > >the swt widets (at least > >the text area one) do not seem to support this functionality > This has been fixed in 3.6. M3, see bug 289752. > > For textual editors this has been currently disabled because it would also mean > to reorder the rulers and other information (see bug 291950 and bug 291949). thank you, this indeed solves the immediate problem. however there is still the concern of form layout, and this relates to ALL RCP applications and plug-ins which are to be deployed along side non-locelized ones. today if a developer would like create an rcp screen with RTL orientation but still allow an eclipse user maintain his original layout with other apps , he would either have to manually set it up with formtoolkit or write code for each form to manually detect the locale setting of the OS. that is assuming he even writes a form . take the mylyn plugin for example, the the original problem that led me to this has a special characteristics. the mylyb design usually calls for a dynamic form to recive metedata from the original issue repository which has a schema of fields customzied for issues. natrually the application repository itself allready has a built in client which is oriented right to left, but mylyn is completely unware of it, and thus displays the original orientation of LTR, rightly so, because it is still being used as a development platform, but is wrong for mylyn. what's more while the task connector usually creates a formeditor for the task input, which can easly configured for RTL, the task list remains untouched, so a developer usually has no reference to it, and it reminas in LTR which makes it very difficult to read and understand. all this leads me to believe that the 2 extremes of either eclipse global command line setting or a a local form setting should have compromise in the shape of plug-in setting, cascading as a default to each form, so instead of calling Window.getOrientation, it would call the plug-in's preferences , which may be even configured by code, or by user settings. i think this is true to other i18n plug-ins we well not just mylyn. consider an insurance application for feeling policies living along side a ticker for new your stocks and finance, the first requires local settings for be oriented correctly while the latter does not. 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. If you have further information on the current state of the bug, please add it. 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. |