Community
Participate
Working Groups
Build Identifier: Preamble --------- Bidi text is stored differently on different platforms. For example: On Windows it is stored in logical Bidi layout While on mainframes it is stored in visual Bidi layout. On different platforms the mechanism used for displaying the data can be different. For example: On Windows, the text in the buffer is first transformed (using Unicode Bidi algorithm) and only then displayed on the screen. On Mainframe the text in the buffer is displayed on the screen as-is Each platform supports proper display of Bidi data in standard for this platform Bidi layout. In other words: Windows: supports proper display of Bidi data stored in logical Bidi layout (aka typing order or chronological order) Mainframe: supports proper display of Bidi data stored in visual Bidi layout Display of data on the platform when this data is stored in Bidi layout different from the Bidi layout supported by this platform results in incorrect display of Bidi data. One of the solution for this problem is providing means for display and editing of data natural to the platform from which it originates. In other words, for proper display and editing of Bidi data in visual Bidi layout (coming from mainframe) on Windows OS (which by default supports only proper display and editing of Bidi data in logical Bidi layout) we need to develop controls which support proper display and editing of visual data on Windows OS. One of the basic such controls supporting editing of visual data is called - visual field. What is missing in general ? ----------------------------- The basic difference between visual field and logical field (the default input field supported by Windows OS), is that in visual field Unicode Bidi algorithm is not applied on the content of buffer before it is rendered on the screen. Application of Unicode Bidi algorithm is in responsibility of OS and it is applied by default in logical fields. There is no Windows API which can be used in order to explicitly turn off application of Unicode Bidi algorithm for a single logical field. However, application of Unicode Bidi algorithm can be indirectly turned off using Unicode control characters. Specifically LRO. Quoting Mati (Bidi architect): "... LRO (Left-to-Right Override, U+202D) can be used to start a piece of text where all characters will be handled as if they were LTR letters ..." In other words for every given text stored in the buffer we can assure that it is displayed and edited using mainframe mechanisms by appending to it LRO as follows: buffer = LRO + buffer + PDF PDF stands for Pop Directional Formatting, U+202C and may be used to limit the effect of a preceding LRE or RLE, LRO or RLO. In our case it is used for clearance only since there is no additional text beyond right boundary of the buffer. What support does SWT already provide ? ---------------------------------------- With enhancement of BidiSegmentListener via bug 241482, we gained the ability to affect which Unicode control characters are added to the buffer "on the glass" . This means that the characters are not added to the buffer itself. Instead they are inserted just before the text is rendered on the screen. In other words we can always insert LRO at the beginning of the text and PDF at its end. Here is a sample code which creates a visual single line field based on StyledText and enhanced BidiSegmentListener: StyledText visualField = new StyledText(shell, SWT.BORDER | SWT.NONE | SWT.SINGLE); visualField.addBidiSegmentListener(new BidiSegmentListener() { public void lineGetSegments(BidiSegmentEvent event) { char LRO = 0x202D; char PDF = 0x202C; int vSeg[] = new int[2]; vSeg[0] = 0; vSeg[1] = event.lineText.length() - 1; char vSegCh = new char[2]; vSegCh[0] = LRO; vSegCh[1] = PDF; event.segments = vSeg; event.segmentChars = vSegCh; } }); What support still need to be developed ? ------------------------------------------ However, turning logical field into visual is not sufficient. At least following features needs to be developed in order to make it compatible with what mainframe supports: * Push mode * Field reverse * Numeric shaping All those options should be controlled via API and through context menu which pops up if you right click the visual field with your mouse. Who will benefit from this support ? ------------------------------------- First and foremost the component(s) which work with mainframe and thus retrieve / display / edit visual Bidi data. One of such components is DTP. For more info please see following defects: * bug 245136 * bug 273722 * bug 273462 Reproducible: Always
(In reply to comment #0) > At least following features needs to be developed in order to make it > compatible with what mainframe supports: > * Push mode > * Field reverse > * Numeric shaping > Hi Tomer, As far I understand, the purpose of this bug is to back 3270 terminal emulation, not just a visual field. Can you please elaborate what in your opinion should be done on the SWT level to provide required capabilities?
Created attachment 155320 [details] Sample screen from DTP By all means. The SWT component which we need to create in order to resolve this bug, should be powerful enough in order to cover entire repertory of functionality associated with visual data manipulation including 3270 terminal emulation. The initial list of features (including push mode) was just that: initial list. Regarding what we expect from SWT. Let us review the simplest scenario involving usage of DTP for modification of data in database. DTP allows to show and interactively change the data in database table. This is achieved via displaying the data in a table and double clicking specific cell subject to data modification. Once you double click on the cell a cell editor is automatically loaded. Currently default Logical cell editor is ALWAYS loaded. Our goal it to make DTP flexible enough to specify which database / table / table column need logical and which need visual editing. This flexibility is subject for a different defect and discussion. However, once it is available, end user will be able to specify the editing mode for database entities (i.e. database, table, table column etc.). Based on this specification, DTP will be able to load either Logical or Visual editor. For example (see the attached image), let us assume that user specified that CUSTOMERNAME field in CUSTOMER table includes visual data and thus requires visual editor for editing. Once end user double click in any row of CUSTOMERNAME column, visual input field will be loaded as cell editor (instead of default logical input field). To make all this happen we need a basic building block - visual input field control / widget. Thus the expectation is to have SWT control / widget which: 1. Can be configured via API to be single / multi line 2. Can be interactively or via API configured to support various features of Visual input field (i.e. push mode) 3. Can be embedded and used as cell editor in DTP (and other plugins) 4. Can be used as standalone widget in Eclipse based application working with visual data.
Well, I think StyledText provides necessary building blocks already (single/multi line mode, Bidi Segments support). It looks like what we need is a new *CellEditor*, e.g. "BidiTextCellEditor" that extends TextCellEditor. However, TextCellEditor currently consumes a Text widget, not StyledText. So BidiTextCellEditor should either use StyledText instead or depend on Bug 230854 - which should provide segments functionaly for the SWT Text control.
I agree with Lina, you can implement visual bidi layout by using StyledText as a cell editor. Don't you agree ?
I certainly agree that: 1. We (DTP code) can implement visual Bidi layout by using StyledText 2. Embedding of visual input field in cell editor is in DTP code responsibility However, please notice that visual input field is much more than just visual Bidi layout supported now by StyledText. As I originally explained Visual Input Field should have inherent capability to support * Push mode * Field reverse * Numeric shaping support and in general cover full repertory of functionality associated with 3270 terminal emulation. In my humble opinion this portion of support should NOT be developed separately by different plugins leveraging StyledText. Instead we should develop a NEW component (you and Lina will know much better than I do if it should be part of SWT, JFace or any other package) which is: a. going to be based on StyledTex and will leverage visual Bidi layout provided now by StyledText b. going to cover full repertory of functionality associated with 3270 terminal emulation (including Push mode, Field reverse, Numeric shaping support etc.). Probably the original title of the defect was misleading. In my view when we talk about visual input field we talk about full repertory of functionality associated with 3270 terminal emulation. This functionality is not present in StyledText now. We can rename the defect to something like: "Visual input field covering full repertory of functionality associated with 3270 terminal emulation." Just to reinforce my point, let us review a very simple example of standard input field (platform based). It is coming with build in context menu, through which you can Copy/Cut/Paste text, introduce Unicode Control Characters, and achieve additional effects. StyledText by itself does not come with any context menu. As opposed to StyledText, visual input field will come with such context menu through which end user will be able to leverage full repertory of functionality associated with 3270 terminal emulation. This way, whenever we use such visual input field (be it DTP or any other component), we ALWAYS be able to access full repertory of functionality associated with 3270 terminal emulation. I believe that implementation of full repertory of functionality associated with 3270 terminal emulation separately in each specific plug-in (i.e. DTP) which needs visual input field is not efficient approach. It is better to have one version of implementation in one control and allow other components to leverage it.
Created attachment 158035 [details] new implementation of Field 3270 functionality based on StyledText
Created attachment 158036 [details] patch file for org.eclipse.datatools.connectivity
Created attachment 158038 [details] patch file for org.eclipse.datatools.sqltools
Created attachment 158040 [details] patch file for org.eclipse.jface
Created attachment 158041 [details] patch file for org.eclipse.jface.text
Created attachment 158042 [details] patch file for org.eclipse.datatools.sqltools.data.ui
My understanding is that patch posted in comment #6 implements the control addressing the problem reported in this bug. Patches posted in comment #7 ... comment #11, illustrate how using this new control a DTP related scenario described in comment #2 can be supported. Bottom line, as part of this bug, we should consider integration of patch from comment #6 only. Please correct me if I miss anything.
(In reply to comment #12) > Bottom line, as part of this bug, we should consider integration of patch > from comment #6 only. Please correct me if I miss anything. Do you want us to include Field3270 as a SWT custom widget ? Personally, I think Field3270 is too specific to be included in the SWT code base.
(In reply to comment #13) > (In reply to comment #12) > > Bottom line, as part of this bug, we should consider integration of patch > > from comment #6 only. Please correct me if I miss anything. > > Do you want us to include Field3270 as a SWT custom widget ? > > Personally, I think Field3270 is too specific to be included in the SWT code > base. ... but it might be a candidate for inclusion in Nebula (http://www.eclipse.org/nebula/)
(In reply to comment #14) > ... but it might be a candidate for inclusion in Nebula > (http://www.eclipse.org/nebula/) I wasn't aware of the existence of such a project. It sounds very reasonable.
(In reply to comment #15) > (In reply to comment #14) > > ... but it might be a candidate for inclusion in Nebula > > (http://www.eclipse.org/nebula/) > I wasn't aware of the existence of such a project. It sounds very reasonable. Mike/Felipe Can you please advise what should be our next steps in order to include this code in Nebula?
(In reply to comment #16) > Can you please advise what should be our next steps in order to include this > code in Nebula? http://www.eclipse.org/nebula/contrib_process.php
Hello, In order to implement this functionality somewhere outside the SWT (e.g. Nebula project), I need to add the following 3 methods to StyledText class: public Caret getDefaultCaret() { return defaultCaret; } public void setDefaultCaret(Caret defaultCaret) { this.defaultCaret = defaultCaret; } public void setCaretDirection(int caretDirection) { this.caretDirection = caretDirection; } Would it be possible to add those methods to existing API? Thank you, Ira
(In reply to comment #18) > Would it be possible to add those methods to existing API? Why do you need them ? What are you trying to do ? I thought you had Field3270 working already. defaultCaret and caretDirection are private members of StyledText, not visible for the application. Exposing them would add new concepts to StyledText users (and SWT as a whole). Not good.
(In reply to comment #19) > I thought you had Field3270 working already. You thought right. Field3270 worked while it was located inside the SWT. Now, when I took it out, there are some changes that need to be made. I've managed to change my code, in order to avoid changing StyledText. Thank you.
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.
