Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gef-dev] Zoom Bug in XYLayoutEditPolicy

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

Back to the top