Re: [gef-dev] Zoom Bug in XYLayoutEditPolicy

[Randy Hudson <hudsonr@xxxxxxxxxx>]

ALT+LEFT arrow is mapped to "Go
Back" by Eclipse.  Used to navigate among open editors
ALT+RIGHT arrow is mapped to "Go
Forward" by Eclipse. " " " 

ALT+DOWN arrow is mapped to "select
into container" by GEF.  For example, when a circuit is selected,
ALT+DOWN will select the circuit's top-left child.
ALT+UP arrow is mapped to "select
parent" by GEF.

IMO, this operation is not that common,
and the "mode" approach of pressing PERIOD is good enough, and
doesn't require any accelerators.  As a user, I would rather drag
the items by mouse, and have the drag automatically recognize other object
in the diagram, and snap to those objects.  In Visio, this feature
is called "snap to geometry".  We'd like to implement this
in 2.2.

-Randy

"julien" <julien@xxxxxxxxxx> Sent by: gef-dev-admin@xxxxxxxxxxx 03/23/2003 02:31 PM Please respond to gef-dev

To:        Randy Hudson/Raleigh/IBM@IBMUS         cc:        <gef-dev@xxxxxxxxxxx>         Subject:        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 ----- 
From: Randy
Hudson 
To: gef-dev@xxxxxxxxxxx

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