GUI on Linux: problems with updating

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, ScrollView must 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.

Min/max sizes are defaulted to 0/inf for UIElement and its descendants.
So, each UI element will always fill parent with non-free layout till the borders (by default).

Text, on the other hand, automatically sets min width (to avoid unwanted text clipping) and also set fixed height (to maintain contant line height)

Then, every element with non-free layout can’t be less than its children. So, Button with text has restricted min size (inherited from underlying Text) and unrestricted max size.

So, if you make vertical Window and put there Button with Text and ScrollView w/o any settings, they would fill the window 1/1 unless you squash it.

Note that ScrollView breaks this chain of size inheriting. Sizes of inner elements doesn’t affect size of host ScrollView in any way.

Such kind of issues means either bug or lack of docs. Nice chance to shoot it down.

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.

Default ScrollView takes exactly the same amout of space as other stretchable things.

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.

ImGui isn’t going to do you any favors for layout. It’ll probably just make it an exponentially larger headache. The paradigm sucks at layout.

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
usability,
but it seems to be able to create scalable/resizeable UIs, as I see
its applications.