I want application window to be scaled with UI updating.
Currently I have to do weird math to set size of ScrollView, which is
really looks hacky at best.
Ideally I want it so that I do not have to manually fixup things.
Basically this means ScrollView is automatially filling its parent in
the same way as other UI elements do. So if I have LM_VERTICAL parent
with 5 elements, 4 buttons and 1 ScrollView I should not need to
handle ScrollView specially for it to behave like buttons
(filling 1/5 of parent vertically and 100% horizontally), so for it to
have intuitive behavior.
If that is not possible, this should be documented among with widget
list which need special handling and what that special handling is to
make it standard. This is worst feeling - not intuitive behavior and
nowhere to go for information.
Meh… basically, Editor Hierarchy window is ScrollView plus some buttons. AFAIK it works automatically in some way, no?
If you set min/max size to 0/inf, ScrollViewmust automatically scale when parent has non-free layout.
Well, the observed behavior is inconsistent with other elements.
Why min/max values are set to 0 for ScrollView?
Why difference with other elements?
Either way thanks for help - I’m not trying to make you fix it or something,
I don’t think anything really can be done here in current circumstances.
I was just curious. Will try to use @Sinoid approach to imgui for node editor and will look for some other solution for in-game UI.
Well, but ScrollView gets size of 0x0 unlike other elements. I think it should get size required by parent container element, as if it was button or other element. It is not logical to set it to 0x0. Also I think Urho UI is too verbose with settings and lacks defaults.
i.e. for Button one have to SetLayout(), SetStyle/SetStyleAuto(), etc. which have to be always present. In most GUI toolkit you create container, put widgets in it and you have something working immediately. In Urho UI code looks very verbose and too much code for what it does. I do overcome this using fancy functions, but I think there is something which needs to be done there… At least for SetLayout()/SetStyle() stuff.
However, Window is always squashed to min size by default, so objects with zero height would be invisible.
There is logic.
Take as little space as possible, but not less than minimum required.
If size is greater than minimum, stretch everything equally, but no more than allowed by element restriction.
It (ImGui) allows for lighter/easier node editor than with stock UI
which is very serious plus for me. It also looks like it is more
predictable regarding what goes where, but I did not dig it seriously
(except for node editor capabilities). I will of course check its
but it seems to be able to create scalable/resizeable UIs, as I see