-
-
Notifications
You must be signed in to change notification settings - Fork 935
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
feat: Draft for new Layout components Row and Column #1971
Conversation
I'm worried about overriding the I believe a reasonable alternative would be to:
|
@st-pasha Thanks for the feedback. Makes all sense imo. |
@st-pasha Regarding the filter in layoutChildren: You mean filtering like
and then casting to one of the interfaces where needed, e.g.
|
With the merge of PR #1976 the class |
@spydon Can we discuss how to proceed with this draft? |
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.
Two small nits but I think this good for an initial approach.
I have two suggestions though
- The code between Column and Row components are very similar, I wonder if we could share some methods/logic between them to avoid repetition.
- I would suggest to move these components to the experimental namespace, that we way we have the freedom to explore this new functionality without fear of breaking changes.
@erickzanardo Thanks for the feedback. I've refactored the 3 classes as follows:
|
Awesome. From my part. I would say this is ready to receive tests and examples. Once we have |
Great, thank you, Erick. Then i will write some tests for it. |
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.
Just the size
s for the components that are missing I think (and tests for the size
s), otherwise it looks good!
return; | ||
} | ||
final currentPosition = Vector2.zero(); | ||
final componentsDimension = list.fold<double>( |
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.
This should be set to the PositionComponent
's width or height right? And then the one that isn't set here should be the max
width/height of the child components.
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.
You mean componentsDimension
? This only sums up the width (or height) for all components which will be used to calculate the free space in all spaceXY and the center alignment type.
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.
The size of the parent component is checked and handled here:
flame/packages/flame/lib/src/experimental/layout_component.dart
Lines 45 to 48 in 7486750
final dimensionAvailable = size[vectorIndex] != 0.0 | |
? size[vectorIndex] - absoluteTopLeftPosition[vectorIndex] | |
: gameRef.canvasSize[vectorIndex] - | |
absoluteTopLeftPosition[vectorIndex]; |
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.
dimensionAvailable
should possibly be the parent's size
, or it's own size
, it shouldn't check anything regarding the canvas size or such.
So either we let the size
of the LayoutComponent
grow dynamically with the children added to it, or it has a set size from the beginning, but to make it more flutter like I think that it should grow the size itself and then just be constrained by the parent's size
.
Because right now the layout component's size
will be (0, 0) now since it isn't updated when children are added. The setter of size
should probably also be overridden so that it can't be set too if we choose to go with a dynamic size.
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.
But can the parent not also have a zero size?
I had it in mind like this: if the developer defines a size for LayoutComponent then this size will be taken for the available dimension calculation, else it just takes the canvas' width or height for the end edge.
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.
As you like. It's already implemented though.
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.
Perhaps let's not overcomplicate this?
In the first version of the LayoutComponent the
size
will have to be provided explicitly. In the next version (in a separate PR), we will relax that requirement and allowsize
to be omitted, in which case it will be derived from a parent.
When re-reviewing this I agree, maybe it's a bit overkill to listen to the parent's size.
Then we can scrap isManuallySized
too, so that the component only grows to its size, can we restrict the user from changing the size
variable from the outside though? Then we only need to do the layout when children are added.
Later we could add a WrapComponent
so that components can be organized within a set size.
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.
What do you think about this @rivella50? :)
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.
@spydon Sure, why not. I've already removed setting the size
and isManuallySized
last weekend.
Just to be clear: Without being able to set the size
(parent or LayoutComponent
) the alignment types spaceXY don't make sense anymore.
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.
Without being able to set the size (parent or LayoutComponent) the alignment types spaceXY don't make sense anymore.
Hmm, that's true, a shame to drop that one...
But maybe it is worth dropping it to just have a simple first version?
doc/flame/components.md
Outdated
@@ -1104,6 +1104,21 @@ Check the example app | |||
for details on how to use it. | |||
|
|||
|
|||
## LayoutComponent |
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.
If we won't expose this we should change the docs to be about RowComponent
and ColumnComponent
instead.
return; | ||
} | ||
final currentPosition = Vector2.zero(); | ||
final componentsDimension = list.fold<double>( |
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.
Perhaps let's not overcomplicate this?
In the first version of the LayoutComponent the
size
will have to be provided explicitly. In the next version (in a separate PR), we will relax that requirement and allowsize
to be omitted, in which case it will be derived from a parent.
When re-reviewing this I agree, maybe it's a bit overkill to listen to the parent's size.
Then we can scrap isManuallySized
too, so that the component only grows to its size, can we restrict the user from changing the size
variable from the outside though? Then we only need to do the layout when children are added.
Later we could add a WrapComponent
so that components can be organized within a set size.
final MainAxisAlignment alignment; | ||
bool _allowSetSize = false; | ||
|
||
/// gap between components |
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.
/// gap between components |
for (var k = 0; k <= 1; k++) { | ||
group(k == 0 ? 'RowComponent' : 'ColumnComponent', () { |
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.
would this be better as:
for (final name in ['RowComponent', 'ColumnComponent']) {
or, maybe even better, extract the block to a function and call it twice?
group('RowComponent', testLayoutComponent(RowComponent))
group('ColumnComponent', testLayoutComponent(ColumnComponent))
_allowSetSize = true; | ||
size[vectorIndex] = totalSizeOfComponents; | ||
_allowSetSize = false; |
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.
I don't think you need this variable -- can you just user super.size
?
example:
class A {
double size = 1.0;
}
class B extends A {
@override
set size(double size) {
assert(false, 'Setting the size is currently unsupported.');
}
void foo() {
// this.size = 2.0; -> this breaks
super.size = 2.0;
}
}
void main() {
final b = B()..foo();
print(b.size);
}
/// type. | ||
class RowComponent extends LayoutComponent { | ||
RowComponent({ | ||
LayoutComponentAlignment alignment = LayoutComponentAlignment.start, |
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.
can't you use super.alignment
here?
@@ -1104,6 +1104,18 @@ Check the example app | |||
for details on how to use it. | |||
|
|||
|
|||
## RowComponent & ColumnComponent |
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.
if it is experimental, should we flag it in the doc, similar to how it is done elsewhere?
Do you want to continue on this PR @rivella50 or should we take it over? :) |
@spydon Feel free to take it over. My current project doesn't let me much free time at the moment. |
I'll close this for now since it's been open for so long, but we should definitely look at this when creating these components based on the |
Description
This is a draft for the planned row and column components for Flame.
At the moment it only covers the horizontal direction class
RowComponent
.As soon as we are clear what features these 2 components will have, the class
ColumnComponent
will be added accordingly.How to use
RowComponent
can be seen in issue #1944 .To be discussed:
Checklist
fix:
,feat:
,docs:
etc).docs
and added dartdoc comments with///
.examples
ordocs
.Related Issues
Closes #1944