Skip to content
This repository has been archived by the owner on Dec 2, 2019. It is now read-only.

Dynamic height of a row #504

Open
jovanivanovic opened this issue Aug 24, 2017 · 2 comments
Open

Dynamic height of a row #504

jovanivanovic opened this issue Aug 24, 2017 · 2 comments

Comments

@jovanivanovic
Copy link

Hello.

Is there a way to have row change its height based of inner elements height? For example, I am using nk_label_wrap and I can't really know in advance how much space it's going to take in height.

@vurtun
Copy link
Owner

vurtun commented Aug 25, 2017

Hey,
layouting is still a problem in nuklear. While it is easy to have a simple row layouting scheme in this type of gui libraries it is a lot harder to get the real thing. It is actually something I am currently still working on.

Basically GUIs are just a tree. In nuklear that tree does not exists in memory but in your code layout. The problem is that the UI tree is traversed from the top to bottom (root to leafs). Layouting however requires both bottom to top (leafs to root) and then top to bottom afterwards. The first pass is to calculate the required size and the second pass is for actual size calculation.

One possible solution is what google did for their GUI and have a callback that calls the UI for each pass. Another solutions is this proposal. So in theory it is possible to add extensive layouting to this type of GUIs, but all these solution have their downside and I am basically spending a lot of my free time on research to find out what is the best way to solve all these and a lot more problems.

@AntiBlueQuirk
Copy link
Contributor

I would like to express interest in a more capable layouting system as well. Looking at the library, I know that's no small order, but it would make nuklear much more powerful.

I would be fine with a multipass system. I don't think it's terribly difficult to wrap your UI functions in loop, and call them as many times as nuklear needs. Unity has a system like this, where OnGUI functions are actually called for every event, not just twice. There's a Layout event, then a Repaint event, then another Layout, followed by all the input events.

Something like this could work, and I think is pretty flexible:

nk_eventloop(ctx) { //like nk_foreach
  //call UI functions
  //get current event with nk_current_event(ctx)
}

The biggest problem I see with this is that I really don't think you can get away with it without major breaking changes.

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

No branches or pull requests

3 participants