Better "fixed point" management on constrained edge drags. about javascript-image-cropper-ui HOT 15 CLOSED

It didn't let me specify, but I'd call this an enhancement request, not a 
defect.

Is there actually any problem with the way the horizontal or vertical edge 
handles
work? I'm not actually sure why this change would be needed if there isn't any
problem currently.

It's not a "problem" (and is why I don't consider this a defect), but it's much 
more difficult to use the tools to 
select the desired region than it could be (so I would consider it a usability 
enhancement).  If you have nearly 
the correct selection, but just want it a little bit wider, it moves down while 
you're making it wider (rather than 
slightly growing both up and down), forcing you to then move the whole box 
again, (which requires careful 
mouse control in two dimensions instead of one, so it's physically a more 
difficult task).

In my (as yet incomplete) changes, I've added a selection mask, and in my use 
of that mask I'm selecting a 
circular region.  It's much clearer in this usage--dragging an edge wider can 
actually push content OUT of the 
circular selection.

Can't replicate

The easiest way to illustrate this is with a couple drawings:

I'm sorry that doesn't clarify it any further for me. I'm really not following 
what
the issue is.

The top drawing in those two makes sense if you were dragging the bottom right 
corner.
If you're dragging the middle of the right edge that behavior violates <a 
href="http://en.wikipedia.org/wiki/Principle_of_least_astonishment">the 
principle of least 
astonishment</a>, since users expect it to behave like the bottom drawing.  
Basically the handle you're 
moving doesn't go where the user moves it to (but rather slides down from 
there).  The point of reference 
(anchor point against which changes should be compared) should be the corner or 
edge opposite the one 
being moved.  This works for corners, but for edges the choice of the corner as 
an anchor point is confusing 
to my users.

It's really not a bug, just a behavior that doesn't match users' expectations.  
If you're not going to fix it, that's 
a reasonable answer, but saying you don't follow makes me want to keep trying 
to explain it :-)

I'm still very confused, here's what happens when moving handles, which I 
believe is
the expected behaviour and would not astonish anyone.

- Moving a horizontal only handle, the horizontal edge it belongs to moves in 
the
given direction of movement. No other edges move.
- Moving a vertical only handle, the vertical edge it belongs to moves in the 
given
direction of movement. No other edges move.
- Moving a corner (horizonal & vertical) handle, the vertical & horizontal 
edges it
belongs to move in the given direction(s) of movement. No other edges move.

Ah!  The critical bit I left out is that this is all dependent upon being in 
the fixed aspect ratio mode (for me it's 
"keep square").

Ah-ha, I see what you mean now.

However the way that my cropper works is exactly as it works in Photoshop and I
believe this is the expected behaviour. Otherwise, what if you got the top left
exactly where you want it but wanted the bottom right moving a little bit. With 
your
suggested change the top left would move.

It could be an option I suppose but in most cases this would not be the desired
behaviour.

If you move a corner the opposite corner shouldn't move.
If you move an edge, the opposite edge shouldn't move.

So this example: "Otherwise, what if you got the top left exactly where you 
want it but wanted the bottom right 
moving a little bit. With your suggested change the top left would move." isn't 
a good counter-example.  For 
moving corners it already does "the right thing", and the top right would NOT 
move.  I'm not suggesting that the 
behavior for moving a corner should change.  Just the behavior when you drag 
the edge of an aspect ratio 
constrained selection.  Again, not a critical thing to address, just a 
nice-to-have.

"If you move a corner the opposite corner shouldn't move."
 - It doesn't
"If you move an edge, the opposite edge shouldn't move."
 - It doesn't

Dale, please provide an example if you are getting different functionality

http://www.defusion.org.uk/demos/060519/cropper.php?
demoType=ratioFourThree&image=castle&formSubmit=Load+demo

If you drag any of the corners, the opposite one remains stationary.
If you drag the top edge, the lower left corner remains stationary (instead of 
the lower edge center marker).
If you drag the right edge or the bottom edge, the top left corner remains 
stationary (instead of the left/top 
edge center markers, respectively).
If you drag the left edge the top right corner remains stationary (instead of 
the right edge center marker).

Ah-ha I fully understand you now. However I do respectfully disagree that it 
should
work in the way you suggest. I think would find myself moving the cropper 
around more
using your way. It's a compromise neither are 100% correct and it entirely 
depends on
the situation which way you would want it to work as an end user.

So I won't be implementing this request.

Thanks for taking the time to understand this -- sorry it wasn't clearer to 
begin with. :-)