The issue was introduced in the fix for 416 (commit 8559aeb).
The original problem was (backspace and arrows moving too fast) is not a
nuklear problem but a GLFW problem. Because of the way nuklear handles
input (it must be between input_begin and end), the key callback method
GLFW offers is not an option.
So we have to use glfwGetKey() which returns the current state of a key
not whether it was just pressed or released, so nuklear acts like it
was pressed every single frame, hence the "too fast" problem.
The fix checks for state change and discards the event if there was
no change. This kills key repeat behavior (for named keys) on
*all* platforms which makes deleting or arrowing inconvenient.
Since there's no way to fix the shortcomings of a callback vs event
based input API, my "fix" just makes the original fix conditional
on a macro NK_KEYSTATE_BASED_INPUT
Copy paste mistake was checking the background type for the cursor style,
leading to a crash if background was image type and cursor was color, as
it would try to use the cursor color as a texture.
Closing a contextual menu by right click caused invalid behavior and
bocking. In addition having consecutive contextual menus and closing an
earlier menu will wrongfully open a following menu. Both are now fixed.
Other parts of the draw_list code simply fail more or less silently when the
buffers fill up. The user could allocate bigger buffers and try again, except
that these particular functions assert when they fail to allocate the buffer.
Nuklear now comes in two flavours. For ones there is the single-header
version for distribution and multiple files inside the /src folder for
development and better readability. Since I don't want to manually
update each version if the other changes the /src directory includes a
python script developed by Apoorva Joshi to pack all files inside the
directory into a single header file.
Previously `nk_clear` with optional vertex output enabled would try and
clear each passed buffer from `nk_convert` if called. Problems arise
if each buffer was specified previously in own code block outside
`nk_clear`.
Overall the buffer clearing was an overreaching measure of `nk_clear`
and I hope not to many tried to make use of it. In general the buffer
is owned by the user of nuklear and not nuklear itself.
Therefore it does not make sense for nuklear to access it after
`nk_convert` was successfully completed.
Sorry for any inconvenience caused by this breaking change.
Opening and closing a set of windows with at least one other window
active caused flickering if a window as closed. Reason was a missing
check inside `nk_build` that did not skip newly closed windows.
I am not 100% sure but this could also affect #637 but I still needs to
be tested.
No idea what happend but for some reason I accidentally removed
`nk_image_color`. I don't think there is any reason why it should have
been removed so I added it back in.
If userdata is used with drawing images userdata was missing from
the first image command and also subsequent commands which draw the
same texture but with different user data were incorrectly merged together.
This modification makes it so the nk_do_property() function uses the user-defined NK_DTOA function instead of the internal nk_dtoa() function, as per the description below "Optional Defines":
NK_DTOA
You can define this to `dtoa` or your own double to string conversion
implementation replacement. If not defined nuklear will use its own
imprecise and possibly unsafe version (does not handle nan or infinity!).
<!> If used it is only required to be defined for the implementation part <!>
Keep up the great work on Nuklear, really enjoying it so far!
I think this adds more clarity to the library. I.e. that it is organized into 2 large #define statements. The first large statement (`NK_NUKLEAR_H_`) has a comment for it's closing `#endif` statement. The second one (`NK_IMPLEMENTATION`) does not.
Since directly modifing window position and size between function calls
nk_begin and nk_end causes drawing errors it is now required to be set
_OUTSIDE_. For that reason each modifing function now takes in the name
of the window to modify. Sorry for the inconvenience.
The window background flags was pretty much broken at this point. It
would completly block all input for each window. The fix itself is quite
dirty but hopefully everything works correctly now.
Single line comment are a feature of C++ and C99 and above while C89 only
supports multiline comment /**/. In addition I added an additional
reference for the addition and subtraction formulae.
Change nk_draw_list_path_arc_to so that it calls sin and cos 4 times
instead of (segments * 2) times. This is achieved through the use of
the trigonometric angle addition identities.
From now on internally nuklear will keep a minimum row height that is
derived from currently select font. If you want to have a row smaller
than that you can call `nk_layout_set_min_row_height` and reset the
value back by calling `nk_layout_reset_min_row_height`.
Fixes issue with uninitialised memory. Didn't move the memset call into
nk_textedit_clear_state because that function is used elsewhere, and you
don't always want to completely clear the struct when you call it.
Add NK_INCLUDE_SOFTWARE_FONT to allow font generation without
the need to have vertexbuffers.
Required for software rasterization.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Had to change some small things to make everything work for a
general case instead of vertex draw list only. Furthermore I
don't want a custom widget inside nuklear so I removed it.
Feel free to add it back into your own version.
Added a new command type 'NK_COMMAND_CUSTOM'.
A custom command contains a callback that will be called to fill the draw list.
Usage:
static void custom_convert(struct nk_draw_list *list,
short x, short y, unsigned short w, unsigned short h,
nk_handle callback_data){/*Fill draw list.*/}
[...]nk_begin[...]
nk_custom(ctx, customConvert, nk_handle_id(0));
The handle can be used to pass data.
These warnings appear on GCC for Windows only. There a lot of them. Doesn't matter, native compilation or crosscompile.
`nuklear.h:6836:9: warning: this decimal constant is unsigned only in ISO C90`
There is function `NK_INTERN int nk_to_upper(int c)` in `UTIL` section. Implementation is almost the same to `NK_INTERN int nk_to_lower(int c)`. But only `nk_to_lower` used in Nuklear's code. To remove this warning we can:
1) Comment i.e. remove `nk_to_upper` from code. But it can break someone's code, if he used it in module with `NK_IMPLEMENTATION` defined.
2) Hide it under define. Same.
3) Just use it somewhere in code.
I replaced two calls of `nk_to_lower` to `nk_to_upper`. It removes the warning, code works the same. The bad side - complication of the code. "Why `nk_to_upper` is used here, but not `nk_to_lower` as one line up?"
Maybe there exists better solution? Or just add the comment about this line to code?
When NDEBUG defined:
nuklear.h: In function 'nk_popup_begin':
nuklear.h:20753:22: warning: variable 'panel' set but not used [-Wunused-but-set-variable]
nuklear.h: In function 'nk_nonblock_begin':
nuklear.h:20850:22: warning: variable 'panel' set but not used [-Wunused-but-set-variable]
Robert Winkler