Immediate-Mode-UI
Docs Update, Align for toggle widgets and nk_layout_space goodies
Hello, this PR is 3 parts.
The first one is a update to docs which seem to not have been updated in a while and i fixed a few typos. Ready to merge.
The second commit adds the possibility to align toggle widgets for consistent ui purposes, see:
I decided to make wrapper functions for the old non aligned calls to keep compatibility, but if you (anyone seeing this) would prefer to not have non-aligned functions, i am open to do it that way do and fixing up all calls all over the project folder. Otherwise mergeable.
The third commit are helper functions to determine how big an allocated nk_layout_space(NK_DYNAMIC/NK_STATIC) is (nk_layout_subspace_bounds) and much of a nk_layout_space(NK_DYNAMIC/NK_STATIC) is left to be used (nk_layout_subspace_remaining). This is useful if you want to stretch a widget over the rest of the nk_layout_space available, see: https://user-images.githubusercontent.com/43303168/138774090-509eae92-eaf6-4e1b-adad-ec149674f741.mp4 However this one is kinda alpha stage and its buggy. nk_layout_subspace_remaining only works after the first row was filled and both functions might miss some padding elimination. I am not yet familiar enough with the inner workings enough to be sure and i hope others can tell me whats missing. This one is not ready to merge.
Have fun testing these changes.
This is YUGE. Would you providing some small example code I could test this out with? Thanks!
From the example:
struct nk_rect total_space = nk_window_get_content_region(ctx);
nk_layout_space_begin(ctx, NK_DYNAMIC, total_space.h, 2147483647);
nk_layout_space_push(ctx, nk_rect(0.0,0.0,0.5,0.6));
if (nk_group_begin(ctx, "SearchResults", NK_WINDOW_BORDER|NK_WINDOW_NO_SCROLLBAR)) {
nk_layout_row_dynamic(ctx, 0, 1);
nk_label(ctx, "...", NK_TEXT_LEFT);
//nk_widget...
nk_group_end(ctx);
}
nk_layout_space_push(ctx, nk_rect(0.5,0.0,0.5,0.6));
if (nk_group_begin(ctx, "SearchOptions", NK_WINDOW_BORDER|NK_WINDOW_NO_SCROLLBAR)) {
nk_layout_row_dynamic(ctx, 0 ,2);
//nk_widget...
//nk_widget...
//nk_widget...
//nk_widget...
struct nk_rect rspace = nk_layout_subspace_remaining(ctx);
nk_layout_row_dynamic(ctx, rspace.h, 1);
nk_button_label(ctx, "This is Yuge");
nk_group_end(ctx);
}
nk_layout_space_end(ctx);
First thanks for the effort - I think it's definitely a valuable approach we should consider for merging in one way or another.
After seeing how the functions are being used in practice I think it's better to deprecate the current versions (i.e. missing the new argument) and in the future have only those with the argument. It's some more clutter but I think it's worth it. Feel free to express your views on this.
On the other hand I'm quite strongly against introducing functions which are known to be buggy despite them offering eagerly sought-after functionality. Could we split this third buggy functionality into a separate PR?
After seeing how the functions are being used in practice I think it's better to deprecate the current versions (i.e. missing the new argument) and in the future have only those with the argument. It's some more clutter but I think it's worth it. Feel free to express your views on this.
I agree, there are a lot of of layout functions but not really useful ones. For example i also thought about adding a "starting point" parameter too. Right now you always go from top left to bottom right, but often it would be useful if you could start from the bottom right for example. I also personally played with the thought of largely rewriting nuklear myself, but right now i lack the time to do it.
On the other hand I'm quite strongly against introducing functions which are known to be buggy despite them offering eagerly sought-after functionality. Could we split this third buggy functionality into a separate PR?
The functionality is not meant to be merged in this state anyway, it was more a request for feedback and help. And i am quite happy people like it. As for merge, you should be able to pull in the 2 commits from the pr and they should disappear from here when i rebase this branch on top of master.
Right now you always go from top left to bottom right, but often it would be useful if you could start from the bottom right for example.
This decision was made at the very beginning and was largely motivated by simplicity it brings. But for mid-complex and highly complex layouts etc. this is very limiting.
I also personally played with the thought of largely rewriting nuklear myself, but right now i lack the time to do it.
That's an interesting point. Then I'd suggest taking a look at Nuklear's "spiritual successor" prototype https://github.com/Immediate-Mode-UI/Quarks from the original Nuklear's author.
Btw. I'd strongly recommend to anyone designing a new UI lib (disregarding whether immediate or retained mode) to do layouting as in https://github.com/Immediate-Mode-UI/layout.c (it's actually accidentally extremely similar to how Flutter does it but much smaller :wink:).
Right now you always go from top left to bottom right, but often it would be useful if you could start from the bottom right for example.
This decision was made at the very beginning and was largely motivated by simplicity it brings. But for mid-complex and highly complex layouts etc. this is very limiting.
I just think its reasonable to suggest that at this point in time it should be redone, with all the knowledge, context and mistakes we are aware of now afterwards. But i personally would like to do that together with the other people using this library and not do a microsoft style EEE plot against the people who maintained it all the years.
I just think its reasonable to suggest that at this point in time it should be redone, with all the knowledge, context and mistakes we are aware of now afterwards. But i personally would like to do that together with the other people using this library and not do a microsoft style EEE plot against the people who maintained it all the years.
I can't speak for others but I won't be able to commit nearly any code due to my job and family. So from my side expect lot's of weird comments & suggestions from time to time :wink:.
Though I'd like to support you in this - if you want, I'll send you an invitation to this org so you can create a new repository and start from there :wink: (it might not be fully immediate mode, but let's discuss it there and not here - I have a few revelations for you :smile:).
Though I'd like to support you in this - if you want, I'll send you an invitation to this org so you can create a new repository and start from there wink (it might not be fully immediate mode, but let's discuss it there and not here - I have a few revelations for you smile).
Sure, i take the invite. And so we can continue this talk in the appropriate place.
Sounds like there's still some updates needed here? Setting it as draft until we're good to go :+1: