Lock and controls (drawing+cursors)

[ncou]

Hi,

Just my 2 cents idear, but perhaps it could became a new feature.

When you set "lockRotation : true" the rotation is locked but the "rect" control is still present/draw.
ofcourse there is the "hasRotationPoint" propertie, but "lockUniScaling" disable the drawing of some controls rect.
1)
It could be interesting to not draw the rotation rect control if hasRotation=false OR lockRotation

When the scalingX&Y or MovementX&Y is set to true, the cursors (to stretch or move) are still displayed it's a bit disturbing to have the cursor while the action is disabled.
Perhaps those tests could be added in the fabric.js code, to disable cursors change ?

@asturur : What do you think ?

[asturur]

i think that this is right.
i have to verify them all but yes. for embedded functions there should be consistency.

[asturur]

so the idea is this:

lockRotation, lockUniscaling, lockMovement will LOCK the action, disable the cursor that tells you the action is available.

they will not disable the corners since this is weird.

Since this is a behaviour change, it will go just in fabric 2.

[asturur]

maybe introducing the notAllowed cursor as not-allowed css feature

[ncou]

yes it could be great to have a propertie "notAllowedCursor" cursor for the locked actions it's would be more clear for the user when the object transformations are locked.

But perhaps (when the lockMovementX&Y are set) this locked cursor should not overide the "hoverCursor" defined, because it would be strange for the users to have a locked cursor on hover while we can still select the object. Of course the "moveCursor" would be overriden by the "notAllowedCursor".

Not sure if i am clear enough. In any case it's a good feature for the v2.0.0 :)

[ncou]

@asturur : thank you, i will do some testing. By the way i tryed to build the library from the master, but the build.js throw a missing file "named_accessors.js" in the src\util folder.
The file is missing there is only a "named_accessors.mixin.js" file, I renamed it and the build is now ok.

[asturur]

the right name is named_accessors.mixin.js. Would you been so kind to open a PR that change build.js with the correct name? Are you building with modules=ALL? 2017-07-03 17:24 GMT+02:00 ncou <[email protected]>:

…

@asturur <https://github.com/asturur> : thank you, i will do some testing. By the way i tryed to build the library from the master, but the build.js throw a missing file "named_accessors.js" in the src\util folder. The file is missing there is only a "named_accessors.mixin.js" file, I renamed it and the build is now ok. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3712 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABI4QEifs7QXdI0cjpAbAoGH6jEf4iLvks5sKQecgaJpZM4MElsy> .

[ncou]

the PR is done.
Yes i use the string "node build.js modules=ALL" to build the lib.

[ncou]

@asturur : i think there is a small bug.
http://jsfiddle.net/qu96G/20/

If i lock the scalingX or scalingY, the middle controls are correctly locked, but not the corner controls.
I can't stretch the object using the corner controls, but the cursor is not "not-allowed".
Disable line 38 the "lockUniScaling" to have the centered controls with the correct notallowedcursor.

Question :
If I lock the movementX + movementY, shouldn't the hoverCusor be overrided by the "notAllowedCursor" ? my object can't move, but the cursor is still the moving cursor.
=> Perhaps it's a border use case.

PS : If i select multiple object, the lock properties is ignored, so the not-allowed cursor is not displayed. But there is a ticket about this.

[asturur]

to answer:

for movementX, movementY i opened a new feature ticket.

for the lock i did not rememeber that lockScalingX was killing the corner scaling! i ll fix it.

lockuniscaling is something to be checked. if is disabling controls, i need to modify it also.

[asturur]

For the group, just to explain a bit:

Group is not gonna check children properties for lock* anymore. It will respect just its own properties.

A new class will be created, called ActiveGroup that will be behave as a multiSelection. Group will be more a simple container with little features, the ActiveGroup will inherit from Group and do the things a user maybe expect.

Also creating a new ActiveGroup should also solve the headaches of creating a multi selectin programmatically.

[ncou]

Does this mean the logic to "lock" the group based on the "children-objects" properties, will be already coded in the future "ActiveGroup" object ? or does this need to be developped by each developer ?

Will it be possible to implement our own rules to avoid a selection ? for example if i don't want an object being added in the "ActiveGroup" selection (for example because it's a locked object), could i implement this behavior ?

[asturur]

Yeah this is the right moment to rise those questions.
I ll take in consideration this thing while writing, to see if it can fitted and where.
(if this.selectabled does not work.... )

[asturur]

i did this so far. #4076 not working yet
i ll continue tomorrow.