[ve-dev] Re: Using JEM to draw cartoon images of widgets (Rich Kulp)

["Namrata" <namrata@xxxxxxxxxxxxxx>]

Hi Rich,

Thanks for responding to my queries very patiently. Now I can create the
live visual swing window using the IDERegistration apis. I also understand
how the ComponentGraphicalEditPart fits into the scheme of things.

I understand the use of other objects (BeanProxyAdapter2, ComponentManager,
ModelChangeController, and IImageController). I could not figure out how
these objects are related to each other, and to the editparts.

I have an EMF hierarchical model for my swing components. Lets say that the
container is a Frame object. In a typical GEF application, I will create the
Frame model, and then associate it to a ContainerGraphicalEditPart. Where do
I create the BeanProxyAdapter, ComponentManager etc. and how
do I associate them?

I think the Live visual should be created as soon as the Model object gets
created, using the proxy. Should I store the created proxy in the model
object itself? Where does BeanProxyAdapter come into picture here.

Similarly if I have a control model object and a ControlGraphicalEditPart,
where will the ComponentManager fit in here. I understand now that the
Figure for a control is a transparent rectangle drawn over its cartoon
image.

One more thing -
Will a step by step instructions using IDERegistry, be useful to others ?
I can create one and pass it on.

Thanks
Namrata

--------------------

> Date: Thu, 23 Jun 2005 12:41:58 -0400
> From: Rich Kulp <richkulp@xxxxxxxxxx>
> Hi,
>
> You shouldn't be looking at anything starting with REM. This is an
> internal implementation of the IProxy interfaces for remote vm. You should
> be accessing the proxies through the IProxy interfaces.  As I recall you
> have a well-defined set of visuals and you don't need a java project and
> extension capability, so you can run using the IDE implementation of the
> IProxys. This will be much faster foy you because the visuals will not
> require a remote vm to be started and you won't be forced to be in a java
> project (remote vm proxies require a java project, the IDE implementation
> does not). Look at IDERegistration.createProxyFactory methods.
> IDERegistration is not internal. But the rest of the IDE... stuff is. We
> haven't gotton around to making it API yet.
>
>
> REMExpression is an implementation of the IExpression interface. What we
> used to do was use straight IMEthodPRoxy invokes. This is like calling a
> method. The problem is that each invoke requires a round-trip to the
> remote vm. When we built up GUI's this round-tripping added up and slowed
> things down. The expression were used to pipe the invokes to the remote
> vm. What happens is that we don't wait for us response, we just keeping
> pushing commands to the remote vm. Then at the very end we do an invoke,
> and this then waits for all of the previous commands to be invoked and
> returns results.
>
> It turns out though that expressions on IDE proxies is actually slower
> than using the IMethodProxy invokes. That is because when using IDE
> proxies, it turns around and calls things directly. This is very fast and
> doesn't have the latency problem that the sockets have that are used with
> the remote vm. So if you are IDE it doesn't require expressions for
> performance.
>
> However, ComponentManager isn't currently written to work without
> expressions. I see now that it might be a good idea to add calls that
> don't require expressions. That would make it faster for you using IDE and
> no expressions.
>
> Now, the way we connect the EMF model to the live beans is through an EMF
> adapter. This adapter (called BeanProxyAdapter (or BeanProxyAdapter2
> depending on what driver you have, we just recently renamed
> BeanProxyAdapter2 back to BeanProxyAdapter) controls the live bean. It
> hears of changes to the EMF and propagates them to the live beans.
>
> You can use something similiar but I don't think it needs to be as complex
> because you have a controlled environment. You don't have to handle a wide
> and undetermined range of beans. Your adapter can simply create the
> visual, connect it to the ComponentManager, listen for changes, and update
> the visual. The visual should be accessed through the IDE proxies because
> that is what the ComponentManager expects.
>
> We also have something called a ModelChangeController. We pipe our command
> stack through this so that only one thread is making changes at time. Plus
> it has a very important added function. You can queue up runnables during
> the execution of the commands that will then be executed at the end of the
> transaction (the command stack execution). This is important because
> things like grabbing images is expensive, so you don't want to do it over
> and over during the execution of the command because of changes happening.
> So the image grabbing is queued up to the end of the transaction and only
> occurs once.
>
> Rich
>
>