ImGui LÖVE module

[Fenrir]

Hey, can you please make an extra big example love file with most of usable features?
It's very difficult for someone to use as documentation from C++ headers, someone really don't know C++.
And big amount of examples will help to understand exactly Lua syntax for creating GUI

Sorry but I won't be able to do it in a near future, the best would be to reimplement the test window (https://github.com/slages/love-imgui/bl ... i_demo.cpp) in Lua but it will need to wait.

[Tjakka5]

Coincidally, I am doing exactly that at the moment; Recreating the test window in lua.
Reason being to learn how everything works, how it's intended to be used.

If you want I can upload the code (with some comments), when Im done. But it might take a litte while before I'm done.

EDIT:
I'll also take this chance to keep a list of functions that I can not get to work.

Code: Select all

GetStyleColName() -- Is nil
GetIO() -- Is nil.

[Fenrir]

Coincidally, I am doing exactly that at the moment; Recreating the test window in lua.
Reason being to learn how everything works, how it's intended to be used.

If you want I can upload the code (with some comments), when Im done. But it might take a litte while before I'm done.

EDIT:
I'll also take this chance to keep a list of functions that I can not get to work.

Code: Select all

GetStyleColName() -- Is nil

Wow good luck with it! I'll definitely be interested in getting it and share it on the project page if possible!

For GetStyleColName, I can easily add support for it (and a couple of other functions returning string values), I'll have a look at it!

EDIT: OK I added support for string return types, it added 3 functions to the supported list (GetStyleColName, GetClipboardText, GetVersion)! I didn't made a release for it, I'll wait for other fixes/improvements for it.

[Tjakka5]

Awesome!

Does that also mean we can easily access "ImGuiCol_COUNT"?
Or is that even necessary?

In the test window it uses that variable to do the following:

Code: Select all

if (ImGui::BeginMenu("Colors"))
    {
        for (int i = 0; i < ImGuiCol_COUNT; i++)
            ImGui::MenuItem(ImGui::GetStyleColName((ImGuiCol)i));
        ImGui::EndMenu();
}

[Fenrir]

Awesome!

Does that also mean we can easily access "ImGuiCol_COUNT"?
Or is that even necessary?

In the test window it uses that variable to do the following:

Code: Select all

if (ImGui::BeginMenu("Colors"))
    {
        for (int i = 0; i < ImGuiCol_COUNT; i++)
            ImGui::MenuItem(ImGui::GetStyleColName((ImGuiCol)i));
        ImGui::EndMenu();
}

Hmm OK I just realized that this function as no real sense for the lua bindings, as the first parameter is an enum value, and as enums are binded to strings, you'll actually need to send the col name to retrieve it:

Code: Select all

imgui.GetStyleColName("Text")

Will return "Text"... Not very useful... :/ We would need to replace it by a custom one, taking an index like the C++ one and returning the string. And no need for ImGuiCol_COUNT as GetStyleColName returns "Unknow" as soon as you send an index out of range, so you can call it from an infinite loop and break when you reach "Unknow". But a custom binding for it is also possible. I'll have a look and let you know!

[RamiLego4Game]

How can I set the style color ?, imgui.GetStyle() doesn't work !

[s-ol]

Has anyone else gotten imgui.BeginModal gotten to work? nothing happens when I use it:

Code: Select all

    if imgui.BeginMainMenuBar() then
      if imgui.BeginMenu "Tools" then
        if imgui.MenuItem("Switch Scene", "S") then
          imgui.OpenPopup "scene switcher"
        end
        imgui.EndMenu()
      end    
    end
    imgui.EndMainMenuBar()

    if imgui.BeginPopup "scene switcher" then
      imgui.Text "hey hey hey!"
      imgui.EndPopup()
    end

    imgui.Render()

Also, I can't have two buttons with the same label?

Code: Select all

if imgui.Button "Button" then print "A" end
if imgui.Button "Button" then print "B" end

will just do nothing when the second one is pressed (though it is rendered).

Lastly, it seems tree node flags (TreeNodeEx, ImGuiTreeNodeFlags_*) are not implemented currently?

shouldn't the TreeNodeEx definition in imgui_iterator.h use

OPTIONAL_ENUM_ARG(flags, 0)
instead of
DEFAULT_ARG(ImGuiTreeNodeFlags, flags, 0)
?

[Fenrir]

How can I set the style color ?, imgui.GetStyle() doesn't work !

Yep GetStyle is not supported currently, to control the style you'll need to use PushStyleColor/PopStyleColor and PushStyleVar/PopStyleVar, for instance:

Code: Select all

imgui.PushStyleColor("WindowBg", 0, 0, 0, 0.9)
..
imgui.PopStyleColor(1)

Has anyone else gotten imgui.BeginModal gotten to work? nothing happens when I use it:

Code: Select all

    if imgui.BeginMainMenuBar() then
      if imgui.BeginMenu "Tools" then
        if imgui.MenuItem("Switch Scene", "S") then
          imgui.OpenPopup "scene switcher"
        end
        imgui.EndMenu()
      end    
    end
    imgui.EndMainMenuBar()

    if imgui.BeginPopup "scene switcher" then
      imgui.Text "hey hey hey!"
      imgui.EndPopup()
    end

    imgui.Render()

Also, I can't have two buttons with the same label?

Code: Select all

if imgui.Button "Button" then print "A" end
if imgui.Button "Button" then print "B" end

will just do nothing when the second one is pressed (though it is rendered).

Lastly, it seems tree node flags (TreeNodeEx, ImGuiTreeNodeFlags_*) are not implemented currently?

shouldn't the TreeNodeEx definition in imgui_iterator.h use

OPTIONAL_ENUM_ARG(flags, 0)
instead of
DEFAULT_ARG(ImGuiTreeNodeFlags, flags, 0)
?

For the popups, the docs says:

Popup identifiers are relative to the current ID-stack (so OpenPopup and BeginPopup needs to be at the same level).

So I tried it this way:

Code: Select all

    local openPopup = false

    if imgui.BeginMainMenuBar() then
      if imgui.BeginMenu "Tools" then
        if imgui.MenuItem("Switch Scene", "S") then
          openPopup = true
        end
        imgui.EndMenu()
      end    
    end
    imgui.EndMainMenuBar()

    if openPopup then
      imgui.OpenPopup "scene switcher"
    end
    if imgui.BeginPopup "scene switcher" then
      imgui.Text "hey hey hey!"
      imgui.EndPopup()
    end

    imgui.Render()

And it works!

For the labels issue, here's the long answer from the docs:

Q: Can I have multiple widgets with the same label? Can I have widget without a label? (Yes)
A: Yes. A primer on the use of labels/IDs in ImGui..
- Elements that are not clickable, such as Text() items don't need an ID.
- Interactive widgets require state to be carried over multiple frames (most typically ImGui often needs to remember what is the "active" widget).
to do so they need an unique ID. unique ID are typically derived from a string label, an integer index or a pointer.
Button("OK"); // Label = "OK", ID = hash of "OK"
Button("Cancel"); // Label = "Cancel", ID = hash of "Cancel"
- ID are uniquely scoped within windows, tree nodes, etc. so no conflict can happen if you have two buttons called "OK" in two different windows
or in two different locations of a tree.
- If you have a same ID twice in the same location, you'll have a conflict:
Button("OK");
Button("OK"); // ID collision! Both buttons will be treated as the same.
Fear not! this is easy to solve and there are many ways to solve it!
- When passing a label you can optionally specify extra unique ID information within string itself. This helps solving the simpler collision cases.
use "##" to pass a complement to the ID that won't be visible to the end-user:
Button("Play"); // Label = "Play", ID = hash of "Play"
Button("Play##foo1"); // Label = "Play", ID = hash of "Play##foo1" (different from above)
Button("Play##foo2"); // Label = "Play", ID = hash of "Play##foo2" (different from above)
- If you want to completely hide the label, but still need an ID:
Checkbox("##On", &b); // Label = "", ID = hash of "##On" (no label!)
- Occasionally/rarely you might want change a label while preserving a constant ID. This allows you to animate labels.
For example you may want to include varying information in a window title bar (and windows are uniquely identified by their ID.. obviously)
Use "###" to pass a label that isn't part of ID:
Button("Hello###ID"; // Label = "Hello", ID = hash of "ID"
Button("World###ID"; // Label = "World", ID = hash of "ID" (same as above)
sprintf(buf, "My game (%f FPS)###MyGame");
Begin(buf); // Variable label, ID = hash of "MyGame"
- Use PushID() / PopID() to create scopes and avoid ID conflicts within the same Window.
This is the most convenient way of distinguishing ID if you are iterating and creating many UI elements.
You can push a pointer, a string or an integer value. Remember that ID are formed from the concatenation of everything in the ID stack!
for (int i = 0; i < 100; i++)
{
PushID(i);
Button("Click"); // Label = "Click", ID = hash of integer + "label" (unique)
PopID();
}
for (int i = 0; i < 100; i++)
{
MyObject* obj = Objects;
PushID(obj);
Button("Click"); // Label = "Click", ID = hash of pointer + "label" (unique)
PopID();
}
for (int i = 0; i < 100; i++)
{
MyObject* obj = Objects;
PushID(obj->Name);
Button("Click"); // Label = "Click", ID = hash of string + "label" (unique)
PopID();
}
- More example showing that you can stack multiple prefixes into the ID stack:
Button("Click"); // Label = "Click", ID = hash of "Click"
PushID("node");
Button("Click"); // Label = "Click", ID = hash of "node" + "Click"
PushID(my_ptr);
Button("Click"); // Label = "Click", ID = hash of "node" + ptr + "Click"
PopID();
PopID();
- Tree nodes implicitly creates a scope for you by calling PushID().
Button("Click"); // Label = "Click", ID = hash of "Click"
if (TreeNode("node"))
{
Button("Click"); // Label = "Click", ID = hash of "node" + "Click"
TreePop();
}
- When working with trees, ID are used to preserve the open/close state of each tree node.
Depending on your use cases you may want to use strings, indices or pointers as ID.
e.g. when displaying a single object that may change over time (1-1 relationship), using a static string as ID will preserve your node open/closed state when the targeted object change.
e.g. when displaying a list of objects, using indices or pointers as ID will preserve the node open/closed state differently. experiment and see what makes more sense!

The short answer is that you need to pass an extra ID (for instance "Button##A" and "Button##B") to make it work, you can't have selectable objects with the same ID on the same ID stack.

And I just saw your pull request for TreeNodes, I'll have a look at it right now!

[Fenrir]

Awesome!

Does that also mean we can easily access "ImGuiCol_COUNT"?
Or is that even necessary?

In the test window it uses that variable to do the following:

Code: Select all

if (ImGui::BeginMenu("Colors"))
    {
        for (int i = 0; i < ImGuiCol_COUNT; i++)
            ImGui::MenuItem(ImGui::GetStyleColName((ImGuiCol)i));
        ImGui::EndMenu();
}

OK I updated GetStyleColName and added a custom GetStyleColCount, so you can do something like that to retrieve all color names:

Code: Select all

    for i = 1, imgui.GetStyleColCount() do
        print(imgui.GetStyleColName(i))
    end

Lastly, it seems tree node flags (TreeNodeEx, ImGuiTreeNodeFlags_*) are not implemented currently?

shouldn't the TreeNodeEx definition in imgui_iterator.h use

OPTIONAL_ENUM_ARG(flags, 0)
instead of
DEFAULT_ARG(ImGuiTreeNodeFlags, flags, 0)
?

I integrated your changes and updated the pearl script generating the bindings to include it too.

As a side note, it made me realize how overrides are currently binded and it's definitely not a satisfying solution, I'll try to find a better way to handle it.

[s-ol]

The short answer is that you need to pass an extra ID (for instance "Button##A" and "Button##B") to make it work, you can't have selectable objects with the same ID on the same ID stack.

And I just saw your pull request for TreeNodes, I'll have a look at it right now!

Ah, thanks for that extract, I saw the usage of "###someid" in the example but wasn't sure what the purpose was and didn't find the documentation.
I didn't think to check the FAQ somehow. Now that I am actually trying to use imgui, I agree that the documentation could be improved (quite a lot). Everything seems to be written down somewhere but you need to cross-check the header file, the example and the README at all times, which is kind of annoying.