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

More sizing options for entities #18

Open
craigmjohnston opened this issue Mar 20, 2017 · 3 comments
Open

More sizing options for entities #18

craigmjohnston opened this issue Mar 20, 2017 · 3 comments

Comments

@craigmjohnston
Copy link
Contributor

This is an enchancement/feature request. I know you're busy so this is kind of just when you can get to it (if you agree!) or I could do a PR sometime and you could look at that.

It'd be handy if entities could have these extra sizing options:

  • Fit parent (i.e. fit remaining space in parent) - e.g. if you had a panel containing a button and another panel, you could set the child panel to FitParent and it would be expanded to Parent.Size.Y-button.Size.Y. If there's more than one entity with this option set, they'll share the remaining space, so 2 entities get 50% each, 3 get ~33% each, etc.. I was also thinking that this could probably replace Vector2.Zero (i.e. parent size), since this is the more intuitive outcome when you're trying to fit to parent.
  • Fit children - e.g. a panel containing several buttons, the panel is set to fit children, it resizes so that its height = the height of all the buttons added together (obviously plus any padding, etc.).

Also, I was thinking the rule with these could be that they can't be stacked both ways, e.g. a panel with FitChildren containing a panel with FitParent. If they're stacked, the child with FitParent sizing gets set to default. Either that or you could just throw an exception (which might be a better idea, then you don't have the annoying instance where the layout just isn't looking right but you can't figure out why).

Lastly, because there would be more sizing options, it would probably be a good idea to make a static class, e.g. something like:

public static class Sizing {
  public static float Default = -1;
  public static float FitToParent = 0;
  public static float FitToChildren = -2;
}

So then you can do

new Panel(new Vector2(Sizing.FitToParent, Sizing.FitToChildren), ...)

and it's explicit what sizing method you're using, and you can add more in the future just by expanding them into the negatives (-3, -4, etc.).

There's quite a lot in this issue, it could probably be split up, but I just wanted to kind of gauge what you thought about it and get some feedback!

@RonenNess
Copy link
Owner

RonenNess commented Mar 22, 2017

Hi Craig,

I like the idea and what you did with the Sizing class. I have a version almost ready in dev that I will merge with stable soon, this could be really nice ideas for next version after that one.

I'll keep you updated when relevant.

Thanks :)

@chitoiur
Copy link

chitoiur commented Jan 5, 2019

Ronen, I was wondering what the status of this was? I am running into the same situation and have not been able to find a way around it. I have a panel with a paragraph and then another panel below that. I want to make the inner panel fill the remaining space after the paragraph, but cannot figure out how to do that with the current API.

@WTRipper
Copy link

The behaviour described by @chitoiur is not implemented currently and could only be added to the current API by overwriting some of the Entity methods which is not ideal for such a fundamental feature.
I had a look into the code and thought about a few possibilities to add the behaviour as a built-in, optional feature:

  • Currently GeonBit.UI uses a kind of implicit row layout when using auto anchors. One could add the behaviour by tracking the rows that are created. Then when using a "Fill remaining space" flag or value or something on a entity one could determine the total height of all rows for vertical space or the total width of all entities in the current row for horizontal space.
  • Another possibility would be moving the responsibility of layouting completely from the Entities into a layer between parent and children - like a Layout object. This would make the layouting more adaptable but at the same time would require a larger refactoring since the layouting and sizing is quite "interwined" at the moment.

Are there other possibilities you see @RonenNess? I am considering those changes for my fork at the moment.. Would there be an interest in pulling those changes back into your original repo afterwards?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants