Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

4 lock types can be easily removed via UI #65

Open
iamsterdam800 opened this issue Apr 18, 2023 · 4 comments
Open

4 lock types can be easily removed via UI #65

iamsterdam800 opened this issue Apr 18, 2023 · 4 comments

Comments

@iamsterdam800
Copy link

I need to lock some objects in the starter template that I provide to the user.
But users can easily disable those locks.

image

  • element with removable lock can be still deleted via Layers panel (the delete button is enabled there)
  • to remove draggable, resizable and contentEditable locks all you need to do is to lock the element with the lock button (either in Layers, or in the topbar) and unlock it back. all the locks will be removed from this element!

Only selectable lock works.

image

Reference polotno export with different locks:
polotno_locks.json.zip

@lavrton
Copy link
Collaborator

lavrton commented Apr 19, 2023

element with removable lock can be still deleted via Layers panel (the delete button is enabled there)

This is a bug. Thanks for pointing into it.

to remove draggable, resizable and contentEditable locks all you need to do is to lock the element with the lock button (either in Layers, or in the topbar) and unlock it back. all the locks will be removed from this element!

For now, this is intentional. Like, a user can lock/unlock elements when they need that.
Only "selectable: false" is a total lock when a user can't even select an element to do anything with it.

Do you have a use case when you want to lock something buy still allow selection? I would like to understand better.

@iamsterdam800
Copy link
Author

iamsterdam800 commented Apr 19, 2023

Yes, in the usecase with the PageView elements, that I explained here, I need to lock the PageView elements from moving or resizing or editing content or removing, because they are unchangable part of the final disign. At the same time I want the users to select them, so that for example I can show text & button on the Topbar.
Another example, the box diecut is an svg element. User cannot move or resize this element, because it should be in exact same position for printing / cutting. However, they can select the element and change its color (to make the whole box base red or green). So it must be selectable & contentEdatable, but not movable, resizable or removable.

For now, this is intentional. Like, a user can lock/unlock elements when they need that.

To be honest, I don't see why general lock/unlock should remove all the custom locks. It should keep the previously set custom locks as they were.
The user can not set custom locks themself. So if I set the custom locks in the template, I did it for a reason.

Maybe if you want to give a user possibility to override custom locking, provide a flag for it (like this)?
But I really don't see it as a default behaviour.

@lavrton
Copy link
Collaborator

lavrton commented May 14, 2023

I would need to deeply think about it. Your use case does make sense to me. Currently, there are no "custom locks". Locks that you change from API and locks that can toggle the user are the same locks. Probably I can add "lockChangeEnabled", that will prevent changing locking from UI.

@iamsterdam800
Copy link
Author

Yeah, that's one way..
Or (maybe cleaner) just add field generalLock.
When you change locking from UI, you only toggle the generalLock
And when you check the other locks in the code, you do e.g.:
if (draggable && !generalLock) { /* ok to change */ }
is that an idea?

@lavrton lavrton added this to Polotno May 20, 2024
@lavrton lavrton moved this to Ideas in Polotno May 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Ideas
Development

No branches or pull requests

2 participants