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

[Rich Kulp <richkulp@xxxxxxxxxx>]

Hi,

Actually you won't be using BeanProxyAdapter,
ContainerGraphicalEditpart, and such. The only thing you will be using
from the jfc plugin is the ComponentManager. All of the other things expect
you to have an Jave EMF model, not your own EMF model. You can use those
as starting ideas, but you don't use them directly.

What you would do is create your own
editparts, and I suggest creating an EMF adapter that implements IVisualComponent.
Then your editpart can use ECoreUtil's getAdapter methods to get that EMF
adapter. That EMF adapter would use a ComponentManager to handle the image
of the component. That adapter would be listening to changes on the EMF
objects to then do what it needs to the visual components to reflect those
changes. 

I would use this for your createFigure():

        public
IFigure getContentPane() {
         
      return getContentPaneFigure().getContentPane();
        }
        protected
IFigure createFigure() {
         
      ContentPaneFigure cfig = new ContentPaneFigure();
         
      ImageFigure ifig = new ImageFigure();
         
      ifig.setOpaque(!transparent);
         
      if (!transparent) {
         
              imageFigureController
= new ImageFigureController();          
             
         
              imageFigureController.setImageFigure(ifig);
         
      }
         
      cfig.setContentPane(ifig);
         
      return cfig;
        }

In here, it would be transparent if
it was a child figure and the parent had the image (like what we do for
AWT/Swing, only the frame would have transparent false because it is the
image, and all of the children have transparent true because the image
comes from the frame.

Your parent container graphical editpart
(a container an editpart that can have children, like we do for frame or
panel) would have:

        protected
void createEditPolicies() {
         
      super.createEditPolicies();
         
      installEditPolicy(VisualComponentsLayoutPolicy.LAYOUT_POLICY,
new VisualComponentsLayoutPolicy(false)); // This is a special policy that
just
         
      // handles the size/position of visual
         
      // components wrt/the figures. It does not
         
      // handle changing size/position.
         
      createLayoutEditPolicy();
        }

The VisualComponentsLayoutPolicy handles
the size/position of the children by listening to the children IVisualComponents
(which are retrieved through the editpart.getAdapter(IVisualComponent.class)
method.

Stay away from using anything else that
comes out of the jfc plugin. It won't work for your model. You can use
them for templates. A lot of their functions actually come from cde plugin,
which you can use.

Thanks,
Rich

"Namrata" <namrata@xxxxxxxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx

06/27/2005 07:30 PM

Please respond to
Discussions people developing code for the Visual Editor project

To	<ve-dev@xxxxxxxxxxx>
cc
Subject	[ve-dev] Re: Using JEM to draw cartoon images of widgets (Rich Kulp)

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
>
>

_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev