All of the glfw demo headers unset shift keypresses when the ctrl key is not
also down.
I can't think of a reason this would be desired and it appears no other demo
code does this.
Unless I'm mistaken, simply removing these lines leaves us with the desired
behaviour.
This resolves a false UBSan trip caused by treating the element offset
in `glDrawElements` as a pointer
This parameter is effectively an offset but is taken as a `void*`
By not storing the offset as a pointer, UBSan no longer tools the offset
to check for null pointer overflow
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
I simplified a lot of API calls by pulling panel memory management
inside the library. All API calls which previously required a panel
as parameter are now handling their panel themself.
I removed the default vertex type and instead create an API to allow the
user to specify the vertex struct layout. Of course you are still
bound on what the library actual has on vertex data but the type and
sequence of the data is now configurable. This commit is quite
experiental and could introduce some bugs, but so far it look fine.
Nuklear now has three different property versions for int, float and
added by this commit a double version. Internally an additional change
happend. Now the type of the property is actually taken into account
and floating pointer errors due to casting are less of an issue.
Previously I packed standard library variable arguments as well as
file operation into one define `NK_INCLUDE_STANDARD_IO`. This caused
some problems and I split the define into two. So if you want the old
behavior you need to define `NK_INCLUDE_STANDARD_IO` as well as
`NK_INCLUDE_STANDARD_VARARGS`. If you only want file operations but
not variable arguments only define `NK_INCLUDE_STANDARD_IO` and
if you only want varargs but not file operations please only define
`NK_INCLUDE_STANDARD_VARARGS`.
Rob Loach