keharriso / love-nuklear Goto Github PK

Text wrapping doesn't seem to work with new lines. Text is on top of other text.

if nk.windowBegin('Overview', 0, 00, 800, 600) then
    nk.layoutRow('dynamic', 30, 1)
    nk.label("Current FPS: "..tostring(love.timer.getFPS( )))
    nk.layoutRow('dynamic', 500, 1)
    nk.label('In the year 1878 I took my degree of Doctor of Medicine of the University of London, and proceeded to Netley to go through the course prescribed for surgeons in the army. Having completed my studies there, I was duly attached to the Fifth Northumberland Fusiliers as Assistant Surgeon. The regiment was stationed in \nIndia at the time, and before I could join it, the second Afghan war had broken out. On landing at Bombay, I learned that my corps had advanced through the passes, and was already deep in the enemy\'s country. I followed, however, with many other officers who were in the same situation as myself, and succeeded in reaching Candahar in safety, where I found my regiment, and at once entered upon my new duties.', 'wrap')
end
nk.windowEnd()

It seems like this binding is missing a chunk of the nk API. In attempting to mirror nuklear's node editor demo, I've noticed the following missing functions in this binding:

/* shape outlines */
NK_API void nk_stroke_line(struct nk_command_buffer *b, float x0, float y0, float x1, float y1, float line_thickness, struct nk_color);
NK_API void nk_stroke_curve(struct nk_command_buffer*, float, float, float, float, float, float, float, float, float line_thickness, struct nk_color);
NK_API void nk_stroke_rect(struct nk_command_buffer*, struct nk_rect, float rounding, float line_thickness, struct nk_color);
NK_API void nk_stroke_circle(struct nk_command_buffer*, struct nk_rect, float line_thickness, struct nk_color);
NK_API void nk_stroke_arc(struct nk_command_buffer*, float cx, float cy, float radius, float a_min, float a_max, float line_thickness, struct nk_color);
NK_API void nk_stroke_triangle(struct nk_command_buffer*, float, float, float, float, float, float, float line_thichness, struct nk_color);
NK_API void nk_stroke_polyline(struct nk_command_buffer*, float *points, int point_count, float line_thickness, struct nk_color col);
NK_API void nk_stroke_polygon(struct nk_command_buffer*, float*, int point_count, float line_thickness, struct nk_color);

/* filled shades */
NK_API void nk_fill_rect(struct nk_command_buffer*, struct nk_rect, float rounding, struct nk_color);
NK_API void nk_fill_rect_multi_color(struct nk_command_buffer*, struct nk_rect, struct nk_color left, struct nk_color top, struct nk_color right, struct nk_color bottom);
NK_API void nk_fill_circle(struct nk_command_buffer*, struct nk_rect, struct nk_color);
NK_API void nk_fill_arc(struct nk_command_buffer*, float cx, float cy, float radius, float a_min, float a_max, struct nk_color);
NK_API void nk_fill_triangle(struct nk_command_buffer*, float x0, float y0, float x1, float y1, float x2, float y2, struct nk_color);
NK_API void nk_fill_polygon(struct nk_command_buffer*, float*, int point_count, struct nk_color);

Would it be possible to implement these as a wrapper for love's own functions?

Doesn't seem I can copy and paste from the edit box.

Hello,
please change line 67 of overview.lua from
nk.slider(0, slider, 1, 0.05)
to
nk.slider(1, slider, 8, 1)
and try moving the slider.... sometimes it works, sometimes not !?!?!

Franc

Color values in the most recent version of Love2d have been changed from 0-255 to 0.0-1.0 and are now percentage based. This results in everything that is drawn to the screen being white because any value over 1 is basically 255 now.

Currently, love-nuklear does not support quads. Quads are necessary for developers that package sprites into sprite atlases. Given that textures are going to be batched automatically, it is possible that more developers are going to shift to using sprite atlases (and therefore quads) in the future.

So this works:

['property'] = {     
	['label normal'] = '#241414',
	['label hover'] = '#241414',
	['label active'] = '#241414',
},

and this does not:

['property'] = {     
	['normal'] = '#241414',   
	['label normal'] = '#241414',
	['label hover'] = '#241414',
	['label active'] = '#241414',
},

The result is a half broken skin, with some f the default values set and others taken from the skin

Great library!
I would be nice to have some precompiled binaries though. That way you could start immediately

Having a scrollable list that I can easily add remove items from is vital for me (want to make a turn based strategy game with lots of menus).

Hello,

there is a difference between docu and source between windowIsAnyHovered and windowsIsAnyHovered.

I think it should be windowIsAnyHovered (without 's') for both.

Franc

Error: error loading module 'lib.nuklear' from file '.\lib\nuklear.dll':
        The specified procedure could not be found.

stack traceback:
        [string "boot.lua"]:637: in function <[string "boot.lua"]:633>
        [C]: at 0x7ff9a4486130
        [C]: in function 'require'
        main.lua:6: in main chunk
        [C]: in function 'require'
        [string "boot.lua"]:475: in function <[string "boot.lua"]:311>
        [C]: in function 'xpcall'
        [string "boot.lua"]:645: in function <[string "boot.lua"]:639>
        [C]: in function 'xpcall'

This is 64 bit version, no build straight from latest release.

This looks darker than what I see the screenshots of original nuklear.

Other widgets have correct shading.

This is not a real issue, but more of an enhancement.
It would be great if the repo would provide a more detailed instruction to building love-nuklear. I at least couldn't reproduce the builds with the steps provided. But of course this is not a love-nuklear issue, more so one of the developer, but it would be nice to have it either way.

Following the build instructions on linux, using cmake gives the error. I've tried versions 2.5-2.6 and each version had the same issue.

CMake Error at CMakeLists.txt:9 (ADD_LIBRARY):
  Cannot find source file:

    src/nuklear/nuklear.h

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx


CMake Error at CMakeLists.txt:9 (ADD_LIBRARY):

While this is definitely a great Lua binding for nuklear, it does feel a bit thin. I wonder if it would be possible to design an API that feels more like a love module than a C wrapper?

I'm getting a segfault when running the examples. I tracked the problem down to layoutTemplatePush.

Minimal code to reproduce the issue:

local nuklear = require 'nuklear'
local ui = nuklear.newUI()

function love.update(dt)
	ui:frameBegin()
	if ui:windowBegin('segfaults', 200, 100, 300, 200) then
		ui:layoutTemplateBegin(40)
		ui:layoutTemplatePush('static', 75) -- [1]
		ui:layoutTemplatePush('static', 75) -- [2]
		ui:layoutTemplateEnd()
	end
	ui:windowEnd()
	ui:frameEnd()
end

function love.draw()
	ui:draw()
end

Running this code: (ignore the socket and jack errors, they are not relevant)

$ love .
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
Segmentation fault

Running this code with GDB:

$ gdb --args love .
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
[...]
Reading symbols from love...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/love .
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe7f76700 (LWP 29772)]
[New Thread 0x7fffe7775700 (LWP 29773)]
[New Thread 0x7fffe6f74700 (LWP 29774)]
[New Thread 0x7fffe6773700 (LWP 29775)]
[New Thread 0x7fffe5f72700 (LWP 29776)]
[New Thread 0x7fffe5771700 (LWP 29777)]
[New Thread 0x7fffe4f70700 (LWP 29778)]
[New Thread 0x7fffe476f700 (LWP 29779)]
[New Thread 0x7ffff7ecf700 (LWP 29780)]
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
[Thread 0x7ffff7ecf700 (LWP 29780) exited]
[New Thread 0x7fffe389e700 (LWP 29781)]
[Thread 0x7fffe389e700 (LWP 29781) exited]
[New Thread 0x7fffe389e700 (LWP 29782)]
[New Thread 0x7fffe309d700 (LWP 29783)]
[New Thread 0x7fffe2784700 (LWP 29784)]
[New Thread 0x7fffe1f83700 (LWP 29785)]

Thread 1 "love" received signal SIGSEGV, Segmentation fault.
0x00007ffff74c8c5c in ?? () from /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2
(gdb) bt
#0  0x00007ffff74c8c5c in ?? () from /usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2
#1  0x0000000000400f41 in ?? ()
#2  0x00007ffff71412e1 in __libc_start_main (main=0x400d20, argc=2, argv=0x7fffffffe228, init=<optimized out>, fini=<optimized out>, 
    rtld_fini=<optimized out>, stack_end=0x7fffffffe218) at ../csu/libc-start.c:291
#3  0x0000000000401135 in ?? ()

The backtrace is probably useless. I have no experience with gdb and couldn't figure out how to make it load the debug symbols from liblove-dbg.

Removing either line [1] or [2] in the code makes it work.

After love.update switches the game state to other, it will not call the draw function. I get an error message when I go back to the old game state and update the ui.
There doesn't seem to be an easy way to reset the ui without recreating it.

To accurately draw lines in love, it is required to offset the coordinates by .5.
nk_love_draw_polyline() causes issues with accurate line rendering, because it ignores this rule and draws lines at integer coordinates.

This is a rectangle drawn with love.graphics.line:

function love.draw()
    love.graphics.setLineWidth(1.0)
    love.graphics.line(10.5, 10.5, 100.5, 10.5, 100.5, 100.5, 10.5, 100.5, 10.5, 10.5)
end

This is the same rectangle drawn with nk.line:

if nk.windowBegin("window", 0, 0, 200, 200) then
    love.graphics.setLineWidth(1.0)
    nk.line(10.5, 10.5, 100, 10, 100.5, 100.5, 10.5, 100.5, 10.5, 10.5)
end
nk.windowEnd()

Both rectangles should look identical, with a thickness of 1 pixel. The one drawn by nk.line is 2 pixels wide. It's not possible to draw lines with a thickness of 1 with nk.line.

I'm checking out this awesome library and I noticed that it feels quite sluggish when I create a simple window and drag it around. Not sure if it's designed to be that way or not, but the window drags significantly behind my cursor.

My hardware should not be to blame, I am running a 6700K and a GTX 1070. I am using the precompiled Linux x86_64 module.

hiya - do you know if it's possible to build this for iOS ?

Hello! I get an odd error when I call nuklear functions from a coroutine:

Error

main.lua:25: bad argument #1 to 'resume' (Nuklear context expected, got thread)


Traceback

[love "callbacks.lua"]:228: in function 'handler'
[C]: in function 'resume'
main.lua:25: in function 'draw'
[love "callbacks.lua"]:168: in function <[love "callbacks.lua"]:144>
[C]: in function 'xpcall'

Here's a minimal reproduction:

local nuklear = require('nuklear')
local nuk_ui
local co

function ui_one_frame()
   nuk_ui:frameBegin()
   if nuk_ui:windowBegin('Window', 100, 100, 600, 160,
          'border', 'movable', 'title') then
      nuk_ui:layoutRow('dynamic', 30, 1)
      nuk_ui:label('Hello, world!')
   end
   nuk_ui:windowEnd()
   nuk_ui:frameEnd()
end

function ui_stuff()
   while true do
      ui_one_frame()
      coroutine.yield()
   end
end

function love.draw()
   love.graphics.clear(0, 0, 0, 1)
   coroutine.resume(co)
   --ui_one_frame()
   nuk_ui:draw()
end

function love.load(_aa, _b)
   nuk_ui = nuklear.newUI()
   co = coroutine.create(ui_stuff)
end

As far as I can see it's failing on the call to windowBegin(). If I replace the coroutine.resume call with ui_one_frame (i.e. call the nuklear functions from the main coroutine) things work fine. Is this expected behavior?

Using 32-bit love2d 11.3.0 and 32-bit dll (renamed to nuklear-32.dll to make it clear its 32-bit)

Error: error loading module 'nuklear-32' from file '.\nuklear-32.dll':
%1 is not a valid Win32 application.

stack traceback:
[string "boot.lua"]:777: in function <[string "boot.lua"]:773>
[C]: at 0x6cc8a030
[C]: in function 'require'
main.lua:43: in main chunk
[C]: in function 'require'
[string "boot.lua"]:570: in function <[string "boot.lua"]:380>
[C]: in function 'xpcall'
[string "boot.lua"]:787: in function <[string "boot.lua"]:780>
[C]: in function 'xpcall'

When using love.graphics.[translate/rotate/scale], bad things happen. Strange mask clipping, input isn't properly transformed, etc. The use case I am trying to implement is the ability to pan the whole UI around, or zoom in and out.

The most recently released binaries are not compatible with LOVE 11.1. They result in this issue but supposedly this has been fixed in master.

Currently I am unable to build from source and so this is unusable in LOVE 11.1. The last release was in December 2016. Is there any chance of a new release with updated binaries?

Working with windows 64bit for reference, but it's probably nice to have up to date binaries across the board.

hi there! osx - built nuklear.so without incident and put it in my love project dir (a directory called 'mb') this is how I invoke things:

blombp:mb blo$ pwd
/Users/blo/proj/mb
blombp:mb blo$    open -n -a love  ../mb --args --debug --console

I get

Error
main.lua:1 module 'nuklear' not found
...

I installed luajuit via brew to build love-nuklear. this is what i have .dylib-wise:

blombp:mb blo$ ls -al /usr/local/lib/*lua*
lrwxr-xr-x  1 blo  admin  52 Sep  2 15:37 /usr/local/lib/libluajit-5.1.2.0.5.dylib -> ../Cellar/luajit/2.0.5/lib/libluajit-5.1.2.0.5.dylib
lrwxr-xr-x  1 blo  admin  48 Sep  2 15:37 /usr/local/lib/libluajit-5.1.2.dylib -> ../Cellar/luajit/2.0.5/lib/libluajit-5.1.2.dylib
lrwxr-xr-x  1 blo  admin  42 Sep  2 15:37 /usr/local/lib/libluajit-5.1.a -> ../Cellar/luajit/2.0.5/lib/libluajit-5.1.a
lrwxr-xr-x  1 blo  admin  46 Sep  2 15:37 /usr/local/lib/libluajit-5.1.dylib -> ../Cellar/luajit/2.0.5/lib/libluajit-5.1.dylib
lrwxr-xr-x  1 blo  admin  38 Sep  2 15:37 /usr/local/lib/libluajit.a -> ../Cellar/luajit/2.0.5/lib/libluajit.a
lrwxr-xr-x  1 blo  admin  42 Sep  2 15:37 /usr/local/lib/libluajit.dylib -> ../Cellar/luajit/2.0.5/lib/libluajit.dylib

Help? Sadly, I'm a bit new to lua/love. Sorry if this is stupid user error. :(

Either released binaries or the one I built with LuaJIT 2.0.4 locally does not work with love2d or luajit.

There is a error message:

Error: error loading module 'nuklear' from file '.\nuklear.dll':
找不到指定的程序。 (Cannot find given executable)

Using 1.2-win64:

nk.frameBegin()

if nk.windowBegin('Test Window', 200, 200, 350, 200, 'title', 'movable', 'scalable') then
	nk.layoutSpaceBegin('dynamic', 150, 2)
	nk.layoutSpacePush(0.1, 0.1, 0.4, 0.4)
	nk.button('Button A')
	nk.layoutSpacePush(0.5, 0.5, 0.4, 0.4)
	nk.button('Button B')
	nk.layoutSpaceEnd()
end
nk.windowEnd()

nk.frameEnd()

Changing 'dynamic' to 'static' seems to have no affect on the layout behavior. It works just fine for layoutRowBegin.

static int nk_love_layout_space_begin(lua_State *L)
{
	nk_love_assert_argc(lua_gettop(L) == 3);
	enum nk_layout_format format = nk_love_checkformat(1);
	float height = luaL_checknumber(L, 2);
	int widget_count = luaL_checkint(L, 3);
	nk_layout_space_begin(&context, format, height, widget_count);
	return 0;
}

vs

static int nk_love_layout_row_begin(lua_State *L)
{
	nk_love_assert_argc(lua_gettop(L) == 3);
	enum nk_layout_format format = nk_love_checkformat(1);
	float height = luaL_checknumber(L, 2);
	int cols = luaL_checkint(L, 3);
	nk_layout_row_begin(&context, format, height, cols);
	return 0;
}

Am I doing something wrong?

Hello,

I would like to use love-nuklear for a project on windows 10. I have mingw64 installed.

love is available for windows and you provide a binary for windows 64bit. What do I need else to make it work ?
Do I need to install luajit ?

Hi I was wondering if you knew any special steps I might need to take to build this library correctly for Mac? These were the steps I took:

1. Check out v1.2
2. cmake .
3. make
4. cp nuklear.so to my project directory
5. Include nuklear with nk = require 'nuklear'

However when I try to run nk.init() I get the following:

Error: main.lua:16: attempt to call field 'init' (a nil value)
stack traceback:
        main.lua:16: in function 'load'
        [string "boot.lua"]:439: in function <[string "boot.lua"]:435>
        [C]: in function 'xpcall'

I tried checking what keys existed in the nk table, and printing those out gave me:

0       function: 0x15d32e50

Calling that function with nk[0]() produced:

Error: attempt to compare string with function
stack traceback:
        [C]: at 0x0f9c2960
        main.lua:17: in function 'load'
        [string "boot.lua"]:439: in function <[string "boot.lua"]:435>
        [C]: in function 'xpcall'

Am I missing something obvious? Any help is appreciated :) Thanks for the great library.

Hi,
if a window is switch to hidden state ( nk.windowHide('Skin Example') )
it still consumes the mouse events if mouse is over the window area.
Franc

I tried running the example provided in both LÖVE 10.2 and 11.1

This is the result (as expected) when using 10.2:

This is the result when using 11.1:

To make text input work on Android and iOS, I believe I need to edit nk_love_edit to call love.keyboard.setTextInput to enable/disable the keyboard.

Hello,

I successfully run love-nuklear in my project. But I have difficulty to make just simple things as draw a rectangle with some text in it.

What I need is to make appear a simple box without title and semi-transparent with one or two lines of text in it.
I do not need to make it move or to have buttons

Currently, I tried this :

    ui:frameBegin()
    if
        ui:windowBegin(
            "Simple Example",
            100,
            100,
            200,
            160,
            "border",
            "title",
            "movable"
        )
    then
        ui:label("ezezeze")
    end
    ui:windowEnd()
    ui:frameEnd()

But the text label does not appear anywhere (or is it of the same color as background ?)

Could anyone using this nice library give me some piece of advice ?

Also : can you round the window corners ?

Regards

Since I have to ensure every external libraries I use is compiled with MSVC because LOVE is compiled with MSVC and I have to ensure (ABI) stability, I can't use the prebuilt binaries which is compiled with MinGW.

There are some modifications that needed to successfully compile it under MSVC

1. Add LUA_BUILD_AS_DLL compile definitions to the CMake if the toolchain is MSVC.
2. Add #define LUA_LIB in nuklear_love before #include <lua.h>.

Both steps is required to ensure luaopen_nuklear exported to the DLL. The build instruction, is easy.

rem Say, %LUA_DIR% is the LuaJIT dir, excluding the "src" dir
rem and you've invoked "msvcbuild.bat" under LuaJIT src directory
rem using VS command prompt, then build love-nuklear like this
cmake -Bbuild -H. -DLUA_INCLUDE_DIR=%LUA_DIR%\src -DLUA_LIBRARY=%LUA_DIR%\src\lua51.lib -DCMAKE_INSTALL_PREFIX=%CD%\install
cmake --build build --config Release --target install

Then you can found nuklear.dll in install folder ready to be used, compiled with MSVC.

for the case of in game chat, it'd be useful to be force-focus text inputs, so you can have a chat key and not require mousing.

this kind of thing is also generally useful for keyboard (or controller) accessibility, which seems a bit impossible at the moment.

also, is the only way to have a working multi-line text widget to draw the text myself?

In my testing on macos, the sample app occupied 85% cpu time, the framerate can not event reach 60. On the contrary, the sdl2 example of nuklear (compiled with INCLUDE_ALL) only takes 6% of CPU. The timing profiler shows that most of time (>80%) is spent in nk_love_draw.

The reason might be the current implementation didn't use nk_convert and vertexes to do batch draw on GPU.

The love binding implementation for dear imgui uses Mesh, which looks faster. maybe it's a way to improve.

nuklear.button("play!!!", nk.colorRGBA(235, 177, 255))
"color buttons cannot have a title" error

Normal

Hover

ui:stylePush({
        button = {
          normal = '#99999944',
          hover = '#99999900',
          ['text background'] = '#ffffff00'
        }
      })
			if ui:button('Button') then
				print('button pressed!')
			end
      ui:stylePop()

It's seems that the text background is the same as normal or hover.

Using the following code:

local nk = require 'nuklear'

function love.load()
	nk.init()
end

function love.update(dt)
	nk.frameBegin()
	if nk.windowBegin('Simple Example', 100, 100, 200, 160, 'closable') then
	end
	nk.windowEnd()
	nk.frameEnd()
end

function love.draw()
	nk.draw()
end

function love.keypressed(key, scancode, isrepeat)
	nk.keypressed(key, scancode, isrepeat)
end

function love.keyreleased(key, scancode)
	nk.keyreleased(key, scancode)
end

function love.mousepressed(x, y, button, istouch)
	nk.mousepressed(x, y, button, istouch)
end

function love.mousereleased(x, y, button, istouch)
	nk.mousereleased(x, y, button, istouch)
end

function love.mousemoved(x, y, dx, dy, istouch)
	nk.mousemoved(x, y, dx, dy, istouch)
end

function love.textinput(text)
	nk.textinput(text)
end

function love.wheelmoved(x, y)
	nk.wheelmoved(x, y)
end

This creates a window that appears to be closable (there is a X in the top right corner), however, when clicking on said X, the window opens again in the next frame.

Is this an expected behavior? If yes, what is the correct way to create a window that can be closed?

Hello,

when passing directly a number to ui:property the value can't get updated from the UI component.

However, if I pass it by wrapping it in a table (like in edit2) then it works.

local edit1 = 2
local edit2 = { value = 2 }

function Player:updateUI(ui) 
  if ui:windowBegin('Player infos', 100, 100, 200, 160,
			'border', 'title', 'movable', 'minimizable') then
		ui:layoutRow('dynamic', 30, 2)
		ui:label('Edit #1')
    ui:property("", 0, edit1, 3, 1, 1)
		ui:layoutRow('dynamic', 30, 2)
		ui:label('Edit #2')
    ui:property("", 0, edit2, 3, 1, 1)
	end
	ui:windowEnd()
end

Am I doing something wrong?

Is it possible to offset the origin for tooltips in anyway? They seem to be set to the mouse position and I can't see any obvious way to affect their behaviour.

Click events are frequently not detected at low frame rates.

Example code:

local ui = require('nuklear').newUI()

function love.mousepressed(...)
	print("pressed", ui:mousepressed(...) and "consumed" or "ignored")
end

function love.mousereleased(...)
	print("released", ui:mousereleased(...) and "consumed" or "ignored")
end

function love.mousemoved(...) ui:mousemoved(...) end

function love.draw()
	ui:frameBegin()
	if ui:windowBegin("window", 0, 0, 800, 600, 'background') then
		ui:layoutRow('static', 30, 100, 1)
		if ui:button("Click me") then
			print("clicked")
		end
		ui:windowEnd()
	end
	ui:frameEnd()
	love.timer.sleep(1 / 2)
	ui:draw()
end

Expected output: for every pressed line, a clicked line should appear immediately after it.

Actual output:

pressed in frame        3       consumed
clicked in frame        4
released in frame       4       consumed
pressed in frame        8       consumed
released in frame       8       consumed
pressed in frame        11      consumed
released in frame       11      consumed
pressed in frame        13      consumed
clicked in frame        14
released in frame       16      consumed
pressed in frame        19      consumed
released in frame       19      consumed
pressed in frame        21      consumed
released in frame       21      consumed
pressed in frame        23      consumed
released in frame       23      consumed
pressed in frame        25      consumed
clicked in frame        26
released in frame       26      consumed

Note how clicks are not recognized if the mouse button is released in the same frame.

It would be great if the developer could optionally use individual styles for different buttons. Nuklear itself allows pushing a style in the 'style' property of the context struct (As seen in https://github.com/vurtun/nuklear/blob/master/demo/overview.c#L867 i.e.).

From would I can judge, it looks like it would be a addition to the nk_love_button method (https://github.com/keharriso/love-nuklear/blob/master/src/nuklear_love.c#L1934), where the developer could push in the style and the method sets it to the &context if the parameter is supplied.

Another approach could be a new method that sets the style for the command, in a push and pop style, which could be used in conjuction with the already available nk.stylePush command in love-nuklear

Code to reproduce the issue:

local ui = nk.newUI()

ui:stylePush({
	checkbox = {
		normal = love.graphics.newImage('checkbox.png'),
	},
})

Stack trace:

Error: attempt to index a nil value
stack traceback:
	[string "boot.lua"]:637: in function <[string "boot.lua"]:633>
	[C]: in function 'stylePush'
	main.lua:4: in main chunk
	[C]: in function 'require'
	[string "boot.lua"]:475: in function <[string "boot.lua"]:311>
	[C]: in function 'xpcall'
	[string "boot.lua"]:645: in function <[string "boot.lua"]:639>
	[C]: in function 'xpcall'

The error gets thrown when calling pushStyle() before calling frameBegin(). I have an app that pushes a style when it starts, before the first frameBegin() - this worked fine with an older version of love-nuklear.

Is this by design? Are static styles to be pushed in every frame?

The project could use a set of instructions for how to build for android distribution, preferably also statically link into the love2d binary itself.