kicad-developers team mailing list archive

[Chris Morgan <chmorgan@xxxxxxxxx>]

On Mon, Jun 10, 2013 at 9:39 AM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

> On 06/10/2013 07:37 AM, Chris Morgan wrote:
> >
> > On Mon, Jun 10, 2013 at 8:29 AM, Dick Hollenbeck <dick@xxxxxxxxxxx
> > <mailto:dick@xxxxxxxxxxx>> wrote:
> >
> >     >
> >     > Can you test the attached patch:
> >     > It removes the if( ..) useless test (and perhaps broken) which
> explains
> >     > sometimes the panning does not happen.
> >     > It set the cross hair position before sending the event which uses
> this
> >     > position, and ensure the zoom center does not uses a strange
> previous
> >     > position.
> >
> >
> >     It works, and I like it for the short lived time
> >
> >        void EDA_DRAW_PANEL::OnMouseLeaving( wxMouseEvent& event )
> >
> >     will likely last (until solutions to a) or b) arrive).
> >
> >
> >     I have asked Chris to remove the goofy event dispatching mechanism,
> and simply call member
> >     function(s), and that would wrap up my last concern beyond a) and b).
> >
> >
> > Oh, I hadn't entirely grasped that from reading your email and haven't
> gone back to read
> > it since a busy weekend.
> >
> > I take it you mean the removing the dispatching of the dialog menu zoom
> center message? It
> > would certainly make the code simpler to just move the viewport around
> via a direct call.
>
>
> I would not want to generalize, since "simple" can be measured a number of
> ways....
> in this case clarity is more valued.
>
>
> > One of my questions on the block centering having to taint the zoom
> centering with
> > knowledge of block dragging but direct calls would allow that to be
> separated out cleanly.
>
>
> Yes, exactly.
>
> While travelling into nanometer "board internal units" (BIU) land, we ran
> into situations
> where the BIUs were wrapping beyond +-INT_MAX.  At one point is was so
> troubling that we
> almost had to punt on the transition, or had to go to a larger data type.
>
> Then I discovered that most of the travel limit enforcement could be done
> in a function named
>
> void EDA_DRAW_FRAME::AdjustScrollBars( const wxPoint& aCenterPositionIU )
>
> which, probably contrary to or beyond its name, also sets an important
> coordinate called
> m_DrawOrg.
>
> To make that function work, it was re-thought a bit and the calculations
> were modified to
> be done using DSIZE and DBOX.  These hold data types which allowed the
> math to bracket the
> +-INT_MAX range.
>
> This was a major breakthrough in the transition to nanometers, and nailed
> about 7 problem
> symptoms/bugs, merely by re-writing this one function.
>
> Now, here we have yet a lingering issue.  To use an analogy, say the block
> being moved is
> like a horizontal picture frame, and the earth is square and flat.  We
> know now we can
> push this picture frame off of a flat earth, if we drag it either left or
> up, and our
> point of contact with the picture frame is lower right corner.  If you
> push the picture
> frame out beyond the end of the earth (maybe world coordinates makes sense
> in this
> analogy), while holding a corner of it, and you are standing on the edge
> of the earth....
> well the picture frame falls when you let go.
>
> The picture frame is the boundary of the block being moved.
>
> I am thinking that if you fictitiously hold the far-est out corner of the
> picture frame,
> keeping the picture frame nearer to the center of the flat earth, then you
> can use the
> same existing function named above to clamp the travel of that fictitious
> picture frame
> anchor point.
>
> This is not a critical bug, since a person has to be almost trying to push
> the block
> unreasonably far left or far up, but it is a bug, and it will eventually
> come back in a
> report to us.
>
> Dick
>
>
> >
> > Chris
> >
>
>

Started looking at the moving code tonight.

- Is the rewrite by CERN going to cause all of this dragging/moving code to
be rewritten?

- It appears that we need to retain the OnMouseLeaving() handler. I'm able
to move the mouse fast enough where I think the mouse position is inside of
the view with one event and outside of the view with the next one. We can
call a common routine from the OnMouseEvent() and OnMouseLeaving() though
so at least we wouldn't have duplicate code.

Chris