- Be consistent about reading and writing pixel values to avoid casting/offset madness
- clean up function names for clarity/consistency
- Fix fence post errors preventing get/set pixels from operating on first row/column
- Enforce mutual exclusivity for pixel layout macros
If XftDrawString8() is given non-ASCII UTF-8 string it fails to properly render it.
Using XftDrawStringUtf8() instead seems to be doing the right thing.
Signed-off-by: Sergiy Kibrik <sakib@darkstar.site>
Like these:
main.c: In function ‘main’:
main.c:234:20: error: ‘ctx’ undeclared (first use in this function)
overview(ctx);
^
Signed-off-by: Sergiy Kibrik <sakib@darkstar.site>
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
This implements the GDI Rect Multicolor functions. This will work without
any problems when targetting Windows 2000 and up.
TODO: Fix Alpha blending. The Color Matrix does not render correctly.
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.
Use the framebuffer pitch to calculate the correct offset.
Fixes garbled rendering on framebuffer that have
pitch != x_resolution * bpp / 8.
The demo application is unaffected as the pitch always aligns with
the x resolution of the window.
Signed-off-by: Patrick Rudolph <siro@das-labor.org>