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
add more orientation options to BoxLayout #8679
base: master
Are you sure you want to change the base?
add more orientation options to BoxLayout #8679
Conversation
Since version layout_direction = OptionProperty("left-to-right", options=("left-to-right", "right-to-left", "top-to-bottom", "bottom-to-top")) Note:I also wonder if the layout should handle these layout changes independently, since the |
Is that really a better way? Compared to this PR, it seems to just make the API inconsistent as StackLayout and GridLayout don't have that property.
I believe so because the |
The fact that the ordinal number of the widget in the In any case, it would be correct to consider any situation where the widgets inside the BoxLayout overlap each other as a mistake. The solution to the problem would be to provide a mechanism for arbitrary manipulation of the placement order, independent of the order of rendering and processing touches. For example, the |
What about accepting @DexerBR's suggestion, but not deprecating |
If I understand Kivy correctly, the rendering sequence needs to be opposite to the sequence of receiving touch events in order for its GUI system to work so
itself should be fine. However, yes, the layout doesn't have to depend on the BoxLayout:
Widget:
pos_hint: {'layout_index': 0, }
Widget:
pos_hint: {'layout_index': 1, } But I think this excessively breaks the API even though Kivy is moving towards the next major version, and more importantly, it doesn't sound convenient. What if you need to add a widget to a BoxLayout where the
I don't think I fully addressed this in the previous comment. You meant you can add a widget on the left/top side of the existing children by using the boxlayout.add_widget(child, index=len(boxlayout.children)) Still, it feels strange to me that I'm starting to think @DexerBR's idea might be just as good as mine because it reduces the risk of breaking the API. if boxlayout.orientation == 'horizontal':
# assumes the orientation to be horizontal
# assumes the direction to be left-to-right
else:
# assumes the orientation to be vertical
# assumes the direction to be top-to-bottom Consider existing code like the above. @DexerBR's approach might disrupt the assumption regarding the direction, but it doesn't affect the assumption regarding the orientation, whereas mine could disrupt both. In summary, @DexerBR's and EBabz's prioritize the compatibility, while mine prioritizes the consistency in the API. I think both are equally good. |
86c2b79
to
4475ab4
Compare
I would prefer not adding this feature to BoxLayout. For a specific way to layout your widget it would make a lot more sense to have a
This would be scalable in that one can then in that case combine this behaviour with other layouts... Think users having their own custom layouts, without having to specifically use BoxLayout. |
Why do you prefer And I don't think the class LayoutOrderBehavior:
def very_little_computation_that_can_be_used_across_many_layouts():
...
def boxlayout_specific_computation():
...
def gridlayout_specific_computation():
...
def stacklayout_specific_computation():
... |
GridLayout, StackLayout offer you the same option, i.e to choose the order of the widgets to be added. You can even just override the existing behaviour using your own LayoutBehavior locally, for instance. Current GridLayout does not layout the widgets with a exactly equal distance from each other.
Where the class
There could be many different ways a developer could choose to display/layout their widgets. You should not be changing the existing layout but extending it in your own code based on your own needs. Changing it for every one would break it for every one who relies on that behaviour. Adding a Behaviour like this would be preferable. |
Maintainer merge checklist
Component: xxx
label.api-deprecation
orapi-break
label.release-highlight
label to be highlighted in release notes.versionadded
,versionchanged
as needed.This PR adds new orientation options (
right-to-left
andbottom-to-top
) to the BoxLayout.Potential API break
This might break the API because of the existing code like this:
The else-clause part of the code above always assumes that the boxlayout lays out its children from top to bottom, but after this PR is merged, it can lay them out in any of the following directions: top-to-bottom, bottom-to-top, or right-to-left.
Alternative Idea I was suggested
This might be an option but consider other layouts:
Using a boolean property may not be a good choice for maintaining consistency.