Community
Participate
Working Groups
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.3; FDM; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Build Identifier: 20090920-1017 hi.. this relates to https://bugs.eclipse.org/bugs/show_bug.cgi?id=295868 as it stands, there is a seam, between inputing data using the user's locale and using eclipse development platform as a whole. when one is working as a developer, he uses the Left to right orientation, because the entire language, terminology and environment are set like that. however, when dealing with user forms that are also used by users who are not developers, these forms need to adhere to standard layout of the country in question, otherwise inputting and viewing data becomes increasingly difficult. the mechanism for reversing the orientation already exists. it just needs to be accessible to the user. for example, even on the most basic level, a textbox or an areabox in windows respond to Ctrl+Shift in the right side, and Ctrl+shift on the left side of the keyboard reversing the orientation of the text, thus making it easier to write text with mixed languages. the swt widets (at least the text area one) do not seem to support this functionality (this intself is a bug i think) so why not allow the orientation to be adjusted by the end user and only accept the default initially. Reproducible: Always Steps to Reproduce: please refer to the referenced bug to see the images displaying the problem.
>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.
