Messages

The problem was that Tab.setFont (which gets called during winEditConfig->add) did not reposition the text.

To work around the issue with your tgui version you can just move that line before all the others:

Code (cpp) Select Expand

winEditConfigTabs = theme->load("tab");
winEditConfig->add(winEditConfigTabs);
winEditConfigTabs->setTextSize(text_size);
...

Or you could download the latest tgui version and compile it with CMake.

Apparently Tab was not tested with a custom text size. It should work when you remove the setTextSize call.
I'll see if I can find where it goes wrong in my code.

I saw that if the edit boxes are added to a panel, these inherit the enabled / disabled state of the panel.

This is only partly true. Technically they don't inherit it so if you check whether the edit box is enabled or disabled it will still report that it is enabled even though the panel to which it was added is disabled. But all events travel from parent to parent (gui -> panel -> edit box) so when the panel is disabled no events will reach the edit box.

I saw that you can make a class that inherits the EditBox and add a method

Creating a custom widget that inherits from EditBox is one way to solve the problem, however the tutorial for custom widgets is not written yet and there are a few small catches so this may not be so easy.

It may not be the best way, but I think just looping over all edit boxes is probably the easiest way. The enablePanel function would be similar.

Code (cpp) Select Expand

void disablePanel(tgui::Panel::Ptr panel)
{
    panel->disable();
    for (auto& widget : panel->getWidgets())
    {
        if (widget->getWidgetType() == "editbox")
            std::static_pointer_cast<tgui::EditBox>(widget)->getRenderer()->setTextColor(color);
    }
}

Yep, that is indeed the code that you need.
The renderer always gets created together with the widget so you just have to call getRenderer to access it.

About the multi-column feature, it has been requested several times with small variations. I guess I will really have to try to add it in 0.7, even though it will be a lot of work to make the widget fit all different use cases.

I think that the first request already dates back 1.5 or even 2 years ago, the github issue is almost a year old as well.

I'll try to make sure that it gets priority and should make it in 0.7-RC, I can't keep delaying it.

This is most likely caused by a bad graphics driver, you should try to update it.

The two other times something similar was reported (see here and here) the outcome was that the problem was only on one pc/graphics card. So other than changing your drivers I don't think there is anything that I can recommend.

Ok, I understand now.
The most important part is this: "3500fps vs 2500fps". FPS scales non-linearly. This means that having such big difference means nothing. If your fps was 60 then the same change might have changed it to 59.

To really see how much difference there is you would have to create so many text objects that you get about 60 or 30 fps and then change them to Labels. And then instead of measuring fps just measure the time per frame (which is not reliable while getting thousands of fps).

A certain performance loss is to be expected. Label is so much more than a simple sf::Text, although just drawing it is optimized so that there is practically no difference. The only thing that Label::draw does more than Text::draw is executing a few if statements to skip parts of the drawing, it will only takes a lot more time when you e.g. set a background color or disable auto-scaling. This part can't be optimized much more.

There are also other parts in the gui where you might loose some performance, e.g. every frame the elapsed time will be updated and all widgets will receive an event for this in case they need to do something. Things like these can also take some time. The goal of the gui is to be simple, not to be the most performant one (although functions like the draw function which are executed a lot are usually more optimized than e.g. loading widgets).

To summarize: Less performance is expected but the big fps drop says nothing about how big the performance difference really is.

I'm not sure what "frame delay" you are talking about.
I didn't really understand what you are saying in your first post. You talk about 1000 fps, but you don't compare it to anything. So I can't tell if it is a good or a bad thing.

Perhaps you should try to reformulate what you were saying but with more sentences and a bit more explanation, maybe I'll understand what you are talking about then.

I don't see a question. Is part of the post missing, since you talk about "this example"?

To be absolutely clear: you need the Button.hpp (and the other headers) from the tgui-alpha2-Win64-VS2015-custom.zip file that I send.

I can tell that the file you are showing is not the correct one, because the one in that zip has the following where the class declaration starts:

Code (cpp) Select Expand

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// @brief Button widget
///
/// Signals:
///     - Pressed (the button was pressed)
///         * Optional parameter sf::String: Caption of the button
///         * Uses Callback member 'text'
///
///     - Inherited signals from ClickableWidget
///
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
class TGUI_API Button : public ClickableWidget

Widget properties were indeed not reset when reloading. You should download the latest version from github and rebuild the library with cmake.

Should i post this new feature request somewhere so you can keep track of it when you next look at doing a new version?

No, it has already been added to my private todo list (actually just some random notes in a text file instead of a useful list, which is why it isn't public).

When I start working on the beta version I will go through that file and see which things I can do. But I doubt it will be done in the beta version, I think this can be added without breaking the api and it could thus even be added after 0.7.0 has been released.

Button.hpp line 44 is in the middle of a comment in the file: https://github.com/texus/TGUI/blob/master/include/TGUI/Widgets/Button.hpp#L44

Make sure that you use the include folder that I included in the zip file and not some other version.

These things are not possible and don't look like they can be easily added.

I'll add it to my todo list but don't expect it anywhere soon. My university semester starts tomorrow and I don't think I will have much time to work on tgui until July next year. I'll always find time for bug fixes but don't expect any new features.

Oh you wanted tgui 0.6?
The load function is from tgui 0.6, I gave you libraries and header files for tgui 0.7-alpha2.

Since the Config.hpp in your files states 2.3.1 instead of 2.3.2 I couldn't build it automatically together with the rest so it took a bit longer.

The files can be found here: https://www.dropbox.com/s/87z36lz145pew8c/tgui-alpha2-Win64-VS2015-custom.zip?dl=1

The TGUI version is newer than the tutorials and documentation on my site. The website will be updated in a few hours or in worst case tomorrow. But the only thing you should keep in mind until then is that you have to use setFont instead of setGlobalFont, you probably won't notice any difference.

I actually have no idea how to do it inside VS, I build my libraries from the command line (with a batch script).
I have to recompile TGUI anyway, if you send me your SFML libraries then I'll build TGUI here with those sfml libs.

One or two of the three is build in 32-bit while the other is 64-bit: your project, tgui, sfml
They all have to match, if tgui is the 32-bit one (it builds as 32-bit by default) and you are using 64-bit for everything else then you should check the settings in Visual Studio when you open tgui.sln and see if you can select Win64 somewhere.

Then those header files are from SFML 2.1 and not from 2.3.2. The cmake script is only compatible from sfml 2.2 onwards.
So you should remove these headers (or temporarily move them if you still need them) and let tgui find your sfml 2.3.2 headers.

And the Config.hpp file in those headers is the one from SFML 2.3.2 (the version is defined on top of that file)?

Could you check the value of SFML_INCLUDE_DIR in cmake?
I'm not sure if the value shows up in the cmake gui when finding it fails, so perhaps you should add the following line in TGUI/cmake/Modules/FindSFML.cmake at line 348 where your error is coming from:

Code Select Expand

message(STATUS "SFML_INCLUDE_DIR: ${SFML_INCLUDE_DIR}")

I suspect that folder is going to be a wrong SFML directory. The SFML version will probably be 2.0 or 2.1 instead of 1.x as the error describes, but this has to do with a bug in FindSFML.cmake that was recently (partially) solved in SFML but I haven't copied the new file to TGUI yet.

The problem with binding a function for each callback is that not every widget has the same callbacks. When trying to bind a callback that the widget does not has an exception would be thrown. So you either have to do it per widget type or you would have to add a lot of try-catches to try and bind every trigger.

You could also do things like putting all triggers in a map with the widget type as key so that you can easily bind the callback, but you would still need to fill the map with contents somewhere.

So binding all triggers would take much more work then it should.

Anyway, this doesn't even matter to neither of us right now. It will still take 3 years or so before support for code like that could be dropped, I'm sure that I will have made some decision by then.

The function would take a boolean as parameter, so you would disable it with setAutoScroll(false).

Hmm, that gives me something to think about for the next tgui version. The new callback system was not designed for handling multiple triggers in the same function. I will add an "all" callback trigger in v0.7 so that this can still be done. But once the legacy part of the system gets removed (which would not happen before 0.8 which is still many many years away anyway) then there would no longer be a way to know what trigger caused the callback. I'll make sure to keep this use case in mind when I eventually remove the Callback class.

It's a bit of a hack but you can do this:

Code (cpp) Select Expand

m_pWidget->bindCallbackEx(&WidgetBase::f_callback, this, 4095);

Triggers can be combined so they are numbered 1, 2, 4, 8, 16, etc so that binding 3 would result in binding both 1 and 2. The 4095 is just (2^N)-1 with N big enough so that it includes all triggers.

But why are you trying to bind all triggers? You are going to discard almost all callbacks in your f_callback function anyway since you don't need to know about them. I'm asking because in TGUI 0.7-dev a hack like this is not possible and I'd like to know if the new callback system covers your use case.