[ve-dev] VE M1 support for RCP

[Dr Gili Mendel <gmendel@xxxxxxxxxx>]

I took the latest Visual Editor integration
driver (http://fullmoon.rtp.raleigh.ibm.com/tools/ve/downloads/drops/I-I20050318-200503181537/index.html)
and tried to open the View.java class from the RCP Mail template application
with the Visual Editor with no success because of the reason below.  Looking
closer on the pattern that was used in creating the mail’s view, it seems
to be a good example of what a user would generate; rather than force VE’s
pattern, I believe that we need to try, as much as possible, to support
free from styles like the one in this example.

1. VE does not support a visual delegate
pattern (like a JFace ViewPart).  This is the case where the class
itself is not a visual component, but uses a visual delegate.  It
is crucial for VE to support the delegate pattern, starting with supporting
the development of a ViewPart in VE M1 (April time frame) https://bugs.eclipse.org/bugs/show_bug.cgi?id=88771
The current workaround for this is to
create a customed widget extending a Composite with the Visual editor,
and instantiate it inside the createPartControl() method (included are
the view with the content developed in a seperate class).

2. VE does not support the pattern where
an instance/local variable is reused.  It is mostly the case where
unique instance/local variables are needed for future references (logic/events
etc.).  But, it is also the case where reuse makes sense; like in
the case of GridData, Label, GridBagConstraints, Layout etc.  VE must
(at least) reverse parse these patterns inducing a unique VE model element
for each.  For example, 
Label l = new Label(parent, …);
l.setText(“Foo”);

l = new Label(parent, …)
l.setText(“Bar”);

VE's reverse parse will create two VE
model instances each with the proper setting. and deal with _expression_'s
offsets to determine instance relevence - impact is to the CodeGen area
of VE only. This support is targeted to M1 as well https://bugs.eclipse.org/bugs/show_bug.cgi?id=88763

3. VE need to support the new Link SWT
control https://bugs.eclipse.org/bugs/show_bug.cgi?id=87120.

Jean, I was using M5a so it may not
be the case with the latest code base. The view uses a Label for the (From:
email).  It will be cool to use the new SWT Link widget instead.

4. Manipulation of FontData.  The
following code is used by the mail View :
         
      Font defaultFont = JFaceResources.getDefaultFont();

                FontData[] data = "">
                for (int i = 0; i < data.length; i++) {
                        data[i].setStyle(SWT.BOLD);
                }
                boldFont = new Font(this.getDisplay(), data);
VE will not be able to model the for-loop.  But from the looks of it, all the code is trying to do is use the bold version of the default JFace font.  The best way to do so is as following:

       Font boldFont = JFaceResources.getFontRegistry().getBold(JFaceResources.DEFAULT_FONT);

This way, we are reusing the JFace font, and do not have to deal with the disposal life cycle for it.  Jean, is it possible for you to change the example to use the above code instead?  VE understands it.

I also included a screen scrape for the VE opening up the content area with the included files view/content java files fixing the 1-4 issues (show Grid is enabled).  I hope that we can get  1, 2, 3 done for M1.



------------
Dr. Gili Mendel
IBM
Software Development
RTP Raleigh, NC
(919)543 6408, tie: 441 6408

Attachment: View.java
Description: Binary data

Attachment: ViewContent.java
Description: Binary data