Messages

I can't reproduce it here. Could you show the lines where you create the knob? Maybe the problem is specific to the minimum, maximum, start rotation and end rotation that you are using.

It is actually not inconsistent with c++, but I understand why you would think it is. In c++ there are 2 options for setting a layout, one is by passing an x and a y value while the other one is setting a string. The loading from file only provides the string representation, which even in c++ require the braces. Also when doing widget->setPosition(x,y) you are actually calling a shortcut to widget->setPosition({x,y}) (which is by itself a shorter notation for widget->setPosition(tgui::Layout{x,y})) so it is even closer related then you might think.

The only valid options are ("_","_") and "{_,_}". I think the reason I went for braces inside the string is because brackets are also used in the math expressions and it is thus easier to parse with braces. Maybe I could drop the braces and accept "_,_" as valid input, but the braces will always be needed when writing something like "2 * {20, button.height} + 50". But I can think of that later, for now only those 2 ways are supported.

The reason why the result is different is because "_,_" will silently fail. Parsing the string is done in the layouts themselves (so the code is not specific to loading from a file) and because it is sometimes intended to silently fail I cannot throw an exception there to warn you that the parsing failed.

"_, _" never worked, you need to add braces: "{_,_}".
Could you provide an example of where it goes wrong with ("_","_")? Because there is a simple test in TGUI which indicates that the loading layouts like that is still working.

Including the main header will always work because it contains everything you could possibly need.

Including only the headers that you need will indeed reduce the compile time, but there is no guarantee that this will work. Suppose I would forward declare the Theme class in the Widget.hpp header so that the theme class does not has to be included everywhere (which leads to faster compilation). Then trying to use the Theme class in your code will give errors because the declaration is missing. Every file that actually needs the Theme class would have to manually include Theme.hpp. So although only including the needed headers will lead to better compilation performance, you might need to include several "internal" headers manually as well for it to work. In TGUI this isn't such a big problem, but in other libraries if you are unlucky you have to include a lot of extra headers just to make the header work that you wanted.

Also when I change the file names or when I forward declare different classes you might have to change the includes in your files. When including the main header nothing would have changed in your code. So both have advantages and disadvantages.

You should never have to delete the folder.
Actually because you ask this question I looked at it again and I now realized why you were getting the error (because earlier I didn't understand why it happened). You are including TGUI/Label.hpp which is a file that no longer exists, it became TGUI/Widgets/Label.hpp. So it is just because you are including a file that doesn't really exist anymore. Since all TGUI examples just tell you to include TGUI/TGUI.hpp, including another file is at your own risk.

Every time a change is pushed to github, TGUI is automatically compiled with 5 different compilers (2 on linux, 2 on windows, 1 on mac), so a compiler error is the last thing that I expect to see

/usr/local/include/TGUI/ClickableWidget.hpp:90:29: error: ‘virtual tgui::Widget::Ptr tgui::ClickableWidget::clone()’ marked ‘override’, but does not override
         virtual Widget::Ptr clone() override

This error occurs because there is a "const" missing behind the function, but not only is there a "const" in the latest version, it is also located on line 96 and not line 90 like the error suggests.

I guess you had a different TGUI version installed before compiling the latest snapshot. I would delete all tgui folders that you have (especially /usr/local/include/TGUI/) and try installing the latest version again.

Edit: Just deleting the /usr/local/include/TGUI/ and re-running "sudo make install" should be enough. Looking closer at the errors I notice that you have some old files remaining which were not overwritten by the new version because the new version has these files in a different subfolder.

I have a very busy week myself, so I will take a look at it next week.

No you can only set the opacity. If I were to add a setColor function to widgets I would also have to define what should happen with colored widgets as opposed to textured widgets. Before there was a setOpacity function there was a setTransparency function which had several issues, when I once tried adding a setColor function back then it made those issues even bigger making it practically impossible. I guess most of these problems will have been solved if I implemented it similar to setOpacity though, so maybe I could give it another try. But it won't happen anywhere soon.

Knob also has a minimum and maximum, the start and end rotation only tell something about where the min and max are graphically, the value goes in the range of min to max which is 0 to 360 by default.

If you add this:

Code (cpp) Select Expand

knob->setMaximum(128-8);
then your scrollbar and knob will have the exact same value range.

The "scrollbar->setValue(( 128 - 8 ) - (value / 3));" code that you had would e.g. become

Code (cpp) Select Expand

scrollbar->setValue((128 - 8) - value);
after this change.

I don't have the time now to give the correct formula, but like this it shouldn't be too hard to find it yourself.

I have added the getRatio function (and a getFixedSize function) in the latest version.

Either you wait and I will try to add such a function later today, or you can just add it yourself.

The libraries have to match the compiler. And it not only the version, the settings have to be correct as well. There are settings which if you change them, you are required to recompile all libraries with that setting changed as well. That is one of the big downsides of programming with c++ in windows (at least with visual c++ or mingw, I don't know anything about borlands). C is more compatible between compiler versions but in VS2015 they even broke the C ABI meaning that even most C libraries also have to be recompiled (but this is a one time change to get their universal apps so at least they have an excuse for that).
On linux (and probably on mac too) you can mostly combine any compiler with any settings (but you still need separate 32bit and 64bit binaries). This together with having standard paths (you don't have to tell the compiler where to find the headers and library files) is why I prefer working on linux. Of course linux has its own problems (like the linker by default not looking in the directory where custom compiled libraries are installed by default), but I still think that they are less frustrating than on windows. I'm sure there is a good reason why it is incompatible on windows with every version and that this reason probably has to do with decisions made a long time ago but I still find it stupid that other systems can manage to keep library compatibility while windows just can't.

But are you still using VS2015? Because then the libraries are still not compatible with the compiler.

VC12
VC14

That is not going to work. On windows the c++ compiler you use for your program has to be the same one as all your libraries. You can't combine libraries meant for different visual studio compilers. It could lead to random behavior so this might be your problem.

I realize now what you were talking about with making Container templated. Maybe inheriting from Container isn't such a good idea, it should remain a generic class that works with just Widget. Also it isn't very user friendly if the user has to manually create those TableRow instances.

You don't need templates to accept only TableRow::Ptr, just make the parameter a TableRow::Ptr instead of a Widget::Ptr.
Templates and inheritance are basically opposites, if you need templates while writing the Table class then you are doing something wrong and should reconsider what you are trying to do.

Tried "std::static_pointer_cast" but doesn't work( it compile, but have no effect)

It is the correct way and if it compiles with TableRow but not with Widget then there must me a mistake somewhere with the function you are calling. There is one thing that could cause stange results though: did you forget to add "typedef std::shared_ptr<TableRow> Ptr;" to the TableRow class? If you forgot that then TableRow::Ptr is actually the same as Widget::Ptr which is why the cast wouldn't make any difference.

It's already looking good. But I would personally add a line below the Name and IP because now it looks like a multi-column listbox where the first line is selected. I'm not sure if this is the case or not, but it is best that the first line (the one with Name and IP) is handled separately from all the other lines. That would allow adding customization options in the future (making the column names bold or giving them a bigger text size).

Code (cpp) Select Expand

table->setFontSize(18, mGui.getFont());
in order to everything to work properly.

It would be best that this are 2 different functions, setTextSize and setFont. When setTextSize is called and there is still no font nothing happens but the size is stored. When setFont is called (or when setTextSize gets called while there already is a font) then it should do what you currently do in setFontSize. But I can easily make changes like this myself when it is finished, so it doesn't matter that it requires such a function now.

if to set the table row height to 'fixed' or 'auto' and if is fixed to set all the widgets size to that size, and if auto, the table to check what is the biggest height and apply to all rows.

Another option that the user might want is having all rows fixed but just have that one row a bit bigger. But I guess the 'fixed' and 'auto' options would be more common than this so it is enough to have them.

mWidget->draw(*target, states);

The draw function (which comes from sf::Drawable) is not meant to be called directly. You have to write the line like this:

Code (cpp) Select Expand

target->draw(mWidget, states);

BoxLayout which contains only 1 widget

it would be nice if you would add padding properties to BoxLayout

Why does it has to be in a BoxLayout when there is only one widget? The BoxLayout is created to place widgets next to each other or below to each other, not to store single widgets.

The (100,100) is the default size of a panel on which is what BoxLayout is based on. Normally you know the height of a VerticalLayout because it is a fixed value. One thing you could do is create an empty label which you give a font and a text size and then use label->getSize().y as the height of your VerticalLayout. Or you could just not use any of these BoxLayouts at all and have full control over the position and sizes of everything, although that would make your code more difficult.

The idea sounds good enough, if it works then just do it like that. But can't Table be a VerticalLayout if it only has to put the lines below each other?

Just make sure to use the latest version and not 0.7-alpha2 as that release has a serious bug in the BoxLayout class.

Feel free to send me the code when you have a working table class, I think several other people will be interested in having such a class available in tgui.

While writing the example I actually figured out that you can do it without any change in TGUI with exactly the same amount of lines of code:

Code (cpp) Select Expand

#include <TGUI/TGUI.hpp>

tgui::ListBox::Ptr popumMenu;

void popupMenuCallback(std::string item)
{
    std::cout << item << std::endl;
}

void rightClickCallback(tgui::Gui& gui, sf::Vector2f position)
{
    popumMenu = std::make_shared<tgui::ListBox>();
    popumMenu->addItem("Option 1");
    popumMenu->addItem("Option 2");
    popumMenu->addItem("Option 3");
    popumMenu->addItem("Option 4");
    popumMenu->setItemHeight(20);
    popumMenu->setPosition(position);
    popumMenu->setSize(120, popumMenu->getItemHeight() * popumMenu->getItemCount());
    popumMenu->connect("ItemSelected", popupMenuCallback);
    gui.add(popumMenu);
}

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "TGUI window");
    tgui::Gui gui(window);
    gui.setFont("TGUI/fonts/DejaVuSans.ttf");

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

            // Check if there is a pop-up menu
            if (popumMenu)
            {
                // When mouse is released, remove the pop-up menu
                if (event.type == sf::Event::MouseButtonReleased && event.mouseButton.button == sf::Mouse::Left)
                {
                    gui.remove(popumMenu);
                    popumMenu = nullptr;
                }

                // When mouse is pressed, remove the pop-up menu only when the mouse is not on top of the menu
                if (event.type == sf::Event::MouseButtonPressed)
                {
                    if (!popumMenu->mouseOnWidget(event.mouseButton.x, event.mouseButton.y))
                    {
                        gui.remove(popumMenu);
                        popumMenu = nullptr;
                    }
                }
            }

            // Perhaps we have to open a menu
            else if (event.type == sf::Event::MouseButtonPressed && event.mouseButton.button == sf::Mouse::Right)
            {
                rightClickCallback(gui, sf::Vector2f(event.mouseButton.x, event.mouseButton.y));
            }

            gui.handleEvent(event);
        }

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

Are you using Visual Studio? I already found some time to add the right click callback, but I just realized that it relies on the optional parameters in the signal system which are not supported in Visual Studio. So if you are using a different compiler then I will just leave it like it is now and write an example based on this, otherwise I'll add some more code to support using it with the tgui::Callback class as well.

I'm not making as much progress with v0.7 as I wanted, even now it looks that as soon as I get a lot of time again (next year July/August) I will be spending multiple weeks rewriting stuff instead of adding new widgets.

The main problem with resizing has always been that I want the cursor to change, but there should be some way for the user to set which cursor he wants or whether he doesn't want it to change. I haven't taken the time yet to think about a proper way to implement it. And I'm also kindof waiting for this before I even consider starting.

There still hasn't been any progress on the right click menu.
The best I can do for now would be to add a right click callback with the mouse position and possible the widget below the mouse as parameters. You would have to create a ListBox in this callback function which serves as popup menu and remove it yourself when clicking somewhere else on the screen afterwards. I'll have a bit time in one or two weeks, it the above solution is enough then I can try to add it (and give a small example code on how to use it to get the popup menu). But a real popup menu won't arrive anywhere soon.

TextBox indeed seems to be missing a few lines of code in setOpacity, I'll fix this later today.
Edit: Fixed

It seems like this bug has already been fixed in the latest version, you can download it from github. You have to build it yourself with CMake.

You made me realize that the latest version on my download page is v0.7-alpha2. I will add a link to the source code of the latest snapshot as well, because there have already been quite some bug fixes.