Window bounds about nuklear

[dumblob]

Is there a way to clamp scalable nk windows between a minimum and maximum size?

I'm not sure - clamping is used in "containers" (e.g. long lists embedded e.g. in a box/window/...) and for the whole canvas/screen. Not sure exactly what you mean by clamping to a predefined size - you'd loose some content of the window, which doesn't sound right to me (but of course, there might be some use case we didn't think about).

Also, I found that if you close your main window, it clears the vbo to 0 (expected), but then it resets it?

Can't give any better answer then recommending reading the source 😉.

[Nielsbishere]

I meant clamping as in that the outer bounds of the window are between a range. So you can set a minimum or maximum like in qt.
I read almost all documentation afaik, is it in the code then?

[dumblob]

I meant clamping as in that the outer bounds of the window are between a range. So you can set a minimum or maximum like in qt.

Do you mean as a reaction e.g. to user input (e.g. dragging the window corner)? That's dead simple - before calling the nuklear nk_input... functions, you'll check, whether your preferred bounds would be crossed or not and only call the nk_input... functions if the bounds won't be crossed. It's this easy due to the per-frame nature of immediate mode UIs (including Nuklear).

[Nielsbishere]

My point is that that might be handy to be built in. Because otherwise I'd have to do a lot of manual checks for which window

[dumblob]

My point is that that might be handy to be built in. Because otherwise I'd have to do a lot of manual checks for which window

If you wanted to constrain each window separately to the very same region, then what prevents you to use the canvas size (i.e. instance of Nuklear ctx structure) of that size in the first place?

If you want to constrain each window to a different region, then the code size for these checks is the same (or I would bet smaller) than in case of Qt 😉. Though I still don't fully understand the motivation why would anyone wanted to do that 😕 - if I understood it better, then I might give you better pointers how to approach that.

[Nielsbishere]

Well a window always has a minimum size of where things would become unusable, so it would be handy to disallow that from happening without having to intervene the input from arriving at nuklear; e.g. by setting a minimum constraint on that window. Maximum would be the same idea; where things would stretch too much

[dumblob]

Well a window always has a minimum size of where things would become unusable, so it would be handy to disallow that from happening without having to intervene the input from arriving at nuklear; e.g. by setting a minimum constraint on that window. Maximum would be the same idea; where things would stretch too much

Now I finally understood what you want/need 😉. This is usually handled by layouting. Layuting in Nuklear is very basic and exactly this type of min/max size constraints would require advanced layouting support which is not available. On the other hand, it's quite easy to compute the sum of dimensions of your widgets yourself (there are reports from Nuklear users in the old issue tracker who did it quite thoroughly) and then use them for alignment etc. and also e.g. for this min/max constraint.

For advanced layouting, there are several/many proposals and approaches - see e.g. Amoeba (Cassowary algorithm), layout.c (proof of concept general layouting acting as generalized backend of Web CSS), layouting using groups, and many ideas in the old threads 1, 2, 3, ...

From my experience one benefits from using this min/max constraint quite rarely - what is you particular use case (which platform, which backend, what type of app and widgets)? I expect there are easier solutions to your problem than using this min/max constraint.

[Nielsbishere]

Well it would be nice to have for a lot of things like scalable windows, so users can't physically make them smaller than a limit defined by the window/layout or bigger than the max. This doesn't just have to be calculated though, even allowing the programmer to set their own min/max through nuklear would be nice.

[dumblob]

I understand the effects of such change. I'm just still missing the real world motivation (use case). Could you describe your use case in detail? Then we can do something about it instead of patching hundreds of lines of Nuklear layouting.

[Nielsbishere]

For example; I have an old app I want to port over from Qt to Nuklear (since it is easier to do cross platform with nuklear). This app has multiple widgets that are stitched together and dragging the left widget also changes layouts in other windows (ala QHBoxLayout & QVBoxLayout this is something I could make myself) and these windows also have minimum and maximum size, so I could adapt other windows based on that. Like a file system where the rows of the explorer have a minimum length and a maximum length, so you don't drag them to be unreadable or too big.

[Nielsbishere]

@dumblob how would I handle min/max window bounds? If I put it in my application by clamping the current nk_window's bounds it is very janky and has a few frames where the window doesn't look correct.