GUI, some startup instructions for create a custom one?

[tomshreds]

Hi,

I've been using löveframes for some months and I must admit that I always been unimpressed with the results.

Yes it has some nice features and some nice advanced ones. But most of the time I end up being unable to do what I want. Stuff like no "selected" appearance on lists items are a big let down for user friendliness. There's also many glitches when you do too much "funky" stuff with it.

So I'd like to create my own interface elements. I'd need to do some pretty advanced stuff such as chart rendering, lists with column ordering, resizable windows, etc.

But I'm frankly lost in all of this. I could start my own löveframes branch or I could build from scratch but IMO it would take such a long time to develop one. I've got no spare time to waste so I need some advice on how should I start if I want to build one from scratch. Any suggestions or advice?

Any other GUI suggestions are welcome, but I tried pretty much all of them now.

Thanks a lot and have a good weekend!

[Ubermann]

You have Löveframes source code at your disposal. Don't you?

[szensk]

I'd recommend extending loveframes. It's relatively easy to implement your own draw, update methods in which you can do a lot of things if you look at the internal objects. For example drawing a chart can easily be done in a customized panel doing exactly such. Just wrap loveframes.Create to create an instance of your new class when requested. I'm sure the other things you need could also be coerced into loveframes, though this wouldn't fix its "funky" aspects.

If you're going to start from scratch I'd recommend developing an immediate mode GUI. These are, in my opinion, easier to understand and thus debug. When possible base your methods on loveframes code (ie inserting text).

[tomshreds]

I'd recommend extending loveframes. It's relatively easy to implement your own draw, update methods in which you can do a lot of things if you look at the internal objects. For example drawing a chart can easily be done in a customized panel doing exactly such. Just wrap loveframes.Create to create an instance of your new class when requested. I'm sure the other things you need could also be coerced into loveframes, though this wouldn't fix its "funky" aspects.

If you're going to start from scratch I'd recommend developing an immediate mode GUI. These are, in my opinion, easier to understand and thus debug.

That's what I was thinking about. I guess extending löveframes would be easier and quicker for me since I already use it massively in my project.

I'd need to introduce advanced stuff such as charting, any idea how I could get this done with lua/löve?

Also what other kind of UI is there? Immediate mode vs ? What's the differences? I always knew only immediate mode.

Thanks a lot!

[ejmr]

Also what other kind of UI is there? Immediate mode vs ? What's the differences? I always knew only immediate mode.

‘Retained Mode’ or RMGUIs are the other kind. The biggest distinction is that RMGUIs maintain a more authoritative state of the GUI, i.e. the state of the underlying data widgets and models. Some IMGUI libraries do this as well, but in my experience most IMGUIs get rid of that state as soon as it’s unneeded.

[vrld]

Actually, the biggest difference between immediate mode and retained mode GUIs is who is in control of the program flow. Consider having a simple button that should print a message when clicked.

With RMGUI you typically do something like this (using loveframes):

Code: Select all

function love.load()
	button = loveframes.Create("Push Me")
	button.OnClick = function(object)
		print("And Then Just Touch Me")
		print("So I Can Get My")
		print("Satisfaction")
	end
end

-- calling loveframes.update/draw/... here

While an IMGUI could look like this (using Quickie):

Code: Select all

function love.update(dt)
	if Button{text = "Push Me"} then
		print("And Then Just Touch Me")
		print("So I Can Get My")
		print("Satisfaction")
	end
end

-- calling gui.core.draw here

As szensk said, IMGUI is usually easier to understand at a glance, because widgets and and their effects are less scattered in the source code. You can also easily hide (just dont call the function) and conditionally show widgets, e.g.

Code: Select all

local checkbox = {checked = false, label = "Show super secret input box"}
local input = {text = ""}
function love.update(dt)
	gui.group.push{grow = "down"}
	gui.Checkbox{info = checkbox}

	if checkbox.checked then
		 gui.Input{info = input} -- only shown if checkbox is checked
	end

	if Button{text = "Push Me"} then
		print("And Then Just Touch Me")
		print("So I Can Get My")
		print("Satisfaction")
	end
	gui.group.pop{}
end

I also think that it is easier to extend an IMGUI framework than it is to extend a RMGUI one. If you are a visual guy, you should watch this video to get a good idea what imgui is good at and why it is.

However, certain things are harder to realize in IMGUI, for example playing a sound when the mouse enters a widget, realizing a drop-down selection-list or supporting drag- and resizeable windows. All of this is possible, but you have to think a little harder than with a retain mode gui.


That said, seeing how you have pretty advanced requirements, especially resizeable windows, you are probably best off just extending loveframes. Maybe you can help to improve it. I am sure Nikolai would be very happy to receive your updates. You could also try extending Quickie or even build a RMGUI on top of it, but documentation besides comments in the code is still pretty much non-existant.

[tomshreds]

Actually, the biggest difference between immediate mode and retained mode GUIs is who is in control of the program flow. Consider having a simple button that should print a message when clicked.

With RMGUI you typically do something like this (using loveframes):

Code: Select all

function love.load()
	button = loveframes.Create("Push Me")
	button.OnClick = function(object)
		print("And Then Just Touch Me")
		print("So I Can Get My")
		print("Satisfaction")
	end
end

-- calling loveframes.update/draw/... here

While an IMGUI could look like this (using Quickie):

Code: Select all

function love.update(dt)
	if Button{text = "Push Me"} then
		print("And Then Just Touch Me")
		print("So I Can Get My")
		print("Satisfaction")
	end
end

-- calling gui.core.draw here

As szensk said, IMGUI is usually easier to understand at a glance, because widgets and and their effects are less scattered in the source code. You can also easily hide (just dont call the function) and conditionally show widgets, e.g.

Code: Select all

local checkbox = {checked = false, label = "Show super secret input box"}
local input = {text = ""}
function love.update(dt)
	gui.group.push{grow = "down"}
	gui.Checkbox{info = checkbox}

	if checkbox.checked then
		 gui.Input{info = input} -- only shown if checkbox is checked
	end

	if Button{text = "Push Me"} then
		print("And Then Just Touch Me")
		print("So I Can Get My")
		print("Satisfaction")
	end
	gui.group.pop{}
end

I also think that it is easier to extend an IMGUI framework than it is to extend a RMGUI one. If you are a visual guy, you should watch this video to get a good idea what imgui is good at and why it is.

However, certain things are harder to realize in IMGUI, for example playing a sound when the mouse enters a widget, realizing a drop-down selection-list or supporting drag- and resizeable windows. All of this is possible, but you have to think a little harder than with a retain mode gui.


That said, seeing how you have pretty advanced requirements, especially resizeable windows, you are probably best off just extending loveframes. Maybe you can help to improve it. I am sure Nikolai would be very happy to receive your updates. You could also try extending Quickie or even build a RMGUI on top of it, but documentation besides comments in the code is still pretty much non-existant.

Thanks for the clear explanation! Liked the examples, nice video too =)

The problem is that I'm still a bit lost, last GUI library I worked on was for .NET, and I just found out that it's completely different to develop one interface library for a game hehe

I used Quickie in the past, but at the time I think I switched to löveframes because it had more advanced features. I'll retry it and also will check löveframes code a bit more. I guess I'll be able figure out where to do afterward :-P

Thanks again, you got me to learn something today!