[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [ve-dev] SWT code patterns
|
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
|
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