RE: [ve-dev] SWT code patterns

[Dr Gili Mendel <gmendel@xxxxxxxxxx>]

Add the SWT container .... project's
properties, BuildPath, Libraries -> AddLibrary

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

Joe Winchester <WINCHEST@xxxxxxxxxx>
Sent by: ve-dev-admin@xxxxxxxxxxx

01/30/2004 11:57 AM

Please respond to
ve-dev

To	ve-dev@xxxxxxxxxxx
cc
Subject	RE: [ve-dev] SWT code patterns

Dave, 

Opening an existing class requires parsing and this work is on-going right
now.  The one that works best right now is the top-down scenario is
the one to try - visit the build path of the project, Add Library, select
"Standard Widget Toolkit" to get the container added.  Open
Empty.java, the SWT stuff is on the platte, drop a Shell from here.  Drop
other stuff into it, resize and move them around and use the property sheet
to change properties. 

Best regards, 

Joe Winchester

Please respond to ve-dev@xxxxxxxxxxx

Sent by:        ve-dev-admin@xxxxxxxxxxx

To:        "'ve-dev@xxxxxxxxxxx'" <ve-dev@xxxxxxxxxxx>
cc:        
Subject:        RE: [ve-dev] SWT code patterns




I got  excited when I saw the screen shots below and wanted to see this work for  myself.  So I:
 
- Got  the latest CVS build from head.
-  Deleted the package Gili mentioned in a previous post.
-  Created the following class (by hand), inside VE:
 

public class SWTTest {
 
org.eclipse.swt.widgets.Shell shell =  null;
 
private void createShell() {
   shell =  new  org.eclipse.swt.widgets.Shell();
   shell.setSize(new org.eclipse.swt.graphics.Point(640, 480));
}
}
 
If I  open VE on this class using the Package Explorer, it chugs for a second or so,  then I get a NPE dialog.  When I hand-coded this inside VE, I got  nothing...
 
What  am I doing wrong?
 
(I'd  *love* to do a short, tightly scripted demo of VE for SWT at EclipseCon next  week during the VE session.  Not to mention that this is just way  cool!)
 
 
Dave

-----Original Message-----
From: Dr Gili Mendel  [mailto:gmendel@xxxxxxxxxx]
Sent: Thursday, January 29, 2004 2:43  PM
To: ve-dev@xxxxxxxxxxx;  wsjve-dev@xxxxxxxxxxxxxxxxxxxxxx
Subject: [ve-dev] SWT code  patterns



We are in the  process of creating a skeleton SWT enabled driver to form the bases from which  to build the SWT extensions.   An important part of it is the code  generation/parsing patterns that we intend to support.  We need to  iterate on this a until we get it right.  The first milestone goal (for  the iteration process) is to have a driver that can generate/parse similar  patterns to the driver that we have today.  The problem is getFoo() for  SWT controls do not make any sense... so we need to move forward a bit.  


.... so we are holding the following  first iteration goal assumptions which do not require any VE modeling  changes:

• One will not be able to drop anything but a  Shell or a parentless widget (e.g. Dialog) on the Free Form.  If one is  to customize a Composite, they will use the create-wizard to  create a  class that extends a Composite with a constructor that takes a parent (need  to talk more about flags).  The target VM will know how to parent the  "this" part on the free form.  
• Dropping a Shell will produce an instance  variable, private  org.eclipse.swt.widgets.Shell shell = null,  and a create method private void  createShell ()  (private vs. public is tbd).  
• Dropping a child on a container  will  create an instance variable for the child, and reuse the parents  initialization method.  ... it will produce the following code/EMF  model
  
  
  
  [IMAGE]
  
  Instance variables are created since both  the shell and the button are contained in the root membership of the model  (vs. a membership owned by a methods element - a local variable).  The  "controls" feature denotes the parent/child relationship.  The  initializes feature of the methods element denotes that createShell is used to  initialize both the shell/button.
  
  This pattern would create a single method per top component.  
  
  
  
  =======================================================  
  
  
  Note that with bottom up parsing, VE  will also recognize the following:
  
  
  [IMAGE]
  
  In  this case we have the same shell and a button as a child. Both are instance  variables, but each is initialized by a different method.
  The key here is that createShell() must call the create  method of the button.  
  In the case that the createButton() _expression_ is removed from  createShell(),  CodeGen will remove the button (and if needed its  init method) from the VE EMF model... which implies that the GUI will only  show the Shell.  
  ... this is a  first pass to the scenario where as a createButton() exists, but no one (that  we can understand) calls it. The WYSIWYG Free Form will reflect that.  
  
  
  This milestone does not take into  consideration factory methods.
  
  
  
  ------------
  Dr. Gili Mendel
  IBM
  Software  Development
  RTP Raleigh, NC
  (919)543 6408, tie: 441  6408