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

Different Responsive Container Layouts #382

Open
cobyj33 opened this issue Dec 21, 2022 · 2 comments
Open

Different Responsive Container Layouts #382

cobyj33 opened this issue Dec 21, 2022 · 2 comments
Labels
enhancement New feature or request

Comments

@cobyj33
Copy link
Contributor

cobyj33 commented Dec 21, 2022

Is your feature request related to a problem? Please describe.
The design of pygame_gui really lends itself to absolutely and realtively positioned elements, which is great for sparse, static GUIs, but starts to become a problem when the amount of elements in the UI start increasing and dynamically changing. That leads to a lot of time spent calculating where an element would be or worrying about which element would be anchored to which, not creating a beautiful GUI
In essence, I'm proposing some sort of CSS Position and CSS Display layout for the UI.

This had already been mentioned in Issue #252 by @Karam-Sabbagh, but #252 mostly focuses on just laying out automatically from left to right with element wrapping. I think that's an amazing idea, but the idea could also be taken further for more layouts as well.

Describe the solution you'd like

  • Different layouts (like flexboxes, grids, etc...) that are not necessarily containers, but can be added as functionality to containers to dictate how they size and position their child components.
    Child elements will still be able to take a Rect or RelativeRect argument that could dictate their absolute position compared to their container, and this should probably stay as the default for backwards compatibility (plus it already works very well)
  • While with dynamic width and height we set the value to -1 to trigger it, which makes sense since dimensions can't really be negative, we can't really do the same with positions since they can be negative, so there'd probably have to be some sort of Union that would allow a child element to pass a Rect or some class with data for its container to use for calculations, or some sort of Factory type function or class that can create a dict with the proper keys for each given layout type

Main proposed layout types

Little Overview of Grid and Flexbox
To be honest, with just Flexbox and Grid, you can create about any layout possible by combining containers and nesting containers, so these are the main one's that I'd look forward to, but there could also be more simple ones like simple Row and Column layouts which just put the elements in a line without being responsible for calculating any dynamic sizes.

Describe alternatives you've considered
I've tried to use anchors to create more complex layouts like a menu bar, but the process of ordering each element to target another element always seems a bit hacky and fragile

Also, I've encountered some glitchy behavior with anchoring an element to another element which is also anchored to an element, but If I can reproduce it it'll go into a different issue

Anchors themselves should allow the layouts to be developed pretty easily though, I can already see it with flexbox, grid, and block layouts, which already position themselves in some sort of order with one element "anchored" to another.

Additional context
My main concern is that since so many components already use the relative-rect and implicitly position themselves relative to their parent container, there would have to be a lot of refactoring in order to add other functionality for dynamic positioning and resizing, but hopefully it should be possible. As of right now, this is really just an idea anyways, but it would really help the workflow of pygame_gui

(also, I'm just saying that it would be cool to allow users to make custom layouts as well, but this is already a monster of a proposal so I'll just leave it as a footnote)

flexbox css

@cobyj33 cobyj33 added the enhancement New feature or request label Dec 21, 2022
@MyreMylar
Copy link
Owner

MyreMylar commented Dec 22, 2022

I think more layout options is a fine idea.

I've honestly not delved too deeply into making very complicated GUI layouts in any of my projects using the library - and my designs have tended to be informed by what I've needed - or wanted when making some relatively simple games or utility apps. Usually a panel or Window has had a maximum of about 10 things in it.

I have a note (somewhere) to do a review of other (non-pygame related) python GUI/UI libraries to see what features they have that I'm lacking in here, and I'm pretty sure looking into grid layouts was one of the things that was going to come from that as I have some awareness of the grid layout in tkinter.

If you do have concrete example of a particular problem that is really annoying to solve with the current anchors and manually positioning system then that would likely help me with the design - as I tend to like creating an example program that demonstrates the current lack/problem and then solve it in the library until it is usable (and hopefully simple) solution.

@LondonClass
Copy link
Contributor

LondonClass commented Jan 17, 2024

I think more layout options is a fine idea.

I've honestly not delved too deeply into making very complicated GUI layouts in any of my projects using the library - and my designs have tended to be informed by what I've needed - or wanted when making some relatively simple games or utility apps. Usually a panel or Window has had a maximum of about 10 things in it.

I have a note (somewhere) to do a review of other (non-pygame related) python GUI/UI libraries to see what features they have that I'm lacking in here, and I'm pretty sure looking into grid layouts was one of the things that was going to come from that as I have some awareness of the grid layout in tkinter.

If you do have concrete example of a particular problem that is really annoying to solve with the current anchors and manually positioning system then that would likely help me with the design - as I ten to like creating an example program that demonstrates the current lack/problem and then solve it in the library until it is usable (and hopefully simple) solution.

Assuming I have a list. I now need to create some delete buttons to correspond to each element in the list. These buttons are arranged in a two-dimensional grid. The button automatically rearranges after deleting elements from the list.

The number of buttons may exceed the capacity of the container. So we also need a scrollbar that automatically changes size to cope with this.

It's really inconvenient to use this module to implement this, I hope it can be achieved through a simple process of creating buttons.

  1. You can pass in a method when creating a button, so there is no need to traverse the button when processing click events.

  2. There is a container that automatically generates scrollbars. Whether it's a panel or a window.

  3. There is a method for automatically generating grid layouts. You don't need to write your own rearrangement method when changing the number of elements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants