kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 06/09/2013 01:25 PM, Chris Morgan wrote:
> I think you have good points. I'll take a look at the more comprehensive fix for the issue.
> 
> On the point of animating the pan, what are your thoughts? The pan today is very
> discontinuous looking.


>From a user interface standpoint, the animation would be nice.  But with the work CERN is
doing using our GAL library, it may very well obsolete much of the panning logic.  The
risk in that would be too high for me in your shoes, at this point.  In your shoes, I
would want to eliminate the risk that my work does not get junked later, either by waiting
for the dust to settle or asking Tom or Orson about it.   I have been told that the GAL
work is progressing rapidly and so that day of potential obsolescence is a real deal.





As an interim fix I committed my patch, fulling expecting to toss it once your more
elaborate block corner logic is in place.



Dick





> 
> Chris
> 
> 
> 
> On Sunday, June 9, 2013, Dick Hollenbeck wrote:
> 
>     On 06/09/2013 01:01 PM, Dick Hollenbeck wrote:
>     >
>     >> The if() test should probably be:
>     >>
>     >>
>     >> if( size.x <= event.GetX() || size.y <= event.GetY()
>     >>      || event.GetX() < 0  || event.GetY() < 0 )
>     >
>     >
>     > Fine, that works.
>     >
>     > But let's remember that there are workspace limits defined by how many nanometers
>     can fit
>     > in a 32 bit integer workspace.
>     >
>     > I don't think any of our solutions yet are optimal.
>     >
>     > The mouse during the drag, can be in any of 4 corners of the block, no?
>     >
>     > If the mouse is in lower right corner, and you drag the block up and to the left, there
>     > are two problems:
>     >
>     > a) you don't get a pan until the block is off client (and so is the mouse).
>     >
>     > b) it is possible to position this block off workspace, such that you can no longer show
>     > either the board nor the block if moved up and up and left and left to the extreme
>     end of
>     > mouse travel.  Since the mouse travel is used in workspace limit calculation, and
>     not the
>     > objects in the block, then the block ends up being positioned off the workspace, I guess
>     > at a large negative number, less than -MAX_INT
>     >
>     >
>     > There are going to be 4 variations on problem b), for the four corners of the block.
>     >
>     > So a comprehensive solution is going to take more time.  We've got to always keep
>     objects
>     > in the allowed workspace coordinate system.  So panning needs more work.   At the place
>     > where we ask the mouse to be centered, we do end of travel limit detection and enforce
>     > limits.  In that same place, while dragging a block we have to use the appropriate block
>     > corner instead of the the mouse position.
>     >
>     >
>     > Dick
> 
> 
>     Chris, can you help us/me fix the two problems above?  The place to fix a) I think is
>     where you hooked in wit
>     h your patch.  And then we'll get rid of OnMouseLeaving().
> 
>     The event ID we are sending routes to this code in OnZoom() I assume:
> 
> 
> 
>         case ID_POPUP_ZOOM_CENTER:
>             center = screen->GetCrossHairPosition();
>             RedrawScreen( center, true );
>             break;
> 
> 
>     So lets copy that code to where you were firing the event, and get rid of the event
>     firing.  Then instead of GetCrossHairPosition(), provide the proper block corner, one of 4
>     choices.  You may not want to center the corner of the block but rather the block's
>     center.  But in any case you can use the correct block corner to decide if you want to
>     scroll.
> 
>     This fixes a).
> 
>     Fixing b) may mean limiting the block move itself, way upstream of anything we are talking
>     about here.  That does not have to be a GUI issue, it is simply a coordinate travel limit
>     established before you even think about drawing anything.  To do the math on the travel
>     limit, you should use a double type or int64_t type.  int will not work nor will long
>     which is often 32 bits also.
> 
> 
>     Thanks for your help.
> 
>     Dick
> 
>