-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
refactor(): Layout Manager #9152
Conversation
Build Stats
|
'object:layout:before': LayoutBeforeEvent & { target: Group }; | ||
'object:layout:after': LayoutAfterEvent & { target: Group }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
object or collection?
@asturur @ShaMan123 Sorry to put pressure, is there anything left blocking for this PR? We're releasing in production in two weeks but the current Layout implementation is bugged so we'd like to be able to move to Layout Manager and test it. The two most severe bugs we have are:
All issues that should be solved by the Layout Manager |
I have some changes i have proposed in a branch and then there would be some followup to change some code for handlign the I m not sure this PR is solving 1) tho. In theory we should be working just on this PR and i should insta-close any other PR, but then that never happen and this get pushed back |
This are some needed changes from me from the Object classes perspective: #9510 |
Probably not, but @ShaMan123 said he's waiting for the Layout Manager to fix the issue |
|
The bright side is that I think that will end all strokeUniform bugs all across fabric making it a stable feature |
i don't want to make other changes to transforms and geometry without talking about it before. I want to also defend _getTransformedDimensions. strokeUniform is a dumb feature that developer rely on because eventually is visually appealing for some geometry. strokeUniform is just plain useless because you could just change the strokeWidth OR you could change object properties outside scale and skew and get the exact same visual effect. |
ok i patched the fromObject function to get this merged, fromObject and toObject is what i want to follow up on. |
Motivation
#9148
Description
Extracted logic to
LayoutManager
that accepts aLayoutStrategy
(which is what the dev should override in order to create custom layout mechanisms e.g. css).Exposed on Group:
triggerLayout
methodlayout:before
,layout:after
events.Changes
object_modifying
triggers that run on moving, scaling etc. + movedtext:changed
to here as it should beinitialization
layoutBREAKING beta:
layout
prop in favor of passing an instance ofLayoutStrategy
_applyLayoutStrategy
=>performLayout
layout
event =>layout:after
layout_change
triggerin favor of the accuratecontext.strategyChange
getLayoutStrategyResult
=>LayoutStrategy#calcLayoutResult
prepareBoundingBox
=>calcBoundingBox
and squashgetObjectsBoundingBox
into itrenameremovedprepareInitialBoundingBox
=>calcInitialBoundingBox
(this method needs revisiting)_adjustObjectPosition
=>layoutObject
onLayout
=>onAfterLayout
changed
toobject_modifying
triggerTODO:
_watchObject
support adding relative objectsadding relative objects has 2 different options, adding before layout and adding after (which means the group needs to perform a different layout altogether because it must know the new center before the objects are added) - so I have decided to drop support for this. Adding relative objects before layout, which is the more sane use case can be achieved bygroup.add(sendObjectToPlane(relativeObject, group.calcTransformMatrix()))
Gist
In Action
https://codesandbox.io/p/sandbox/fabric-vanillajs-sandbox-forked-qh3256