Messages

Could you clarify a bit what the situation is and what you expect?
It is impossible to draw outside the window, you always need something to draw on. (I know it is possible to draw directly to the screen, but that is not something in the scope of SFML or TGUI)

They need to have the same TGUI version as you are using. They don't have to build it, you should include the .so files with your application (similar to handling .dll files on windows except that .so files aren't looked for in the current directory and you have to mess around with the rpath of the executable to make it work).

Of course the change that I made will be included in the next tgui release. So once 0.7.4 comes out you could download and use that version. Then you no longer have this special version.

But even after the 0.7.4 release you shouldn't rely on people installing that version manually, you should always try to ship the right dependencies with your application. So in the end it shouldn't matter whether you have a modified or an official version of tgui.

Distributing an application on linux is quite complex and requires a lot of experimentation. If you intend to do so then I suggest you read the following post that I once wrote: https://en.sfml-dev.org/forums/index.php?topic=20727.msg148895#msg148895
Or maybe you can use a different method, e.g. using snaps. Or bundle all the source code including sfml and tgui with a makefile and have it all build on their pc.

But these are things to worry about when the application is finished.

Although it is good that you have it solved, your solution to the problem is a bit wrong. What you have to do when you get the error is described here: https://tgui.eu/tutorials/v0.7/linux/#possible_error

If you installed libtgui-dev from the package manager again then you now likely have two versions on your pc, one in /usr/lib and one in /usr/local/lib. If I understood your situation correctly then you should actually be able to uninstall libtgui-dev from the package manager again and everything should still work fine.

Reinstalling the package probably caused the system to run ldconfig for you which is why it solved the error.

The issue has been fixed. You will have to download the updated version and build the tgui libraries yourself.

This seems to be a separate issue. I have been able to reproduce it, I'll try to fix it soon.

Are you using TGUI 0.7.3? Because this sounds like a bug that I fixed in that version.

Having a gui in each entity misses the point of what the gui is about. You should be creating panels inside the entities, not guis. You should store a single Gui instance in a similar way that you are storing a single RenderWindow and that you try to attach the panels to the guis in a similar way as how you manage to "connect" (handle events and draw) your entities to the window.

I was going to make the Gui copyable to not arbitrary limit you but I just found a reason on why I shouldn't make them copyable that I think is good enough and probably was the reason why I designed the code like this in the first place. If the gui is used like intended then making it copyable allows some very hard to spot issues when your code is wrong. If you forget to pass the object by reference and make a copy instead then your code would no longer work as intended. Calls to e.g. handleEvent would be done on the wrong gui. These are difficult issues to find because stuff just doesn't work in complex code but everything is fine in any minimal code. I vaguely remember such an issue.

I also can't make the handleEvent function from Panel public because it looks like it is the Gui which maps events from window to world view. This code can't be moved to Panel because it must only be done once on a place that can't occur inside the hierarchy (Panels could be nested and thus the code would be run multiple times).

TGUI is not made for what you intend to do. The code is designed to have a single Gui where interaction is handled. It is made for menu screens and static HUD, not for being part of your entities. I'm afraid you will either have to adapt your code so that it works with a single gui or else simply not rely on TGUI to do these things.

The gui should take care of attaching the system clipboard when you pass an sf::RenderWindow as parameter to gui.setWindow.
The only two reasons why this would not be done that I can think of is when you run the code on linux or mac or when you set a RenderTexture instead of a RenderWindow. But neither should be the case here.

You may want to try calling the following function in your own code and see if it helps:

Code (cpp) Select Expand

tgui::Clipboard::setWindowHandle(yourSfmlRenderWindow.getSystemHandle());

Do you set an sf::RendererWindow to the Gui in your code?

I realized that the clipboard won't work if you draw to an sf::RenderTexture as it needs a window to work.

It should work out of the box, but it hasn't been tested for a long time (only briefly when the feature was added).

First of all make sure you are copying plain text data only by copying some text from notepad. Although I doubt it is the case, I think it is technically possible for a program to only put the formatted text in the clipboard without including the plain text.

What OS and compiler are you using?
Edit: could you also show a minimal example code that I can just copy-paste to test with?

I still don't see what you gain from copying it. You would save one line of code as you wouldn't have to call gui.setWindow again, but that's about it.

The fix has been made in the master branch on github (download zip).

Also, as a side note, I needed to set the load an external font myself to make the textbox work... I don't know if this is normal or if the textbox is suposed to have a default font active when no font was selected.

Looks like you found another reason on why the Gui class is useful. All widgets added to the gui come with a build-in font.

You don't have to manually set the font for each widget btw, it gets inherited from the parent. So if you set the font of a panel then all widgets inside that panel will get that font as well.

I'll make sure it gets fixed in the next hour. You will have to rebuild tgui yourself afterward though.

A workaround for now is to call dialogBox->setPosition(1,1) before calling dialogBox->setPosition("parent.width / 4", 0).

I just figured out that the bug isn't even in the layout system. It is specific to TextBox (and maybe a few other classes with similar code). It's basically a caching issue.

I told you what to write in my last post: you don't need "parent.top", you just need a 0.
If your panel is located at position (10, 20) and the widget inside the panel is placed at position (30, 40) then on the screen the widget will appear at pixel (40, 60). All positions are relative to the parent, that is why the top of your text box should be 0.

The bug is that somehow the expression is not being evaluated when there is no expression. When mWindow->getSize().y is 600 then mDialogInterface->getPosition().y will be 450 and thus parent.top should be 450. The bug is that it is 0. When you put an expression into the x position then it suddenly gets interpreted correctly and the dialogBox is placed on y position 450 instead of y position 0.

What you need is the following:

Code (cpp) Select Expand

dialogBox->setSize("parent.width / 4", 0);

That is indeed a bug in my layout system, but apparently not how you are expecting it. It turns out that the behavior of "parent.left + 1" is more correct than the one for "parent.left". Positions are already relative to the parent, so to put a widget in the top left corner of its parent you must give it position (0,0). You are placing your dialogBox far below the screen in your code.

Also, as a side note, I've tryed receiving input from the panel via panel->handleInput(const sf::Event& event) but the compiler tells me that the function is protected. Is there any other way of doing this without relying on guis (aka, in my case, using panels)?

Apparently not. It seems like you will have to use a Gui if you need to handle events.

TGUI has an internal clipboard that allows copying and pasting from one edit box to the other by just selecting text and pressing ctrl+c and ctrl+v.
On windows the system clipboard is also accessed so that you can copy things from other applications. On linux and mac accessing the system clipboard it is currently not supported so you can't paste things other than what you copied in tgui.

Although you could pass events to widgets directly by e.g. calling button->leftMousePressed(mousePos) you would be better of having the widgets in a Panel and using panel->handleEvent(event). Containers like Panel have the same functions as you would find in the Gui class, with the difference that Panel also has all the functions inherited from the Widget class.

If you have no events and no need for animations then I guess you could indeed use the code without the Gui class. But do you really need a gui library then?

You are correct about that widgets should not rely on the existence of a global gui, and then don't.
The main use of the Gui is simplicity, so that you only need to do one function call for handling events and one for drawing. Technically I don't think there is any dependency on the gui and you should thus be able to use all widgets directly. But then you would have to manually pass the right events to the right widgets, keep a clock to update e.g. the flickering edit box caret and draw all of them. Having a Gui object which encapsulates that is easier.

There is no technical reason why you can't copy it, but why would you? If you have multiple guis then you have to call handleEvent and draw on each of them which is more work. Everything can be done more simply by having different panels inside a single gui. And even if you had multiple guis, would you really copy the first one instead of just creating a new one?
The gui is the topmost object that is tied to the window and will handle all interaction (events and drawing) with the rest of the objects. So I don't see a reason on why it should be copyable.

The above reasons are actually only enough to justify why I don't remove the non-copyable property, I don't think I would have made the decision to arbitrary limit the possibilities. Maybe that piece of code is just almost as old as the library itself and originates from a time where the Gui inherited from sf::RenderWindow. I would have been forced to make it non-copyable as sf::RenderWindow is non-copyable. Nope, the code was only introduced halfway 2014 during a major rewrite of the entire gui, so there is no reasoning found in the commit message. So I'm just as clueless as you on why it is like this

The Gui is not copyable because it is not meant to be used like this. You are only supposed to create a single Gui instance per windows.
What you probably want is the Panel class (or Group class in 0.8-dev). You would add those panels to the gui when you need them and remove them again when they are no longer needed. The widgets (progress bars or the vertical layout) would be added to this panel instead of to the gui.

Maybe you called removeAllWidgets on the wrong widget? I can't imagine any other case, the removeAllWidgets will definately get rid of all child widgets.

edit: or your kept a list of widgets in your own code which didn't get cleared and populatePanel inserted the widgets into that list as well

There shouldn't be any way for an event to trigger multiple times unless you called the connect function multiple times, so make sure you aren't doing that.
Having it depending on the duration of the function looks really weird. Are you certain gui.handleEvent is only called once for each sfml event?

The debugger should show you that it crashes because gui_ProgressBarHP is a nullptr.

The gui doesn't know about the existence of the progress bar. It only has the panel as child widget while the panel in turn has the progress bar as child. So you would have to get the progress bar from the panel:

Code (cpp) Select Expand

gui_panelInfo->get<tgui::ProgressBar>("info_health");

Alternatively you can pass "true" as second parameter to the get function. This will search for the widget recursively.

Code (cpp) Select Expand

gui.get<tgui::ProgressBar>("info_health", true);