Cool - hopefully it's not your last
>I'm trying to extend VE to support my company's
>proprietary graphic toolkit. The problem is, it's
>actually a server-side library so its widgets don't
>actually extend any of the AWT/Swing/SWT classes and
>it's not even possible to instantiate them outside the
>GUI server.
So if your classes don't extend AWT or SWT are they
Java classes ? At the moment the VE works by having a Java design
time representation of the parsed code. Most of the time the design
time representation is the runtime set of widgets, so if the code is for Swing
the design time VE uses Swing, SWT uses SWT, etc... For the cases
where the runtime isn't Java there is one team extending the VE that have created
their own set of SWT peers that match those of their runtime, and the reason
they can do this is because their particular language runtime uses native widgets so
SWT was a good match.
If your runtime isn't Java what is it ?
>So my question is,
>(1) Is it possible to extend VE without using the
>actual target widget instances? (i.e. replacing them
>with vanilla java beans with similar properties)
Yes - I think what you're angling at is the preferred
technique to do what you want, which is to fake out the target VM so that the design time
classes are a set of classes that have the same visual characteristics as the runtime, but can piggy
back the VE framework that allows rendering into GEF and layout manager stuff.
>(2) Is there any reference or related documents on JEM
>and org.eclipse.ve.internal.* stuffs? Could anyone
>explain to me what does /vm/jbcfswtvm.jar and
>/vm/jfcvm.jar do or how they're called from VE?
For the JEM documentation we don't have a lot. The
best place to look is probably to do the visual editor tutorial that touches on the model. There is a tutorial
being put together at the moment that covers the model in more depth and we'll post to this newsgroup once it is ready
for review. The two jars you mentioned are because the VE starts
a target VM for each classe edited, and there is supporting code that is put into the target VM to support particular
runtimes. The two you have listed are for swt and the jfc widget libraries. If you create a development environment
and attach to /home/tools and dev.eclipse.org and connect with user id of anonymous you can check out the ve-dev module
from cvs. This contains the plugins that make up the VE and in this you will fine org.eclipse.ve.jfc and org.eclipse.ve.swt.
Each of these contains the code for each toolkit and there are some
source folders with the words vm in them, such as vm_jfcvm and these are
what get packaged into the jar files you mention. When the VE starts it looks at the Java buildpath
of the project and if it determines that either SWT or JFC are there it then adds the supporting VE code - the classes to
look at are org.eclipse.ve.internal.swt.SWTContainer
and org.eclipse.ve.internal.jfc.core.JFCVisualContributor.
Both of these sit on the IDE side and
manipulat the arguments to the javaw.exe that is started to create the
final target VM
>Any kind of answers, references, or comments that
>might be able to enlighten me to get out of this
>problem will be greatly appreciated. Thanks in
>advance!
If you could provide more information on your widget
toolkit that'd help us. You said it is proprietary, but are the any
docs or references that'd help to show how a "Hello
World" examples works and how it can be constructed and also how much,
if any, Java is in it ?