Messages

The problem is that the gui is only told about the resize when receiving the Resize event (by the way, is the resize event send after recreating the window on windows?).

I can solve this particular scenario, but it won't be completely solved.
If you have a button in the gui and then use button->getParent()->getSize() you will still get the wrong size.

Passing the window to the gui again should solve this issue, so maybe I should document it somewhere that you have to call gui.setWindow(window) after calling window.create(...)?

Yes, the master branch on github contains the latest v0.6 snapshot.
But the download on my site just link to github so it will always be the latest version as well.

The change has been made by now.

Currently only TextBox is planned to be changed, so it is relatively safe.
Although it is not a complete reassurance as most changes were made without being planned, I think I came to the point where the api for v0.6 is finished. Small fixes can still occur but I don't expect any more major changes.

Edit: You might want to wait for the version that is going to be put online in a few minutes though.

I basically have to rewrite the form builder and I also wanted to rewrite the TextBox class.

I recently started a new todo list (because I lost my old one months ago). So these are the things that I still want to do.
- Find out why Slider2d isn't in the windows library
- Finish BabyBlue theme (I think only Tab images are missing, but there might be more)
- Add a White theme (will come with the new form builder)
- Write a new form builder
- Install files on correct places on linux
- Add a method to easily switch theme
- Rewrite TextBox
- EditBox with NumbersOnly should support commas

No, I haven't considered it yet.
I'll add it to the list of other widgets that I want to write in the future.

Once v0.6 is finished, I will again launch a poll to see which widgets are the most wanted. If more people are interested in the tree view element then it might get into v0.7 and otherwise it will be delayed even more.

Is it something that you wanted, or have you any plan to change that in the future?

It was the easiest way to do it I guess.
I'm not sure what problems I faced, but I eventually decided that it would be better to split the widgets.
It was also to avoid having too many functions in Tab, I tried to keep it simple.

And of course by keeping Tab and Panel separate, you can have just the tabs without being forced to have a panel right beneath it. And it gives you more liberty (think of an internet brower where there could be bookmark bar right below the tabs).

I'll try to figure it out.
But my priority is with the c++ version right now, so its going to take some time.

If I'm lucky then it is just now working because it can't find the libraries because of the 32bit vs 64bit issue. I'll try to install a 32bit OS on my laptop to avoid accidentally having the wrong libs. My cinnamon environment crashed a few days ago and I am now forced to work on gnome shell, so I was going to install another linux anyway (as the problem seems to be beyond repair).

Thanks for the link to the doc. I had only found the docs of the dllmap earlier which didn't specify in which file I had to put the lines which is why I ended up putting it in /etc/mono/config.

The Tab widget on itself only displayes those tabs, you will also need panels for what you want.

Here is an example:

Code Select Expand

#include <TGUI/TGUI.hpp>

void onTabSelected(const tgui::Callback& callback)
{
    // Get the tab that sent the callback
    /// WARNING: This might soon be changed to using tgui::Tab::Pẗr
    tgui::Tab* tab = (tgui::Tab*)callback.widget;

    // Access the gui.
    tgui::Container* gui = tab->getParent();

    // Show the correct panel
    if (tab->getSelected() == "First")
    {
        gui->get("FirstPanel")->show();
        gui->get("SecondPanel")->hide();
    }
    else if (tab->getSelected() == "Second")
    {
        gui->get("FirstPanel")->hide();
        gui->get("SecondPanel")->show();
    }
}

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "TGUI.Net Tabs Example");

    sf::Texture background1, background2;
    background1.loadFromFile("xubuntu_bg_aluminium.jpg");
    background2.loadFromFile("Linux.jpg");

    tgui::Gui gui = tgui::Gui(window);
    gui.setGlobalFont("TGUI/fonts/DejaVuSans.ttf");

    // Create the tabs
    tgui::Tab::Ptr tabs(gui);
    tabs->load("TGUI/widgets/Black.conf");
    tabs->add("First");
    tabs->add("Second");
    tabs->setPosition(20, 20);

    // Create the first panel
    tgui::Panel::Ptr panel1(gui, "FirstPanel");
    panel1->setSize(400, 300);
    panel1->setPosition(tabs->getPosition().x, tabs->getPosition().y + tabs->getTabHeight());
    panel1->setBackgroundTexture(&background1);

    // Create the second panel (copy of first one, but with different image)
    tgui::Panel::Ptr panel2 = gui.copy(panel1, "SecondPanel");
    panel2->setBackgroundTexture(&background2);

    // Enable callback when another tab is selected
    tabs->bindCallbackEx(onTabSelected, tgui::Tab::TabChanged);

    // Select the first tab and only show the first panel
    tabs->select("First");
    panel1->show();
    panel2->hide();

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();

            gui.handleEvent(event);
        }

        window.clear();
        gui.draw();
        window.display();
    }

    return 0;
}

Fixed. Thanks.

Let me check env paths again and will report back

Have you been able to solve it?

The error that "MinGW Makefiles" not being found is because the compiler path isn't in the PATH variable.
You just have to add ";C:\Program Files (x86)\CodeBlocks\MinGW\bin" to it and it should be fine.

where is the source: when i set from C:/tgui-master/ to : C:/TGUI-master/cmake/Modules

The source is in "C:/tgui-master/".

I just can't get it to work.

I created the app.exe.config, but it seems to ignore it. I had the configuration tag with the dllmap tags in it, but I got a "System.DllNotFoundException: csfml-graphics-2" error. (also tried leaving the 'configuration' away and only have the dllmap tags)

You just compile like this, right?

Code Select Expand

mcs -r:sfmlnet-window-2,sfmlnet-graphics-2,tguinet LoginScreen.cs
It seems to completely ignore the LoginScreen.exe.config file.

By the time I placed the lines back into /etc/mono/config, something has been messed up and I now have the error "System.DllNotFoundException: /usr/local/lib/libcsfml-graphics.so.2.1" again. From what I've seen so far, this error can be caused by basically anthing and I don't have a clue what I changed.
Edit: I think I already know what is causing this. I'm on a 64bit system and I installed 32bit libraries because MonoDevelop only works 32bit, while running mono in the terminal is 64bit.

So it is going to take some time to get a decent tutorial online if I can't even get it work myself.
And my first atempt to use it on windows has failed as well, but I guess I should just try with recompiling the lib with Visual Studio.

Alright, but could you point me to some documentation on how to do that?

I assume that this will be slightly different when compiling through the terminal or with MonoDevelop?

Its fixed by now by the way.

Damn, thats what you get when coding on linux with gcc 4.8 installed.

I'll revert that part of the commit. After searching, it seems like there are problems with MinGW and these function. They are not yet supported without patching the compiler.

Edit: I can't force everone to install an extra patch just to use tgui, so I'll just won't use the functions.

Everything seems to be working great, thanks a lot!

Grrrr, I did it the right way first, then I looked at the librocket documentation and saw that they did it the other way around, which is why I changed it.

Fixed.

Thanks for pointing out these mistakes. There fixed now.

The changes have been made. The function will now return true when the gui didn't handle the event and false when the event was consumed.

Currently MouseMoved is also consumed, but this can always be changed later. And it shouldn't be too much trouble to manually check if the event was a mouse move and then still executing your code instead of ignoring the event.

The current solution isn't perfect though. Key presses are also consumed when e.g. a button is selected.
It will require a bit more changes to fix that. In every widget, the functions that are used to tell the widget about the event would have to return a bool whether or not they actually handled the event.

But this should do for now.

Alright, those are more convincing arguments, I'll see what I can do.

I'm not sure about mouse move, they look like they do belong to the gui to me and should thus be treated the same way as mouse clicks.

If you want a setSize function then you'll have to write it yourself, I give up.

I did replace the addRow and addToRow with an addWidget function though. And I've also added a getWidget function.

You were right, it was a small change .
All code was already there, it just had to be moved to different functions.

I'm now going to take a look at Grid, that will be a bit more challenging.

handleEvent could return a bool, but I will have to change a couple of lines for that.
But I won't do that if your problem can be solved with only a few lines.

If the only thing you need to check is if the mouse is on top of the child window, then it could be done like this:

Code Select Expand

while (window.pollEvent(event))
{
    gui.handleEvent();

    if ((event.type == sf::Event::MouseMoved) && (childWindow->mouseOnWidget(event.mouseMove.x, event.mouseMove.y)))
        continue;
    else if ((event.type == sf::Event::MouseButtonPressed) || (event.type == sf::Event::MouseButtonReleased))
    {
        if (childWindow->mouseOnWidget(event.mouseButton.x, event.mouseButton.y))
            continue;
    }

    // Handle the event here
}

Or is there something that I don't know yet and does it require you to write a lot more code than that?
Because I'm willing to make the change if it makes some difference, I just don't want to do it to only replace a line or five in your code.

I think that some proposal should help to improve it.

Indeed. I only use my own gui for the form builder so users of tgui usually get more and different experiences.
Small things like the title of the child window being centered is only in tgui because it was suggested by someone.

And because I have many things to do, I usally rate the importance based on what people want.
I was planning to make the change in MenuBar, but it was somewhere on the bottom of my todo list (which is fictive as I lost my real todo list some time ago). But now that I know someone is interested in it, I'll make sure it gets done faster.

I've been thinking about that as well, so I will do that some day (I'll try to still get the change in v0.6).

But MenuBar is still a relatively new widget and there are more improvement that could be made. Like keeping it on the foreground (and not allow child windows on top of it).

Most widgets got added in one version and improved a lot in the next version, they just need some time to be tested and afterwards they are usually rewritten to make them like they should be.

I'll look into the possibility of returning a bool. It might be harder than it looks at first sight.

As a quick workaround, something like this should be enough. (I didn't try to compile the code, so it might contain small errors)

Code Select Expand

bool mouseOnGuiWidget = false;
if ((event.type == sf::Event::MouseMoved) || (event.type == sf::Event::MouseButtonPressed) || (event.type == sf::Event::MouseButtonReleased))
{
    std::Vector2i mousePosition;
    if ((event.type == sf::Event::MouseMoved)
        mousePosition = sf::Vector2i(event.mouseMove.x, event.mouseMove.y);
    else
        mousePosition = sf::Vector2i(event.mouseButton.x, event.mouseButton.y);

    std::vector<tgui::Widget::Ptr> widgets = gui.getWidgets();
    while (unsigned int i = 0; i < widgets.size(); ++i)
    {
        if (widgets[i]->mouseOnWidget(mousePosition.x, mousePosition.y))
        {
            mouseOnGuiWidget = true;
            break;
        }
    }
}
That might be a bit smaller than the piece of code you've written.

Also, why not use a union here?

You can't have Vector2f in a union. There was a union before with structs that just had an x and y member, but it seemed easier to use if it was a Vector2f directly so I removed the union.