Home » Eclipse Projects » GEF » coordinate system/documentation
|
| Re: coordinate system/documentation [message #149026 is a reply to message #148972] |
Mon, 30 August 2004 17:02   |
Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
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 #149251 is a reply to message #149026] |
Tue, 31 August 2004 17:49 |
 Bernd Hofner
Messages: 68
Registered: July 2009 |
Member |
|
|
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 18: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 12:24 |
Bernd Hofner
Messages: 68
Registered: July 2009 |
Member |
|
|
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 14: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 #149719 is a reply to message #149696] |
Thu, 02 September 2004 14:36 |
| Eclipse User |
|
|
|
Originally posted by: contact.jasperassistant.com
For me 100% would be the real physical size (as in inches * DPI) and not
pixels. Not sure if it can be done.
Regards,
Peter.
Bernd Hofner wrote:
> Now to the zooming battlefield:
>
>
>>>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.
>
>
> This is a question of perception. What does 100% denote, if not all?
>
> You look from the programmer side at the zoom level:
> 100% <=> one model pixel = one display pixel
> 200% <=> one model pixel = two display pixels
>
> I look from the user perspective on the zoom level setting:
> 100% <=> I can see my whole drawing
> 200% <=> I can see half of my drawing (with more details)
>
> From what I have seen in standard software, I admit that the first model is
> used quite often.
> That doesn't make it more intuitive.
>
> I haven't though this quite through to the end. It might be useful to think
> of the canvas as a
> piece of paper with given dimensions (say A4). Then think of the figures on
> the "paper"
> as a scaled view of reality (as in a technical drawing) with a given scale
> (say 1:100).
> Probably this will make things more complicated, as now there could be two
> modes
> of scaling:
> - the drawing scale (1:100); changing it could lead to the figures no
> longer fitting on the paper
> - the monitor zooming scale; which just zooms into the drawing using the
> conceptual pixel (programmers) view
>
> I guess I have to firm up what I really want here, first.
>
>
>>You need to intercept at the point when your editor has been sized to its
>>final width/height, and the calculate the zoom.
>
>
> I agree. But where in the djungle of framework operation might this be?
>
>
>
|
|
|
| Re: coordinate system/documentation [message #149739 is a reply to message #149688] |
Thu, 02 September 2004 17:46 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> We beginn with the ruler-unit setting: UNIT_PIXELS.
> Now my NORTH ruler ends at about 10200 [pixel]
> The max length of the displayed product (model) is 10200.0 mm
> So my models millimeters are interpreted as pixels,
> which is logical, since I didn't use any kind of coordinate
transformation.
You didn't, but the ruler is going to below.
> Now we switch the ruler-unit to UNIT_CENTIMETERS.
> Now my NORTH ruler ends at 269 [cm]
Because of the Display's DPI.
> Ehm, why? I suspect that this has something to do with the display
> resolution
> (DotsPerInch which is probably converted to DotsPerCentimeter).
> like: 10200 pixel / 96DPI = 106.25 Inch = 269.875 cm
The ruler understands the ZoomManager AND the UI multiplier, so the solution
is still the same as before.
> We end again at the outset of the problem:
> How do I tell GEF that my models units are to be converted from
millimeters
> to pixels?
If you are converting (1 mm in the model) <==> (1 pixel on the screen), then
you need to do the math, measure how big a pixel really is, and set the UI
multiplier accordingly.
> I'll get to the zooming battlefield in the next posting...
>
> Thanks for your patience!
>
>
|
|
|
| Re: coordinate system/documentation [message #149747 is a reply to message #149696] |
Thu, 02 September 2004 17:48 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> This is a question of perception. What does 100% denote, if not all?
>
> You look from the programmer side at the zoom level:
> 100% <=> one model pixel = one display pixel
> 200% <=> one model pixel = two display pixels
>
> I look from the user perspective on the zoom level setting:
> 100% <=> I can see my whole drawing
> 200% <=> I can see half of my drawing (with more details)
I've never seen this before. 100% either means "pixels", or if you have
real-world units like inches, it tried to display an inch as an inch by
asking the OS for the Display's DPI. Of course the monitor size is unknown
usually so this is just an approximation
|
|
| |
Goto Forum:
Current Time: Fri Nov 01 00:30:27 GMT 2024
Powered by FUDForum. Page generated in 0.06727 seconds |
] 
Search
Help
Register
Login
Home
