Home » Eclipse Projects » GEF » coordinate system/documentation
| coordinate system/documentation [message #148972] |
Mon, 30 August 2004 10:56  |
Eclipse User |
|
|
|
Hello,
I'm new to the gef/draw2d drawing API and have some problems finding my way.
Furthermore I haven't used java mechanisms to paint anything, yet. So I
might miss some
seemingly obvious points.
I managed to build a GEF Editor with the corresponding model and my figures
are getting
painted. Well - kind of.
According to sizes and coordinates I'm still stepping in the dark. I
couldn't find any explanation
in the documentation about coordinate systems. Neither did a Google search
help.
I'd like to know which units draw2d uses for its coordinate and size values.
And the prefered way to map from real-world coordinates to the logical
coordinate system used by draw2d.
Can anyone point me to some documentation regarding this area? Or can anyone
give me some tips what to do?
Thanks in advance!
Bernd
|
|
| |
| Re: coordinate system/documentation [message #149251 is a reply to message #149026] |
Tue, 31 August 2004 13:49  |
| Eclipse User |
|
|
|
My pleasure :-)
My model represents a simple CAD part of rectangular shape, with a bunch of
child parts (actually: holes in the part).
The model coordinates are in Millimetres.
Initially, I want my whole models figure to be visible (without scrollbars).
Later, the user should be able to Zoom and Scroll, as he wishes.
Rulers in millimetres at the top and left side of the editor pane would be
nice.
I know the phyical boundaries of my model (a rectangle: physicalBounds).
So, I guess I need to scale from my physical coordinates to the logical
(pixel) coordinates.
Again guessing, I would have to get the current boundaries of my canvas.
Probably by calling
Rectangle clientRect= getClientArea()
on the figure in the topmost edit part (Or is there a better way?) .
Now I can compute my scaling factors:
double scaleY= clientRect.height / physicalBounds.height
double scaleX= clientRect.width / physicalBounds.width
Now, what to do with these factors?
Probably each time I update my parts from the model (updateVisuals() or some
such),
I would have to apply the scaling factors to get from model physcal
coordinates to model logical coordinates.
somefigure.x= cadThing.x * scaleX
somefigure.y= cadThing.y * scaleY
That is a bit uncomfortable. It would be much nicer to tell the canvas, that
each coordinate that I use is in fact
a physical coordinate, which needes to be scaled or otherwise translated to
screen coordinates (pixels)
before the actual painting takes place.
The win32 API (GDI Drawing Decice Context, represented by the MFC class CDC)
offers methods to set up
a physical to logical mapping using setMapMode(), setWindowExt() and
setViewportExt() methods.
Is there something similar in draw2d? Or java2d (which I guess could be
brought into play using the holongate.org plugin)?
Can you make anything of this? Or am I barking up the wrong tree?
Thanks,
Bernd
"Randy Hudson" <none@us.ibm.com> wrote in message
news:cgvmca$pfe$1@eclipse.org...
> Everything is pixel-based. There is zoom functionality, but it just
> performs scaling and then rounds to the nearest pixel.
> Can you be more specific?
>
> "Bernd Hofner" <bernd.hofner@gmx.net> wrote in message
> news:cgvf00$b9o$1@eclipse.org...
> > Hello,
> >
> > I'm new to the gef/draw2d drawing API and have some problems finding my
> way.
> > Furthermore I haven't used java mechanisms to paint anything, yet. So I
> > might miss some
> > seemingly obvious points.
> >
> > I managed to build a GEF Editor with the corresponding model and my
> figures
> > are getting
> > painted. Well - kind of.
> >
> > According to sizes and coordinates I'm still stepping in the dark. I
> > couldn't find any explanation
> > in the documentation about coordinate systems. Neither did a Google
search
> > help.
> >
> > I'd like to know which units draw2d uses for its coordinate and size
> values.
> > And the prefered way to map from real-world coordinates to the logical
> > coordinate system used by draw2d.
> >
> > Can anyone point me to some documentation regarding this area? Or can
> anyone
> > give me some tips what to do?
> >
> > Thanks in advance!
> >
> > Bernd
> >
> >
>
>
|
|
|
| Re: coordinate system/documentation [message #149255 is a reply to message #149251] |
Tue, 31 August 2004 14:07 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
I can't imagine why you would want different X and Y scale value. I would
just take the minimum of the two at startup.
All you need is a mapping from your model coordinates to a rectangular
(integer) constraint used in XYLayout. Depending on that mapping (1mm==1),
or (0.1mm == 1), you will have more detail as the user zooms into the
drawing. We are working with SWT which only supports integers. You can
fake what you want by having a zoom level of "100%" really be a zoom level
10%, so that at 1000% you still have pixel-level accuracy.
You should be able to use the Scalable[Freeform]RootEditpart to implement
zoom and XY or FreeformLayout.
"Bernd Hofner" <bernd.hofner@gmx.net> wrote in message
news:ch2dgm$97h$1@eclipse.org...
> My pleasure :-)
>
> My model represents a simple CAD part of rectangular shape, with a bunch
of
> child parts (actually: holes in the part).
> The model coordinates are in Millimetres.
> Initially, I want my whole models figure to be visible (without
scrollbars).
> Later, the user should be able to Zoom and Scroll, as he wishes.
> Rulers in millimetres at the top and left side of the editor pane would be
> nice.
>
> I know the phyical boundaries of my model (a rectangle: physicalBounds).
>
> So, I guess I need to scale from my physical coordinates to the logical
> (pixel) coordinates.
> Again guessing, I would have to get the current boundaries of my canvas.
> Probably by calling
> Rectangle clientRect= getClientArea()
> on the figure in the topmost edit part (Or is there a better way?) .
>
> Now I can compute my scaling factors:
>
> double scaleY= clientRect.height / physicalBounds.height
> double scaleX= clientRect.width / physicalBounds.width
>
> Now, what to do with these factors?
>
> Probably each time I update my parts from the model (updateVisuals() or
some
> such),
> I would have to apply the scaling factors to get from model physcal
> coordinates to model logical coordinates.
>
> somefigure.x= cadThing.x * scaleX
> somefigure.y= cadThing.y * scaleY
>
> That is a bit uncomfortable. It would be much nicer to tell the canvas,
that
> each coordinate that I use is in fact
> a physical coordinate, which needes to be scaled or otherwise translated
to
> screen coordinates (pixels)
> before the actual painting takes place.
> The win32 API (GDI Drawing Decice Context, represented by the MFC class
CDC)
> offers methods to set up
> a physical to logical mapping using setMapMode(), setWindowExt() and
> setViewportExt() methods.
> Is there something similar in draw2d? Or java2d (which I guess could be
> brought into play using the holongate.org plugin)?
>
> Can you make anything of this? Or am I barking up the wrong tree?
>
> Thanks,
>
> Bernd
>
>
>
>
>
>
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:cgvmca$pfe$1@eclipse.org...
> > Everything is pixel-based. There is zoom functionality, but it just
> > performs scaling and then rounds to the nearest pixel.
> > Can you be more specific?
> >
> > "Bernd Hofner" <bernd.hofner@gmx.net> wrote in message
> > news:cgvf00$b9o$1@eclipse.org...
> > > Hello,
> > >
> > > I'm new to the gef/draw2d drawing API and have some problems finding
my
> > way.
> > > Furthermore I haven't used java mechanisms to paint anything, yet. So
I
> > > might miss some
> > > seemingly obvious points.
> > >
> > > I managed to build a GEF Editor with the corresponding model and my
> > figures
> > > are getting
> > > painted. Well - kind of.
> > >
> > > According to sizes and coordinates I'm still stepping in the dark. I
> > > couldn't find any explanation
> > > in the documentation about coordinate systems. Neither did a Google
> search
> > > help.
> > >
> > > I'd like to know which units draw2d uses for its coordinate and size
> > values.
> > > And the prefered way to map from real-world coordinates to the logical
> > > coordinate system used by draw2d.
> > >
> > > Can anyone point me to some documentation regarding this area? Or can
> > anyone
> > > give me some tips what to do?
> > >
> > > Thanks in advance!
> > >
> > > Bernd
> > >
> > >
> >
> >
>
>
|
|
|
| Re: coordinate system/documentation [message #149543 is a reply to message #149255] |
Wed, 01 September 2004 08:24 |
| Eclipse User |
|
|
|
Yes, you're right, a common scale factor for both dimensions is probably
better.
Now, mentioning the constraints, we're getting to the nebulous areas.
From what I read in the documentation,
I understood constraints to be positioning hints for the layout manager.
How does this relate to scaling?
Now some loud thinking:
I'm using the ScalableRootEditPart as rooteditpart.
My topmost EditPart representing my IEdiorInput is called
DiagramContentsEditPart which extends AbstractGraphicalEditPart.
DiagramContentsEditPart .createFigure() creates a contentsFigure : Figure
and sets the XYLayout on this contentsFigure.
The ScalableRootEditPart can have an associated figure (getFigure()),
but I don't know which figure that might be. Traversing the JavaDoc hints
that it might be null.
Browsing the code reveals it is a viewport. I guess this is the Root Layered
Pane mentioned
in the class JavaDoc for ScalableRootEditPart.
Nevertheless ScalableRootEditPart creates a ZoomManger (getZoomManager()),
which in turn wants a ScalableFigure for construction.
Where does that come from? JavaDoc doesn't help here either.
Code reveals: it is the ScalableLayeredPane (Scalable Layers in above
mentioned JavaDoc).
Hmmm. Now I have the following choices:
a) The ZoomManager provides a method called setUIMultiplyer(double m)
It seems more of a Divisor, since the JavaDoc states (a bit winded,
though):
actualZoom= zoomSetting / m
b) I could call fig= ScalableRootEditPart.getFigure() which should be an
instance
of ScalableFigure (the ScalableLayeredPane) and call fig.setScale().
That would be a mistake, I guess, since the ZoomManager does just that
when changing zoom levels.
So this leaves option a).
Mission:
On Zoom Level 100% show the whole picure (as if calling FIT_ALL).
Note that FIT_ALL corresponds to 8% using my sample data.
So in DiagramContentsEditPart.refreshVisuals() I added these lines:
double height= myModel.maxHeight();
double width= myModel.maxWidth();
if(getRoot() instanceof ScalableRootEditPart)
{
ScalableRootEditPart root= (ScalableRootEditPart)getRoot();
Dimension available = root.getFigure().getClientArea().getSize();
// get size of client area
double zoomScale= 1.0;
if(width > height)
zoomScale= width / (double)available.width;
else
zoomScale= height / (double)available.height;
// avoid div by zero error
if(zoomScale == 0.0)
zoomScale= 1.0;
root.getZoomManager().setUIMultiplier(zoomScale);
}
My, my was I wrong. Reading the setUIMultiplyer() JavaDoc again I see the
errors of my ways.
(This just scales the texts displayed in the Zoom Combo...)
Being able to read is definitly an advantage...
Furthermore I have the suspicion that the client area has not its final size
here, yet.
Nevertheless, option b) seems still a bad idea...
Please turn me in the right direction!
Bernd
|
|
|
| Re: coordinate system/documentation [message #149591 is a reply to message #149543] |
Wed, 01 September 2004 10:52 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> Now, mentioning the constraints, we're getting to the nebulous areas.
> From what I read in the documentation,
> I understood constraints to be positioning hints for the layout manager.
> How does this relate to scaling?
It doesn't. The scaling happens only at the time of painting, external to
the layout.
> Now some loud thinking:
> I'm using the ScalableRootEditPart as rooteditpart.
> My topmost EditPart representing my IEdiorInput is called
> DiagramContentsEditPart which extends AbstractGraphicalEditPart.
> DiagramContentsEditPart .createFigure() creates a contentsFigure : Figure
> and sets the XYLayout on this contentsFigure.
>
> The ScalableRootEditPart can have an associated figure (getFigure()),
> but I don't know which figure that might be. Traversing the JavaDoc hints
> that it might be null.
> Browsing the code reveals it is a viewport. I guess this is the Root
Layered
> Pane mentioned
> in the class JavaDoc for ScalableRootEditPart.
>
> Nevertheless ScalableRootEditPart creates a ZoomManger (getZoomManager()),
> which in turn wants a ScalableFigure for construction.
> Where does that come from? JavaDoc doesn't help here either.
> Code reveals: it is the ScalableLayeredPane (Scalable Layers in above
> mentioned JavaDoc).
> Hmmm. Now I have the following choices:
>
> a) The ZoomManager provides a method called setUIMultiplyer(double m)
> It seems more of a Divisor, since the JavaDoc states (a bit winded,
> though):
> actualZoom= zoomSetting / m
It's a multiplier for the *UI*. See getZoomAsText, which is displayed in
the UI.
So you can have your diagram scaled out to 10%, but tell the user it's at
100%. (x10)
> b) I could call fig= ScalableRootEditPart.getFigure() which should be an
> instance
> of ScalableFigure (the ScalableLayeredPane) and call fig.setScale().
> That would be a mistake, I guess, since the ZoomManager does just that
> when changing zoom levels.
You should interact only with the ZoomManager. that is the zoom model.
> So this leaves option a).
>
> Mission:
> On Zoom Level 100% show the whole picure (as if calling FIT_ALL).
I disagree. Fit All will be a different zoom level depending on the size of
the diagram and editor's size.
> Note that FIT_ALL corresponds to 8% using my sample data.
>
> So in DiagramContentsEditPart.refreshVisuals() I added these lines:
> double height= myModel.maxHeight();
> double width= myModel.maxWidth();
> if(getRoot() instanceof ScalableRootEditPart)
> {
> ScalableRootEditPart root= (ScalableRootEditPart)getRoot();
> Dimension available =
root.getFigure().getClientArea().getSize();
> // get size of client area
> double zoomScale= 1.0;
> if(width > height)
> zoomScale= width / (double)available.width;
> else
> zoomScale= height / (double)available.height;
> // avoid div by zero error
> if(zoomScale == 0.0)
> zoomScale= 1.0;
> root.getZoomManager().setUIMultiplier(zoomScale);
> }
I would pick a constant UI multiplier, probably a power of 2, and then
calculate the zoom, not the multiplier.
>
> My, my was I wrong. Reading the setUIMultiplyer() JavaDoc again I see the
> errors of my ways.
> (This just scales the texts displayed in the Zoom Combo...)
> Being able to read is definitly an advantage...
> Furthermore I have the suspicion that the client area has not its final
size
> here, yet.
>
> Nevertheless, option b) seems still a bad idea...
>
> Please turn me in the right direction!
>
> Bernd
You need to intercept at the point when your editor has been sized to its
final width/height, and the calculate the zoom.
Is defaulting to FIT_ALL really that important? You may want to just
remember the document's previous zoom setting, which is what the Logic
example does. And that setting may be FIT_ALL or something else.
|
|
| | | | | |
| Re: coordinate system/documentation [message #149816 is a reply to message #149739] |
Fri, 03 September 2004 05:00 |
| Eclipse User |
|
|
|
I guess I ran into the old framework trap, looking for a function that one
thinks is so common that it should be there, but actually isn't.
So what I've done now is providing a conversion method int mm2pixel(double
v).
For starters, this method converts the given model value ([mm]) to a pixel
value using the screen resolution (Display.getDPI()).
Note that the resolution could be different for the x- and y-axis, so I DO
need diffent "scaling" factors for X/Y!
I apply this conversion to all layout constraints set during
refreshVisuals().
At least now my figures sizes and positions are in sync with the ruler, when
it is in UNIT_CENTIMETERS mode.
I guess I can extend that scaling function if I need additional conceptual
scaling (like 1mm in the drawing corresponds to 100mm in reality,
to get a large CAD part on a small piece of A4 paper).
Of course then my ruler is kind of "out of sync" again, because it still
measures paper sizes and not the "real-world" sizes.
For now, thanks for your advice!
CU
Bernd
|
|
|
Goto Forum:
Current Time: Fri May 09 22:01:55 EDT 2025
Powered by FUDForum. Page generated in 0.12755 seconds |
Home