Development Blog

Definitely do kind of like this way. It's very simple and straight forward, looks organized too. We could just create a listener or something in C++ and attach a Lua script to it to "spawn" the GUI from C++ code right?

It would probably be something like Widget::SetCallback() instead of Widget::SetScript() for C++. The real meat of the GUI is the window management and handling partial window refreshing, widget alignment, and events.

 

Think of it as a game engine for GUI elements.

Have you defined how the user would handle events yet? Say the click event? That button script would be a generic button script that you could reuse with many different buttons right? So the click events inside it wouldn't be what the user uses to do game specific logic in the buttons click event right?

Right, that's what I'm thinking about. Maybe we'll have an event queue system, so that script would call something like this when the button is clicked:

Event::Emit(Event::WidgetAction,self.widget)

 

Main.lua would then add this code in the loop:

while Event::Peek() do
local event = Event::Wait()
if event.id == Event::WidgetAction then
	if event.source == mybutton then
		--do something here
	end
end
end

 

It's kind of weird because there is the internal event handling in the window class, and then we're adding sort of a secondary event system. Not sure I like it but from the user's perspective it makes sense.

 

I really like the abstract design of this. I think the community is going to be very good at churning out a ton of useful widget scripts for various game interfaces I couldn't dream of.

My vote is defining callbacks vs polling.

Callbacks please.

Why do you prefer that?

Callbacks, I agree. Cleaner code, easier to separate different functionality and it gets triggered instantly.