Skip to content

Conversation

@Nielsbishere
Copy link
Contributor

Multiple PRs:

Various changes such as:

  • Fixing clicking through multiple overlapping windows
  • Allowing subpixel rendering
  • Allowing add_window to return a Window pointer to read out information useful to an abstraction that isn't immediate mode over nuklear.
  • Fixed radio buttons style
  • Fixed compile issues with C++17 (-Werr -W3)
  • Trees can now have 'child' nodes, which are supposed to be the final stop for childless nodes. This isn't fully true, but it can be used to have another tree node type. It doesn't have a symbol as a file should as opposed to a folder.

itsuhane and others added 30 commits June 16, 2019 15:19
… for vertices (they check correctly now).

Paq.sh now automatically outputs to nuklear.h.
keharriso's Prevent clicking more than one (overlapping) button per frame.
However, this has a couple of other changes that should fix dropdowns from intefering as well.
- Sets click to 0 every start of frame
- Input was still down for that frame, so it triggered the next event
Now it waits for your button to go back up before resetting the clicked variable, so as long as your mouse is down, only one item is clicked.
…checkbox!

With README changes that show off more features and the updated style. Slightly modified.
@Nielsbishere Nielsbishere changed the title Feature subpixel api v 4.04.0: Multiple PRs merged Jul 6, 2020
@RobLoach
Copy link
Contributor

Looks like there's a few git conflicts 👀

@dumblob
Copy link
Member

dumblob commented Dec 14, 2021

I'm sorry for us not getting earlier to this. I think this PR is quite valuable and was a lot of work to put it all together. We should merge (parts of?) it after a thorough review. Would anyone be willing to update it to fix the merge conflicts? I'm constantly fighting my tighter and tighter schedule...

@Nielsbishere Nielsbishere changed the title v 4.04.0: Multiple PRs merged v 4.10.0: Multiple PRs merged Dec 15, 2021
@Nielsbishere
Copy link
Contributor Author

There we go

@dumblob
Copy link
Member

dumblob commented Dec 15, 2021

I've skimmed it (really no review yet) and it actually looks surprisingly good to me. @RobLoach could you please thoroughly review it? @Hejsil would you also find some time to take a look at this rather sensitive PR? The more eyes the better.

Copy link
Contributor

@Hejsil Hejsil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried, but it is very hard to review this as I have to context switch all the time to figure out what each change relates to. I would personally prefer we don't do these "merge 5 things together" pull requests for a few reasons:

  • It's very hard to review
  • The git history is a mess, and doing a "Squash and Merge" is not really a good idea as we want multiple commits, one for each fix/feature.
  • Change log for this version is a bit of a mess. I would rather we have patch and minor bumps have just one thing they do. Major bumps can be a mess.

Comment on lines +2317 to 2329
- 2020/07/06 (4.04.0) - Added subpixel API from itsuhane. Allowing you to turn on
NK_ENABLE_SUBPIXEL_API to position window and elements in subpixels
Changed nk_begin to return a nk_window so you can get the position and other useful info.
Fixed radio buttons' style.
Fixed click cascading through multiple buttons; it should only click the upper button.
Strict c++17 now compiles: only declaring memset, memcpy if they are used.
Only asserting index range if ushorts are used for indices.
Made paq.sh identical to paq.bat (outputs to nuklear.h).
Replaced NK_ASSERT(0 && ...) with NK_ERROR(), to ensure it compiles on strict C++17.
Replaced const char** by const char * const * in combobox, to ensure const List<const char*> can be used.
Added nk_tree_type for allowing the symbol next to a tree element to be hidden (for children) if it's not an image.
- 2020/04/09 (4.02.1) - Removed unused nk_sqrt function to fix compiler warnings
- Fixed compiler warnings if you bring your own methods for
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. The versioning in here seems quite out of date

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'll fix the versioning after we finally know which of the (many) other PRs get merged first.


```c
/* init gui state */
struct nk_context ctx;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure why we are updating the example in the readme. IMO readme examples should be very small and give the reader a taste of how nuklear is to use. Not sure this update really makes it any better

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It shows elements of nuklear that are often going to be used in applications, but I guess it's preference

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I usually tend to prefer readme examples to be very small. In our case we're pretty much covered by everything in example/ directory. So here I won't advocate for extending the current example.

I'm though fine with extending if it's just about 1-5 SLOC which add and I quote "often used elements". That's not the current case though.

"src": [
"nuklear.h"
]
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not change the formatting of the clib.json. Only bump the version

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason? To me it seems easier to read this way

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm indifferent here. But generally speaking if such changes shall further extend big PRs I'd beg everyone to leave them out for the sake of clarity.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would personally also like it to be formatted this way, as then it would be inline with my json formatter (4 spaces would be nice too). If enough people agree, then sure we can change it, but I don't want to end up en a situation where we change the clib.json format in every PR, if you know what I mean :)

@@ -1,4 +1,4 @@
<meta charset='utf-8' emacsmode='-*- markdown -*-'>
<meta charset='utf-8' emacsmode='-*- markdown -*-'>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What changed on this line?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unsure, hopefully not line endings

}
NK_API int
nk_combo_callback(struct nk_context *ctx, void(*item_getter)(void*, int, const char**),
nk_combo_callback(struct nk_context *ctx, void(*item_getter)(void*, int, const char* const *),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure this is a breaking change as old void (*)(void *, int, const char**) functions passed here will now be a compiler error.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's right, but that's why there's a major bump and not a minor one. If this change isn't enforced then it won't work for some cases.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bumping to 4.10 is a minor bump. We would need a 5.0 to be a major one.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is actually no major bump (only minor) in this PR as of now 😢.

But more importantly I'd definitely prefer if major bumping features (i.e. those affecting backwards compatibility) were in a separate PR. It's true that this PR is quite convoluted though I think I'd merge it after it passes our review. But the split due to a major bump is something important for several other reasons (one of which is release engineering).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Hejsil my bad, it's major.minor.bugfix? Then I might have to bump it

NK_API void
nk_combobox_callback(struct nk_context *ctx,
void(*item_getter)(void* data, int id, const char **out_text),
void(*item_getter)(void* data, int id, const char * const *out_text),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

Comment on lines +561 to +580
NK_API void
nk_push_scissor_subpixel(struct nk_command_buffer *b, struct nk_rect r)
{
struct nk_command_scissor *cmd;
NK_ASSERT(b);
if (!b) return;

b->clip.x = r.x;
b->clip.y = r.y;
b->clip.w = r.w;
b->clip.h = r.h;
cmd = (struct nk_command_scissor*)
nk_command_buffer_push(b, NK_COMMAND_SCISSOR, sizeof(*cmd));

if (!cmd) return;
cmd->x = r.x;
cmd->y = r.y;
cmd->w = NK_MAX(0, r.w);
cmd->h = NK_MAX(0, r.h);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are a lot of these new subpixel apis that are just copies of the original but without the casts to short. Their signature are the same, so should nk_push_scissor just support subpixels if enabled instead of having two functions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this was a bad auto merge or for backwards compatibility.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so should nk_push_scissor just support subpixels if enabled instead of having two functions?

Interesting idea. I think it's worth exploring. @Nielsbishere would you find some time to try to rewrite this PR to see if it solves some of the issues we have here and if it makes the PR leaner?

Comment on lines +493 to +495
tab->sym_minimize = NK_SYMBOL_PLUS;
tab->sym_maximize = NK_SYMBOL_MINUS;
tab->sym_child = NK_SYMBOL_NONE;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a breaking change visually for people who use the default style

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally I'm indifferent on this one. A quick google search seems to suggest that triangles are a tiny bit more modern than + - though. So I think this can be left out of this big PR.

Comment on lines +10 to +11
nk_toggle_behavior(struct nk_input *in, struct nk_rect select,
nk_flags *state, int active)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure this should be a bool and not an int

Comment on lines +3 to +11
rm ../nuklear.h

python3 build.py --macro NK --intro HEADER --pub nuklear.h --priv1 nuklear_internal.h,nuklear_math.c,nuklear_util.c,nuklear_color.c,nuklear_utf8.c,nuklear_buffer.c,nuklear_string.c,nuklear_draw.c,nuklear_vertex.c --extern stb_rect_pack.h,stb_truetype.h --priv2 nuklear_font.c,nuklear_input.c,nuklear_style.c,nuklear_context.c,nuklear_pool.c,nuklear_page_element.c,nuklear_table.c,nuklear_panel.c,nuklear_window.c,nuklear_popup.c,nuklear_contextual.c,nuklear_menu.c,nuklear_layout.c,nuklear_tree.c,nuklear_group.c,nuklear_list_view.c,nuklear_widget.c,nuklear_text.c,nuklear_image.c,nuklear_9slice.c,nuklear_button.c,nuklear_toggle.c,nuklear_selectable.c,nuklear_slider.c,nuklear_progress.c,nuklear_scrollbar.c,nuklear_text_editor.c,nuklear_edit.c,nuklear_property.c,nuklear_chart.c,nuklear_color_picker.c,nuklear_combo.c,nuklear_tooltip.c --outro LICENSE,CHANGELOG,CREDITS > ../nuklear.h

if [ -s ../nuklear.h ] ; then
echo -- nulear exported
else
echo -- nuklear export failed
fi
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When would this script fail, so that we would need these error messages? Also, I think these messages should be emitted by build.py instead of here

Copy link
Contributor Author

@Nielsbishere Nielsbishere Dec 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If python3 is not installed (or if the build script fails)

Copy link
Member

@dumblob dumblob Dec 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally I think the only potentially valuable change to paq.sh could be to print an error message in case of a failure. But only in that case and it has to be to stderr. I.e.:

#!/bin/sh

set -e

python build.py --macro NK --intro HEADER --pub nuklear.h --priv1 nuklear_internal.h,nuklear_math.c,nuklear_util.c,nuklear_color.c,nuklear_utf8.c,nuklear_buffer.c,nuklear_string.c,nuklear_draw.c,nuklear_vertex.c --extern stb_rect_pack.h,stb_truetype.h --priv2 nuklear_font.c,nuklear_input.c,nuklear_style.c,nuklear_context.c,nuklear_pool.c,nuklear_page_element.c,nuklear_table.c,nuklear_panel.c,nuklear_window.c,nuklear_popup.c,nuklear_contextual.c,nuklear_menu.c,nuklear_layout.c,nuklear_tree.c,nuklear_group.c,nuklear_list_view.c,nuklear_widget.c,nuklear_text.c,nuklear_image.c,nuklear_9slice.c,nuklear_button.c,nuklear_toggle.c,nuklear_selectable.c,nuklear_slider.c,nuklear_progress.c,nuklear_scrollbar.c,nuklear_text_editor.c,nuklear_edit.c,nuklear_property.c,nuklear_chart.c,nuklear_color_picker.c,nuklear_combo.c,nuklear_tooltip.c --outro LICENSE,CHANGELOG,CREDITS > ../nuklear.h || {
    ret=$?
    printf 'ERR nuklear.h wrongly generated (or not generated at all)\n' >&2
    exit $ret
}

(and if others will approve any such adjustments, then paq.bat also has to be adjusted to behave identically!)

@Nielsbishere
Copy link
Contributor Author

@Hejsil I agree, but it was requested I merge this a long time ago iirc.

@dumblob
Copy link
Member

dumblob commented Dec 16, 2021

@Nielsbishere yep, we thought that merging small changes will make it more appropriate. As it turns out, not all the changes are as small as anticipated. Do you think you could help us with splitting the PR (at least the major bump versus other changes) and cleaning it as discussed above?

@aganm
Copy link
Contributor

aganm commented Dec 25, 2021

I double checked this branch to see if all works well in case it ends up being pulled in. There's only one thing that bugs me, I'm not sure if it's on purpose but the color picker widget isn't following my mouse cursor anymore.

You see when I click, I'm holding the mouse, but the color cursor isn't following the mouse cursor:
GIF 12-24-2021 9-35-00 PM

This is the expected behaviour:
GIF 12-24-2021 9-36-15 PM

@Nielsbishere
Copy link
Contributor Author

Oh yeah I will get to this PR in a bit, just busy.
@aganm I'm guessing the event is being consumed before it reaches it for some reason.
@dumblob I think I should probably apply those fixes. I'm not sure how to split it in different branches without rewriting it.

@dumblob
Copy link
Member

dumblob commented Dec 28, 2021

@aganm thanks for the quick test! That's very important to do. Feel free to continue your endeavor if you find some time for it. We'll be thankful for that!

@dumblob I think I should probably apply those fixes. I'm not sure how to split it in different branches without rewriting it.

Yeah, different fixes will be necessary. Regarding splitting, what do you mean by "rewriting it"? Just take few related commits into a separate branch and then consolidate the result with one new commit in that new branch (fixing the discrepancies which are to be expected). Do this until you run out of all the commits from this PR 😉. This PR will then get closed as superseeded by all the new PRs (for each new branch). Sounds tedious but in this case it's really valuable and we'll be greateful if you managed. Take your time.

Thanks!

@mecwerks
Copy link

mecwerks commented Nov 22, 2022

I double checked this branch to see if all works well in case it ends up being pulled in. There's only one thing that bugs me, I'm not sure if it's on purpose but the color picker widget isn't following my mouse cursor anymore.

Found a fix that worked for me. I'm not sure what else this may affect but it seemed to retain the click through fix

diff --git a/src/nuklear_input.c b/src/nuklear_input.c
index 6bcb97d..a8f5e05 100644
--- a/src/nuklear_input.c
+++ b/src/nuklear_input.c
@@ -154,7 +154,7 @@ nk_input_has_mouse_click_in_rect(const struct nk_input *i, enum nk_buttons id,
     struct nk_rect b)
 {
     const struct nk_mouse_button *btn;
-    if (!i || i->mouse.clicked) return nk_false;
+    if (!i) return nk_false;
     btn = &i->mouse.buttons[id];
     if (!NK_INBOX(btn->clicked_pos.x,btn->clicked_pos.y,b.x,b.y,b.w,b.h))
         return nk_false;

@aganm
Copy link
Contributor

aganm commented Nov 22, 2022

@mecwerks Thanks for that, I have looked into it and this change comes from commit

8e89387 Merge branch 'fix_click' of https://github.com/Nielsbishere/Nuklear into fix_radio_buttons

It seems like the reason for this change was to fix click related to radio buttons, but, I have tested your proposed fix and it seems to work, both color pickers and radio buttons seem to work perfectly with this fix!

Fix which is a revert of this one specific line

if (!i || i->mouse.clicked) return nk_false;

back to what it was before this PR
if (!i) return nk_false;

With this fix I would be happy if we could merge this PR.

@Nielsbishere
Copy link
Contributor Author

Oh hey it's my old branch. @aganm @mecwerks the reason for this change was quite important; if you have a dropdown window over a radio button, it'll push through the window into the radio button. The proper fix would be to figure out why the color picker has this behavior. Maybe this check is in the wrong place; preventing that behavior? But letting the radio button be clicked while the input event is already consumed is not good imo

@aganm
Copy link
Contributor

aganm commented Nov 22, 2022

Oh hey it's my old branch. @aganm @mecwerks the reason for this change was quite important; if you have a dropdown window over a radio button, it'll push through the window into the radio button. The proper fix would be to figure out why the color picker has this behavior. Maybe this check is in the wrong place; preventing that behavior? But letting the radio button be clicked while the input event is already consumed is not good imo

It seems both color picker and radio button rely on the same underlying nk_button_behavior function. But the difference is that the radio button calls nk_button_behavior with a behavior parameter of NK_BUTTON_DEFAULT and the color picker calls nk_button_behavior with a behavior parameter of NK_BUTTON_REPEATED. The function nk_button_behavior seems to not handle the repeated mode correctly.

@Nielsbishere
Copy link
Contributor Author

@aganm sounds like a solution is to only check if it's not repeated then. I'm not continuing this branch as my current project doesn't use it. Maybe if I ever use it again, but I don't have any time left to do this rn

@RobLoach
Copy link
Contributor

RobLoach commented Nov 4, 2025

3 years 😉 Thanks for your push on this. Are there any individual PRs you believe we should bring in? A large change like this can be difficult to review, as demonstrated. Smaller code changes are easier to bring in.

@Nielsbishere
Copy link
Contributor Author

yeah I was going through my open PRs and noticed this was still open. I'm not sure what happened since then in terms of development, but the original was smaller PRs and was asked to be merged into one bigger PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants