Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 311661

Summary: [New Widget] BidiLayout - Visual field supporting proper display and editing of Bidi data in visual Bidi layout
Product: z_Archived Reporter: Ira Fishbein <fira>
Component: NebulaAssignee: Thomas Schindl <tom.schindl>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: fira, Lina.Kemmel, sadir, tom.schindl, tomerm
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
See Also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=298392
Whiteboard:
Attachments:
Description Flags
zip file containing BidiLayout plugin
none
zip file containing BidiLayout plugin (without OS dependency)
none
zip file containing BidiLayout plugin(with modified constructor)
none
zip file containing BidiLayout plugin(with modified constructor, subclassing Composite) none

Description Ira Fishbein CLA 2010-05-05 02:51:52 EDT
Build Identifier: 

Visual field supporting proper display and editing of Bidi data in visual Bidi layout 

Reproducible: Always
Comment 1 Ira Fishbein CLA 2010-05-05 03:04:01 EDT
I am copying here some sections from the description of Bug298392, which appears in 'see also' section. The description was written by Tomer Mahlin.

 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. 

 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.
Comment 2 Ira Fishbein CLA 2010-05-05 03:25:11 EDT
Created attachment 167081 [details]
zip file containing BidiLayout plugin

zip file containing BidiLayout plugin
Comment 3 Thomas Schindl CLA 2010-05-05 06:01:39 EDT
Hi Ira - looks like a great addition to Nebula. 

Just one question, you are using OS-Class to get specific informations which makes your control only compile on with SWT-Win32. Do you know if this information is also available on other systems? 

Another question is whether you want to support the widget in future or only contribute it and we need to take care of it. 

I'll take a more close look at the code and come back to you until next week.
Comment 4 Ira Fishbein CLA 2010-05-10 06:31:12 EDT
Created attachment 167682 [details]
zip file containing BidiLayout plugin (without OS dependency)

Hi Tom,
I've removed OS dependency.
Regarding your second question - Yes, I am planning to support this widget in the future.
Ira
Comment 5 Ira Fishbein CLA 2010-05-31 08:06:53 EDT
Hi Tom,
Have you had a chance to look at the code?
Please update me,
Thank you,
Ira
Comment 6 Thomas Schindl CLA 2010-05-31 08:18:50 EDT
I took a short look and there's one thing I don't really like with the current implementation. You are subclassing Canvas but IMHO this not needed at all so IMHO it would better to make your code not inherit from Canvas (you are also doing strange things in the constructor where you under certain cirtumstances add the styled-text-control on the parent and sometimes on the Canvas)

I'd suggest you refactor your code to look like this:

---------8<---------
public class BidiViewer {
  public BidiViewer(Composite parent, int style) {
    styledText = new StyledText(parent, style);

    addBidiSegmentListener();
    addListeners();
    styledText.setMenu(createContextMenu());
  }
}
---------8<---------
Comment 7 Ira Fishbein CLA 2010-06-01 02:51:35 EDT
Hi Tom,
Appreciate your prompt response. 
The general idea is to use this Widget in different Eclipse components. The first candidate for this is DTP. I want to make minimum changes in DTP code and BidiViewer is actually replacing there Text class. Thus I want my class to be 'Control' type. Another reason is that this way I inherit all Canvas methods and this also minimizes  required changes in DTP code (no cast is required when Canvas methods are called). 
'Strange things' in constructor also have the same explanation. This code will be used from different places and this logic is required.
I can copy here code examples from DTP if I haven't explained myself clear enough.
If you can suggest some other way that achieves similar results - please do.
Thank you,
Ira
Comment 8 Ira Fishbein CLA 2010-06-21 01:21:38 EDT
Hi Tom,
Any update? 
Ira
Comment 9 Thomas Schindl CLA 2010-06-22 06:51:23 EDT
(In reply to comment #8)
> Hi Tom,
> Any update? 
> Ira

Ira, I understand your problem with integrating this as a direct replacement but IMHO this wrapping has to happen outside the widget.

As stated before being a subclass of Composite doesn't feel right for me. If you really really need to make it a subclass for Composite you need at least fix your constructor to make the inner styled text a child of the wrapping composite IN ANY CASE!

Still I'd like you to think about others who'd like to use the widget. Is it really such a big overhead for you to make the "Control" something like a BidiViewer which is not inheriting from Composite but getting passed a Composite as the parent and for your purpose you create a Composite-Wrapper in your own code. This make the "Control" API much leaner and cleaner.
Comment 10 Ira Fishbein CLA 2010-06-27 08:38:46 EDT
Created attachment 172854 [details]
zip file containing BidiLayout plugin(with modified constructor)

Hi Tom,
I've changed constructor as you requested. New version is attached.
Regarding your suggestion 'to think about others who'd like to use this widget'. I am trying :). I've used this widget for DTP and it seems to me that the fact of being 'Control' actually leaves the code cleaner. 
For example, in DefaultExternalTableDataWizardPage class :
getEditWidget().setLayoutData(gdtxtTextValue); 
Thank you,
Ira
Comment 11 Ira Fishbein CLA 2010-06-28 04:16:41 EDT
Tom,
Just one more remark. I am not sure I explained it earlier. This widget will be used for as replacement of Text & StyledText controls. That is why it seems important for me to make it Control and to override methods from Text & StyledText classes. This will allow to keep caller's code cleaner, although it 'overloads' my widget's code.
Ira
Comment 12 Thomas Schindl CLA 2010-07-05 14:32:54 EDT
Ira - CQ is filed as CQ 4304 - I'll now start the committer voting.

One small note: Probably subclassing Composite instead of Canvas makes more sense.
Comment 13 Thomas Schindl CLA 2010-07-05 14:33:41 EDT
> One small note: Probably subclassing Composite instead of Canvas makes more
> sense.

We should not make this change before we brought in your code to CVS because the one with Canvas is sent for IP review
Comment 14 Ira Fishbein CLA 2010-07-06 02:50:38 EDT
Created attachment 173499 [details]
zip file containing BidiLayout plugin(with modified constructor, subclassing Composite)

zip file containing BidiLayout plugin(with modified constructor, subclassing Composite)
Comment 15 Thomas Schindl CLA 2010-07-06 16:02:45 EDT
Ira, the IP Team wants us to:

--------8<--------
Hi Thomas:

Please arrange for the contributor to make the following confirmations via the
referenced bug.  When that is in place, please let me know via this CQ.

Confirmations:

1. Authored 100% of the content being contributed
2. Has the rights to donate the content to Eclipse
3. Contributes the content under the EPL 

Thanks,
Sharon
--------8<--------

Can you please answer those questions so that I can go ahead with the IP-Team.

Tom
Comment 16 Ira Fishbein CLA 2010-07-07 07:11:15 EDT
(In reply to comment #15)
Hi Tom,
Yes, I confirm the following 3 statements.
> Confirmations:
> 1. Authored 100% of the content being contributed
> 2. Has the rights to donate the content to Eclipse
> 3. Contributes the content under the EPL 

Thank you,
Ira
Comment 17 Ira Fishbein CLA 2010-07-20 06:42:41 EDT
Hi Tom,
At this point, am I suppose to see my code in CVS? I couldn't find it...
Thank you,
Ira
Comment 18 Thomas Schindl CLA 2010-07-20 06:48:10 EDT
(In reply to comment #17)
> Hi Tom,
> At this point, am I suppose to see my code in CVS? I couldn't find it...
> Thank you,
> Ira

You are the one responsible for checking it in :-) Once you've done it you can close this bug.

The repo is found in:
Host: dev.eclipse.org
CVSROOT: /cvsroot/technology
Module: org.eclipse.swt.nebula/org.eclipse.nebula.widgets.bidilayout

The org.eclipse.nebula.widgets.bidilayout doesn't exists but the CVS-Share dialog helps you creating it.
Comment 19 Ira Fishbein CLA 2010-07-20 06:58:46 EDT
Done,
Thank you!