kicad-developers team mailing list archive

[Chris Morgan <chmorgan@xxxxxxxxx>]

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.

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
>
>
>