LÖVE-Nuklear - a lightweight immediate mode GUI

[grump]

There's a pull request on Github that fixes things inside love-nuklear to make it compatible with LÖVE 11. The author seems to have abandoned the lib though

Some things can't be fixed with the setColor hack - the color picker is broken and requires a fix in the C code.

[keharriso]

LÖVE-Nuklear is back and better than ever in v2.5. If anyone has any problems, please add an issue to the github repo. Thanks, and good luck with your projects!

[totalvamp]

Loving it so far, however I'm confused on how to handle textinput, there is no example of this either.

Does anyone have an example on how to get every text input into a text input?

[keharriso]

The edit widget is probably what you're looking for.

Simple example:

Code: Select all

local nuklear = require 'nuklear'

local ui

function love.load()
	love.keyboard.setKeyRepeat(true)
	ui = nuklear.newUI()
end

local edit = {value = 'Hello, world!'}

function love.update(dt)
	ui:frameBegin()
	if ui:windowBegin('Text Input', 100, 100, 200, 80,
			'border', 'title', 'movable') then
		ui:layoutRow('dynamic', 30, 1)
		local state, changed = ui:edit('field', edit)
		if changed then
			print(edit.value)
		end
	end
	ui:windowEnd()
	ui:frameEnd()
end

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

function love.keypressed(key, scancode, isrepeat)
	ui:keypressed(key, scancode, isrepeat)
end

function love.keyreleased(key, scancode)
	ui:keyreleased(key, scancode)
end

function love.mousepressed(x, y, button, istouch, presses)
	ui:mousepressed(x, y, button, istouch, presses)
end

function love.mousereleased(x, y, button, istouch, presses)
	ui:mousereleased(x, y, button, istouch, presses)
end

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

function love.textinput(text)
	ui:textinput(text)
end

function love.wheelmoved(x, y)
	ui:wheelmoved(x, y)
end

[monolifed]

I made a rough comparison of their cpu usage (at 60fps)
gspot (demo screen) has the lowest
suit (couldn't find a demo: button spam screen) has slightly more cpu usage than gspot
loveframes (demo screen) use around 1.3 times more cpu
nuklear (demo screen with only calculator) has slightly more cpu usage than loveframes

I was expecting nuklear to perform better, maybe I did something wrong?

[keharriso]

I made a rough comparison of their cpu usage (at 60fps)
gspot (demo screen) has the lowest
suit (couldn't find a demo: button spam screen) has slightly more cpu usage than gspot
loveframes (demo screen) use around 1.3 times more cpu
nuklear (demo screen with only calculator) has slightly more cpu usage than loveframes

I was expecting nuklear to perform better, maybe I did something wrong?

It's not entirely unexpected that LÖVE-Nuklear performs slightly worse than pure-Lua alternatives. This could be for any number of reasons. For one, a pure Lua library doesn't need to cross the Lua/C boundary, while LÖVE-Nuklear passes it many times, at least once for every call. For another, LÖVE-Nuklear does extensive argument checking and assertions with every call. There are also probably many possibilities I can't think of at the moment.

I will say that performance is secondary in priority to simplicity and flexibility. Nuklear has a very strong styling system, and I try to keep the API as clean as possible. Maybe one day someone (perhaps me) will re-write Nuklear in pure Lua and see if it's any faster. For the moment, however, it's working perfectly for my project.

Also, the entirety of LÖVE-Nuklear is a single C file, so if anyone wants to help improve LÖVE-Nuklear's performance, you know exactly where to start.

EDIT: I did some side-by-side comparisons and it looks like Nuklear is also drawing more than, say, Gspot. Nuklear does window borders, title bar backgrounds, rounded buttons with borders, etc. If you haven't included these things in your tests, they may be something to consider. For example, the calculator takes roughly 50 draw calls to render while the Gspot demo looks like it takes close to half that.

I tried a demo of 50 windows with 2 labels and 2 buttons each. With window title and borders, the FPS was 240. Without window title and window borders, the FPS was 300. That's not counting the performance of button borders.

It's also possible that using LuaJIT FFI would be faster than the plain C module.

I would encourage anyone looking into any sort of performance issues (in this case related to the GUI) to ensure they aren't optimizing prematurely. At the end of the day, does it really matter that you can only render 50 windows 240 times every second? In most cases I think you'll find the ease of use of the libraries trumps the performance considerations.

[Frenchgui]

Hi keharriso, thanks a lot for all your work (binding and docs!). Just a question: how can I minimize a window at start, when I use ui:windowCollapse(mywindowname) once at start I can't expand it manually?

[keharriso]

Hi keharriso, thanks a lot for all your work (binding and docs!). Just a question: how can I minimize a window at start, when I use ui:windowCollapse(mywindowname) once at start I can't expand it manually?

Thanks for the kind words.

You need to keep track of whether or not the window has been collapsed yet or not. I did this in the following example with the "collapse" variable.

Code: Select all

local collapse = true
function love.update(dt)
	ui:frameBegin()
	if ui:windowBegin('Collapse Example', 100, 100, 200, 150,
			'border', 'title', 'movable', 'minimizable') then
		ui:layoutRow('dynamic', 30, 1)
		ui:label('Hello, world!')
	end
	ui:windowEnd()
	if collapse then
		collapse = false
		ui:windowCollapse('Collapse Example')
	end
	ui:frameEnd()
end

[Frenchgui]

Oh! Thanks everything is working now..

[CrimsonGuy]

For some reason i cant compile this on Ubuntu 18.04 even tho i have LuaJit and Cmake i get this error

Code: Select all

cmake -DCMAKE_BUILD_TYPE=Release ../love-nuklear
CMake Error at /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find LuaJIT (missing: LUA_LIBRARIES)
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindLuaJIT.cmake:59 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:5 (FIND_PACKAGE)


-- Configuring incomplete, errors occurred!

I found this bug, but workaround doesn't seem to be working for me or maybe im pointing to the wrong direction

https://github.com/minetest/minetest/issues/7306

cmake -DLUA_INCLUDE_DIR=/usr/lib/x86_64-linux-gnu/ -DCMAKE_BUILD_TYPE=Release ../love-nuklear

I swear for some reason cmake always gives me troubles its like a curse or something