🚀 go-pugleaf

JD wrote:

>> Third option would be to somehow remember last mouse
>> position, and only reduce the box by the delta rather than
>> the absolute.
>
>I'm not sure what you mean by this. The code currently saves
>the click point, makes the size change and then updates the
>click point to the current point. The change in size is
>calculated by comparing the click point to the current point.

Well, what I saw was if the mouse is one pixel left of bar, box
collapses at one pixel speed (constant). To mimic normal (non-maxed
scroll bar), moving mouse left at constant speed, to move box right at
constant speed, means instead of taking absolute difference from bar
to mouse for the speed, take difference in movement from last draw to
this, as speed.
Now, that sounds a lot like what you are saying it is doing.
So, the question is...what coordinate system is it using?
If it is measuring mouse position from left-most (hidden box) edge,
then you would still see larger movement than the absolute
screen-coordinate movement.

>If the mouse it at 100 and moved to 99, after that one pixel
>move has been processed and the window is redrawn, the mouse
>is now at 98 even though it wasn't moved!

Which would indicate that you are reading client (box) coordinates at
a time when you really want to know the real-world (screen)
coordinates. There _are_ conversion routines somewhere in the api.....