Summary: | BIDI_BDL: Visual field supporting proper display and editing of Bidi data in visual Bidi layout | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Tomer Mahlin <tomerm> |
Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | eclipse.felipe, fira, Lina.Kemmel, matial, Mike_Wilson, ob1.eclipse, sadir, semion, Silenio_Quarti, stephen.francisco |
Version: | 4.0 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows Server 2003 | ||
Whiteboard: | |||
Bug Depends on: | 241482 | ||
Bug Blocks: | 245136, 273462, 273722 | ||
Attachments: |
Description
Tomer Mahlin
2009-12-22 06:19:10 EST
(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. |