Does this make the GUI for Leadwerks Lua dependent then? It seems like this might be hard to make both C++ & Lua GUI extendable the same way.

When writing a system that others may use, or I may use later I always start with the experience I want to have working with it and work backwards from there. So in your example how would I make a button and register it's click event to do my game logic in? I don't want to draw the button I mean using the button LE will come with.

Love the pic. "Put this one in your mouth, this one in your ear, and this one in your butt" Best part of that movie!

GUI* gui = GUI::Create(window);
Widget* widget = Widget::Create(gui);
widget->SetShape(20,40,70,26);
widget->SetScript("Scripts/GUI/Button.lua");

Then if someone makes a set of scripts for some crazy RPG UI you can utilize that just as easily.

I really hope when finished earn it's own spot in the tutorial section!

This really look interesting... How about using LUA to create the widgets that would be represented as a new node type with input and output from the node editor?

Since the node editor is good for logic, It could really fill the gap, users could exchange scripts of GUI designs that could be easily used after with the node editor.

That is a possibility. I think it is more interesting for an in-game GUI on a 3D surface, like a simple interface you control to open a door or something. The game's menu GUI will mostly be handling quality settings, etc. so the flowgraph isn't as useful there.

Have you thought about doing something with callbacks? You could have both lua and c++ UI code. I wrote a simple program to prove the concept, the end result is you could write c++ UI like this:

Widget* Button = CreateWidget();
Button->Draw = std::bind(&MyDrawFunc);

void MyDrawFunc()
{
   std::cout << "MyDrawFunc" << std::endl;
}

Or with classes:

class MyButton
{
public:
   MyButton()
   {
       Widget* Button = CreateWidget();
       Button->Draw = std::bind(&MyButton::Draw, this);
   }

   void Draw()
   {
       std::cout << "MyButtonDraw" << std::endl;
   }
};

MyButton mybutton;

The for Lua you could do:

function LuaDrawFunc()
   print("LuaDrawFunc")
end

button = Widget.Create()
button:DrawCallback(LuaDrawFunc)

or with a table:

thing = {}

function thing:ThingDraw()
   print("ThingDraw!")
end

thing.button = Widget:Create()
thing.button:DrawCallback(thing.ThingDraw, thing)

C++ callbacks are definitely an option.

I've refactored the window class on Windows now, and it allows the creation of embedded subwindows parented to a window. So now I can create a window that uses OS commands to draw a GUI directly onto it, without a 3D context, and subwindows can be created within that window and have an OpenGL context created on them and rendered to.

I really like the idea of using a Lua script on widgets just like we do for entities because it makes things so incredibly flexible. I expect we'll have a core set of simple widget scripts, and then people can go crazy with them by modifying the drawing behavior, the widget's response to various events, or both.

However, it looks like simple "skinning" probably won't really be a thing, since the drawing commands are built into the script. Instead, you would modify the script to draw the way you want. Another layer of abstraction beyond that would probably be too complicated to be useful, since a skin can't account for every possible widget people will create. Maybe there will be a few modifiable values like foreground / background colors, but only really basic UIs are going to rely solely on that. Even the default Windows theme has lots of subtle variation in colors and shading.

This is definitely a very unique approach to GUI design, and after thinking about this issue for years I think I really like the idea.

Are you going to handle resolution independence for us? Without that there isn't much use of the system over the custom ones out there.

Yeah, I have thought about that. I'm thinking a global GUI scaling factor can be used to multiply all coordinates maybe, or perhaps an option will exist to place things in percentage dimensions.

I took a page out of Aggrors and did anchoring and custom "units" for position and size of widgets and then a formula converts those units on the fly to the resolution. Percentages don't work right between aspect ratios when it comes to size from my experience. The hardest part about that is working in these units as it's hard to know where the values show up but that's why a wysiwyg gui editor would be ideal so those values don't mean much to the user as they just position and size widgets in the editor and then anchor them and now it'll look the same on any resolution.

What if the aspect ratio changes?

or perhaps an option will exist to place things in percentage dimensions.

If I recall if you make a widget image width/height, say, 25% of the screen width in a 4:3 it might look fine, but then the user switches to a 16:9 resolution and it won't look right anymore. Pending that's what you meant in your above quote about percentages.

who does 4:3 nowdays?

Options are nice to have. Today it's 1 aspect ratio tomorrow it's another.

I know this is a year old, but I'm still interested.

I'm having an error thrown on any function call that follows Widget::Draw(). If I don't call draw, it only renders for a single frame when the mouse hovers.

Any ideas?

1 hour ago, St0nedas said:

I know this is a year old, but I'm still interested.

I'm having an error thrown on any function call that follows Widget::Draw(). If I don't call draw, it only renders for a single frame when the mouse hovers.

Any ideas?

I do not understand your question, or how it relates to a year-old development blog.  Can you post a working example in a new forum topic?