-
Notifications
You must be signed in to change notification settings - Fork 16
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
Fix/tiling layout issues #1605
Fix/tiling layout issues #1605
Conversation
4e530e7
to
a8e2659
Compare
7e203c6
to
0cf1e47
Compare
af3f4cf
to
ea0b014
Compare
d918d82
to
1027770
Compare
Previously, if not passing the extent, yoga would assume dynamic height or width (when filling owner) to be 0 which is nonesense.
This replaces the previous integration of yoga-layout to support the tiling layouts in lively.next. Overall the initial approach was to tightly couple morphs and their bounds to the yoga nodes and utilize the yoga nodes like “abstract twins“ to compute the layout. This was problematic, since yoga does not like to be evaluated/executed on a per morph level, but instead works best when the layout is continously updated form the top most layout (the morph on top of a layout composition). As a result, this change tries to adhere more to the execution scheme that yoga prefers, making a bunch of hacky adjustments that were previously found in the code unnessecary.
Previously the default browser behavior was preventing a morph from shrinking beyond its submorph bounds when resized vertically by a layout.
This saves a bunch unnessecary compute cycles, improving performance.
Layouts would update the actual bounds of a morph too late, so that the breakpoints whould not get activated on time. We now move the updates for breakpoint affected morphs to an earlier point.
1027770
to
b14cae3
Compare
@@ -1052,7 +1052,7 @@ export class StylePolicy { | |||
*/ | |||
synthesizeSubSpec (submorphNameInPolicyContext, ownerOfScope, previousTarget) { | |||
const isRoot = !submorphNameInPolicyContext; | |||
const transformProps = ['extent', 'position', 'rotation', 'scale', 'lineHeight']; | |||
const transformProps = ['extent', 'position', 'scale', 'lineHeight']; |
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.
"apply rotation for root of component for now" - why only 'for now'?
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.
Because I am not yet sure if we run into unintended consequences. The reason I excluded transform properties from being applied to a morph when it is the root is that we mostly dont want that, even if these properties are not explicitly overridden.
For instance if we do not exclude the position from being applied to the root, it will lead to weird jump behaviors of morphs that suddenly align at positions that make no sense in the context they are in. For now I assume that rotation is seldomly defined at all, so it wont cause any issue. Also since it is applied so rarely you would assume that if a rotation is applied, it is there for a good reason.
Fixes a broken fill behavior and invalid margin computation in the tiling layout.