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

Fix/tiling layout issues #1605

Merged
merged 27 commits into from
Jul 22, 2024
Merged

Fix/tiling layout issues #1605

merged 27 commits into from
Jul 22, 2024

Conversation

merryman
Copy link
Member

@merryman merryman commented Jul 4, 2024

Fixes a broken fill behavior and invalid margin computation in the tiling layout.

@merryman merryman requested a review from linusha July 4, 2024 11:47
@merryman merryman marked this pull request as draft July 4, 2024 13:55
@merryman merryman marked this pull request as ready for review July 8, 2024 13:05
@merryman merryman force-pushed the fix/tiling-layout-issues branch 2 times, most recently from 7e203c6 to 0cf1e47 Compare July 12, 2024 10:09
@merryman merryman force-pushed the fix/tiling-layout-issues branch 2 times, most recently from d918d82 to 1027770 Compare July 13, 2024 12:24
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.
lively.morphic/layout.js Outdated Show resolved Hide resolved
@@ -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'];
Copy link
Contributor

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'?

Copy link
Member Author

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.

@linusha linusha merged commit 1dd1731 into main Jul 22, 2024
4 checks passed
@linusha linusha deleted the fix/tiling-layout-issues branch July 22, 2024 16:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants