Hi Randy,
Thanks for advice. How about using
Alt+ARROW to move an object with the keyboard. I think the solution with
"PERIOD followed by arrow keys" isn't easy to access. I don't see
Alt+ARROW is reserved by GEF. What we like to propose is:
Alt+ARROW -> fast move
shift Alt+ARROW -> slow move
julien
omondo
----- Original Message -----
Sent: Sunday, March 23, 2003 6:30
PM
Subject: Re: [gef-dev] Zoom Bug in
XYLayoutEditPolicy
I haven't downloaded Omondo,
but it sounds like you are mapping Ctrl+ARROW to "nudge". If you want
your editor to behave like other GEF editors, Ctrl+ARROW should be reserved to
change focus without changing selection, so that the user can then use
Ctrl+SPACE to multi-select. This is the same behavior used on the
windows desktop, trees, lists, and tables, and is necessary for keyboard
accessibility. To move an object with the keyboard, GEF uses PERIOD,
followed by arrow keys and then ENTER. Your application probably
inherits the behavior already.
It's great to see somone actually using the features we've added, and
finding both problems and solutions for them! We are aware of rounding issues.
They also affect the calculation of the freeform bounds, but the only
visible side effect is that the overview window gets notified of a 1 pixel
change in the size of the printable layers, and it refreshes itself.
It would be nice to calculate the freeform bounds with double accuracy
too.
We cannot make any changes
now for 2.1.0, but this fix can definitely be considered for our NLS release,
2.1.1. 2.1.0 will be declared this week, and 2.1.1 is due out in the
following few months. You should open a bugzilla to track this issue and
any others you encouter with zoom. But feel free to continue discussing such
fixes on this mailing list.
-randy
| "julien"
<julien@xxxxxxxxxx> Sent by: gef-dev-admin@xxxxxxxxxxx
03/23/2003 09:11 AM Please respond to gef-dev
| To:
<gef-dev@xxxxxxxxxxx> cc:
Subject: [gef-dev] Zoom Bug in
XYLayoutEditPolicy |
We
run into a bug in ths class XYLayoutEditPolicy with zoom != 1. In the method
getConstraintFor(), the same rectangle changes the both x and y value (+1 or
-1) after the following two operations
child.getFigure().translateToAbsolute(rect);
child.getFigure().translateToRelative(rect);
This problem appears when we move the graphic element by keyborad
with ctrl+arrow (you can test it with our last plugin:
eclipseuml_1.1.9.20030320).
The solution is
to define the precision Rectangle class as precisionPoint (attached in
this email) and change a bit of this method as following:
protected Object getConstraintFor(
ChangeBoundsRequest request,
GraphicalEditPart child)
{
Rectangle bounds = child.getFigure().getBounds();
PrecisionRectangle rect = new
PrecisionRectangle(bounds);
child.getFigure().translateToAbsolute(rect);
// original code:
// rect = request.getTransformedRectangle(rect);
{
rect.translate(request.getMoveDelta());
Dimension sizeDelta = request.getSizeDelta();
rect.width += sizeDelta.width;
rect.height+= sizeDelta.height;
}
child.getFigure().translateToRelative(rect);
rect.translate(getLayoutOrigin().getNegated());
if
(RequestConstants.REQ_MOVE_CHILDREN.equals(request.getType()))
{
Rectangle cons =
(Rectangle) getCurrentConstraintFor(child);
rect.setSize(cons.width, cons.height);
}
if
(RequestConstants.REQ_RESIZE_CHILDREN.equals(request.getType()))
{
Dimension minSize =
getMinimumSizeFor(child);
if (rect.width
< minSize.width)
rect.width =
minSize.width;
if (rect.height <
minSize.height)
rect.height =
minSize.height;
}
return getConstraintFor(rect.getCopy());
}
Please let me know if you
need more precision
julien
omondo
|