Fixed Issue #1942 [BUG] Some modifying actions can still be performed#1989
Fixed Issue #1942 [BUG] Some modifying actions can still be performed#1989Jouvens-Corantin wants to merge 1 commit into
Conversation
MrStevns
left a comment
There was a problem hiding this comment.
Thanks for the contribution 🙂
There are of course still room for improvement in this area, for example we could check in Layer::moveSelectedFrames and Layer::reverseOrderOfSelection, Layer::setFrameSelected, Layer::toggleFrameSelected
But some validation is better than no validation.
| { | ||
| if (!visible()) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
I would prefer to keep this logic out of the Layer class.
Restricting frame movement based on visibility is a UI-level behavior designed to prevent accidental edits. however, from a data perspective, the model should allow moving frames regardless of visibility. We should probably move this check to the Interaction or Controller layer.
There was a problem hiding this comment.
I think that's up for debate. Imo. This is exactly where the logic should be, rather than in the UI. If we decide to build two UI clients, then the logic should be handled by our core rather than each respective client?
There was a problem hiding this comment.
If we plan to add script system or API. I believe we did discuss the feasibility before.
…performed on hidden layers) Added an if statements to check for the hidden layer property throughout the clear frame, select all, paste, paste from pervious frame, and move key operations. Added a deselect all function when switching from a unhidden to hidden layer to prevent selection issues.
|



Implemented validation checks for hidden layers across the Clear Frame, Select All, Paste, Paste from Previous Frame, and Move Key operations. Additionally, added an automatic deselect function when switching to a hidden layer to prevent selection artifacts.