[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [ve-dev] Understanding this huge pile of code... ;-)
|
Title: Message
Ok,
I've got the VEP source extracted into my workspace and am trying to follow the
directions below. However, VE isn't running correctly yet in my runtime
workspace. Here's what I did:
1)
Extracted VEP source
2) Ran
runtime workspace
3)
Created a project, then a visual class extending JFrame.
Then I
got two dialogs with the following error messages:
---
Could
not find the main class. Program will exit.
IWAV0138E Remote VM terminated too soon. See LoggingUtil.log for
trace of output. For VM "Project (VisualProject)-VM for
MyFrame.java".
---
But I
can't find any file named like "LoggingUtil.log" anywhere under my Eclipse dir
in order to help diagnose this problem:
returns nothing. The following only finds the Apache commons
logging framework:
daveo@daveo ~/c/eclipse_ve
$ find . | grep
ogging
./eclipse/plugins/org.eclipse.tomcat_4.0.6.2/commons-logging.jar
What's
my next step?
Thanks,
Dave
>Suppose I
have a visual layout that extends JPanel and has a BorderLayout
>set.
I then do the following:
>- Select button in the palette.
>-
Drop it in the west region of the BorderLayout.
>Questions:
>-
What actors (Java objects) will participate in selecting the
button,
>providing the borderlayout assistance as my mouse moves over
the panel,
>detecting the drop, hit testing the region of the border
layout in which to
>drop the button, and actually performing the
drop?
There is an EMF model
behind the VE and it's good to work in a mode where you can see the serialized
form of this. To do this from the IDE that launched your Eclipse
workspace (i.e. your development Eclipse) visit the launch configuration,
enable tracing, and for the ve plugin select org.eclipse.ve.java.core and
change debug/xmltext to true. Then in the workspace that is running the
VE visit the preferences page and a new checkbox should be there that lets you
see the serialized model.
The
reason for seeing the model is that you can see the objects that get created.
For the scenario you described let's start with just dropping a JPanel
down and dragging it to have an initial size of 277,163. I've simplified
the model below but it will be something like this with two EMF instances.
These are for the JPanel and the Dimension for its size. The
Dimension is modeled within the method that initializes it (which is the same
one that returns and creates the panel), and the panel points to it.
<members xsi:type="javax.swing:JPanel" size="//@methods.0/@properties.0"/>
<methods name="getJPanel"
initializes="//@members.0" return="//@members.0">
<properties
xsi:type="java.awt:Dimension"
initializationString="new
java.awt.Dimension(227,163)"/>
</methods>
All of the objects (the JPanel and the Dimension)
inside the VE are instances of JavaObjectInstance. This is an EMF
instance whose metaobject is a JavaClass. Every relationship on the
JavaClass comes from a mixture of introspection and merging with override
data, to build up a structure of what the shape of the class is - what
properties it has and what relationships it has to other classes. The
size property is picked up through introspection.
Now you visit the property sheet and change the
panel to BorderLayout
<members
xsi:type="javax.swing:JPanel" size="//@methods.0/@properties.0" layout="//@methods.0/@properties.1"/>
<methods name="getJPanel"
initializes="//@members.0" return="//@members.0">
<properties
xsi:type="java.awt:Dimension"
initializationString="new
java.awt.Dimension(227,163)"/>
<properties xsi:type="java.awt:BorderLayout"/>
</methods>
An instance of BorderLayout gets
created in the model, and the panel points to it. To follow the property
sheet a good object to breakpoint inside is
org.eclipse.ve.internal.java.core.BeanPropertyDescriptorAdapter which creates
the cell editor and label provider.
Now you visit the palette and select a JButton. The JButton
itself is created but not yet added to anything, and as the user moves the
mouse around the GUI or the tree GEF edit policies are responsible for
generating the command that is going to add it to the model. Good
objects to debug are ContainerGraphicalEditPart, that delegates everything to
helpers. Look at ILayoutPolicyFactory and its implementors and find the
one for Border, and trace through how when the layout property was altered on
the ContainerGraphicalEditPart how the factory was involved.
BorderLayoutPolicyHelper is used quite a bit.
When the user releases the mouse the command is
executed and the model updated. The Button is not added to the jPanel
method (in the current code pattern) and has its own method created for it
that returns and initializes it
<members xsi:type="javax.swing:JPanel" size="//@methods.0/@properties.0" layout="//@methods.0/@properties.1">
<components
component="//@members.1" constraint="//@methods.0/@properties.2"/>
</members>
<members xsi:type="javax.swing:JButton"/>
<methods
name="getJPanel" initializes="//@members.0" return="//@members.0">
<properties
xsi:type="java.awt:Dimension"
initializationString="new
java.awt.Dimension(227,163)"/>
<properties xsi:type="java.awt:BorderLayout"/>
<properties
xsi:type="java.lang:String"
initializationString="java.awt.BorderLayout.NORTH"/>
</methods>
<methods name="getJButton"
initializes="//@members.1" return="//@members.1"/>
The JPanel to
JButton is interesting because instead of the JPanel having a child that is an
instance of JButton, it instead has a child object called components that is
an instance of an intermediate object called ConstraintComponent. This
object points to the component (the "//@members.0 is the JButton" and the
constraint is the second property which (cause it's zero indexed) is an
instance of a String that is "java.awt.BorderLayout.NORTH".
>- On
what source lines should I drop break points if I want to see
this
>happen?
The GEF
editpolicies within the edit parts. So try with
ContainerGraphicalEditPart and stop within its edit policies.
>- How
do I set break points in the target VM's code so I can watch it do
its
>thing?
This I think
is described in the help. If not it's on the VEP newsgroup in the thread
"Debugging Java beans in Visual Editor"
>- What parts of this are
subject to change in the 3.0 code base?
For the model I think biggest change I can think of
is how we store the information to instantiate instances. Right now we
tend to store a single initializationString which is evaluated in a way that
works OK in stand alone mode, e.g.
jPanel.setBackground(java.awt.Color.red);
but we have more situations now, especially with SWT
and people writing their own code they want the VE to be able to work with,
where the expressions reference other fields in the model, e.g.
composite.setBackground(display.getSystemColor(SWT.COLOR_RED));
as well as ad-hoc code that just executes
methods on their visual instances that they want to see the result of.
There is a design doc for this that I
believe Rich sent around the newsgroup a while back that may have been hard to
follow initially, but hopefully when we get more stuck in to the development
of this the ensuing discussions will make this clearer.
Best regards,
Joe