-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
Child Windows: support the ImGuiWindowFlags_AlwaysAutoResize flag for ch... #160
Conversation
… child windows. This appears to do the right thing in my testing, and has no impact on paths where the flag is not set.
Thanks Adam. The patch shouldn't introduce any problems but this looks inconsistent with the behaviour of ImGuiWindowFlags_AlwaysAutoResize for normal window. The flag is supposed to resize a window to the size of its content. Here it is being resized to fit the remaining space in the parent. I am also curious as to how you are using this. A child window resizing to its content kind of defeat the point of a child window since it won't scroll. I am aware of at least one thing that may be remotely related: EDIT I am also not sure of the effect of the added test in Begin()
|
My bad I had misinterpreted the change, so disregard my comments above. But this question still stands: "I am also curious as to how you are using this. A child window resizing to its content kind of defeat the point of a child window since it won't scroll." |
The patch does resize a (child) window to the size of its content, as with a normal window. There IS a problem I've just spotted though. The child window does get a scrollbar (if it exceeds the display height, though this should really be the parent window height), or you can use the no-scrollbar flag and it does the right thing there too. But in both cases, the parent window's scroll area is definitely confused. |
I'll have to have a look at the cases you described because I'm not sure to understand. Anyway if you are using it for the purpose of layout, I guess we need to add more complete layout features. Something like BeginGroup / EndGroup? (not sure of the name)
But apart from the bad name ("group" probably not what we are looking for) the problem is that I need to tackle better layout features - also see #97 - as a whole, so a single pair of function calls may be too short-sighted at the moment. |
If the only thing you are using it for is to use SameLine between those childs I can possibly come up with functions to do it neatly, at the risk that the functions may be replaced later on. |
Thanks, so really I want it for two things:
|
The BeginGroup/EndGroup you describe, I think, would totally suit my desires (and more :)). |
OK it looks like I can add this regardless of the features discussed in topic 97. |
That sounds great, I'm using GetItemBoxMin/Max for this already. (GetCursorPos() does sound wiser.) |
Working on this but it's raising another (tricky) issue with the vertical alignment of text blocks that I need to fix prior hand. |
Cool - cheers. |
…arious sizes. Added demos. Toward #160 Also fixed LabelText() height.
Works well - thanks! |
...ild windows.
This appears to do the right thing in my testing, and has no impact on paths where the flag is not set.