1

General Discussion / Re: About TGUI 0.9-dev

« on: Yesterday at 19:37:47 »

the absolute buttons

What did you mean with this part exactly?
Any help to improve TGUI is always welcome, although the look of only buttons isn't going to have much value if the rest of the gui looks completely different.

2

General Discussion / Re: About TGUI 0.9-dev

« on: Yesterday at 16:56:09 »

I was already thinking about doing it for buttons as well.

Adding an outline for all text rendering in TGUI 0.9-dev might not be that hard as long as all texts within the widget use the same outline thickness and color. I'm not looking forward to adding functions to change the outline for each widget state (e.g. different outline for button hover, down and focus states). I actually asked the question because I started adding it to Button and found that it would take quite a while to do that for all widgets.

3

General Discussion / Re: About TGUI 0.9-dev

« on: Yesterday at 16:10:45 »

What happens in future if tgui texts have outline color?

In what kind of situation do you want support for text outline? Maybe it should only be supported in Label to start with?

4

Help requests / Re: unfocusing widgets

« on: 24 May 2019, 18:04:37 »

I have added a setFocusable function for all widgets. The updated TGUI version can be downloaded from github.

5

Help requests / Re: unfocusing widgets

« on: 24 May 2019, 17:13:35 »

Perhaps a simple boolean is good enough.

Perhaps. But I don't like that the user would have to do it for every widget he creates. There will always be cases where the default doesn't match what you want and where you need to set the value each time, but I was hoping to find a way on a slightly higher level (e.g. a single function to disable it on all buttons). Maybe something in the theme. Although that sounds similar to earlier TGUI versions where widgets were only focusable if it had a focus texture (with EditBox as exception which could gain focus even without such texture).

The biggest problem is always figuring out what would work best without actually knowing what people want or how they want it. So maybe I should indeed just add the simple boolean toggle to already allow it now and leave the better designs for later.

6

Help requests / Re: unfocusing widgets

« on: 24 May 2019, 16:46:51 »

The oldest version that I can check is TGUI 0.4 and even there it already responded to pressing space or enter.

What would happen after adding a key to addEventCodeTrigger? I don't see any use case except for this one so I might as well add a function to disable using space and return keys to buttons.

The issue is a bit related to the question of which widgets should be focusable. Some people might e.g. want to be able to focus a slider and use the arrow keys to change the value while other might want the tab key to skip the slider. So if I could find a good way to allow the user to decide which widgets can gain focus then you would be able to solve it by making the buttons unfocusable.

7

Help requests / Re: unfocusing widgets

« on: 24 May 2019, 14:13:26 »

Yes, something like that.

8

Help requests / Re: unfocusing widgets

« on: 24 May 2019, 11:34:06 »

Is there any option to disable auto focusing last pressed widget?

No. You can disable it visually so that the user can't tell the difference between focused widgets but that won't solve the issue.
I can see how what you ask makes sense for buttons, but not allowing focusing widgets isn't a good solution in the general case because then you would no longer be able to use edit boxes and similar widgets that rely on the focusing.

If you need some events to go to TGUI while other events should be handled in your code and there is some overlap in the events then you should probably just not call gui.handleEvent for events you want to handle. So basically call gui.handleEvent for every event except for the space key press event.

9

General Discussion / Re: About TGUI 0.9-dev

« on: 19 May 2019, 10:41:38 »

The renderer that I provide (not to be confused with widget renderers) will continue to use SFML for rendering, so it is unlikely that I will add any features not supported by SFML myself. I will of course open for pull requests if someone can add extra functionality.

It may also be possible to completely swap out the rendering code in the future and replace it with your own code, but at this point I can neither confirm nor deny the existence or nonexistence of a Backends/SFML/BackendRendererSFML.cpp file that would contain all actual rendering code.

10

General Discussion / Re: About TGUI 0.9-dev

« on: 19 May 2019, 09:48:03 »

May be you meaning milliseconds?

You are right, it should have been milliseconds (I edited the post now). That's what you get when quickly writing a post at the end of the day.

What happens in future if tgui texts have outline color?

In order to batch texts, I couldn't use the sf::Text class and had to implement what sf::Text does in my code. I removed things related to outline because it couldn't be set anyway, but I could add it back when support gets added (and it won't interfere with the batching as it is rendered together with the text). I'm still not sure how to give more control in rendering, this is one of the outstanding issues that I want to solve in TGUI 0.9.

Will this be configurable, meaning select the way tgui renders?

I'm not sure how the relation between widget and renderer will eventually look like. Maybe it will end up being the same as now but with the drawing code split in multiple functions inside the renderer, so that you just have to inherit the renderer and override one function to draw slightly differently. I've been too busy with the batch renderer until now to look into the other parts of the code that needs changing. And the batch renderer still needs some finishing touches before I can start on other parts of the code.

11

Help requests / Re: Cast Widget to Radiobutton?

« on: 17 May 2019, 18:21:36 »

Widget pointers are of type std::shared_ptr (tgui::Widget::Ptr is just an alias for std::shared_ptr<Widget>), so you shouldn't just cast them to raw pointers.You could call the .get() function of std::shared_ptr<T> to get a T* which you can then cast with a dynamic_cast (or with a c-style cast like you are doing), but it isn't meant to be used like that.
You can cast std::shared_ptr objects with std::dynamic_pointer_cast but to make things shorter widgets have a cast function that does it for you. So you can write something like

tgui::RadioButton::Ptr = widget->cast<tgui::RadioButton>();

There is actually a get function that takes a template parameter and does the cast for you, so what you want is as simple as

NewGameMenu->get<tgui::RadioButton>("radTom")->isChecked()

12

General Discussion / Re: Updating existing Picture widget

« on: 15 May 2019, 22:09:56 »

The texture became part of the renderer in 0.8, so you can use picture->getRenderer()->setTexture(...)

13

General Discussion / Re: TGUI and Unicode

« on: 07 May 2019, 22:30:39 »

TGUI uses sf::String on most places, which supports unicode, you just need to get the data into sf::String. If your data is UTF8 and stored in some array of "char" or "unsigned char", you should be able to use sf::String::fromUtf8(data.begin(), data.end()).

If you want to display special characters then you need to make sure to use a font that can render those characters. Maybe the default TGUI font can, but it is possible that it will just render squares in which case you need a different font.

14

General Discussion / Re: Triggering action from another thread

« on: 05 May 2019, 09:51:09 »

You can't access the same SFML or TGUI objects from multiple threads at the same time, it is up to you to do the synchronization. One way would be to use mutexes around the TGUI objects you access, but that will likely decrease performance as you would have to lock practically everywhere in the main thread (locks around both event handling and drawing and anywhere else where you access TGUI widgets). So the best way is probably to only let the main thread access TGUI and get your data to the main thread somehow. How to do this is of course not related to TGUI.

I don't have much experience with syncing between threads myself, other than on a windows-only project that uses the Windows functions like PostMessage, SetEvent and WaitForSingleObject.
A pure c++ alternative to SetEvent/WaitForSingleObject would probably be to have a mutex around a shared variable. Every frame (or every X milliseconds) you lock the mutex, check the variable and unlock the mutex again. In the other thread, when data is read from the card, it locks the mutex, writes the data in the variable and unlock the mutex again.

15

General Discussion / Re: Re-using RenderWindow

« on: 03 May 2019, 18:54:42 »

I am bit confused by the tgui::Ptr's. They cannot be C++ class pointers, since I cannot do new/delete on them. But still, I have to use -> operator, not dot(.).

tgui::Widget::Ptr is simply a typedef for std::shared_ptr<tgui::Widget>. So they are pointers, but memory is managed automatically so you don't have to delete them.
In example code I always use e.g. tgui::Button::create() to create the widget, but std::make_shared<tgui::Button>() would work just as well (although the create function may take extra optional parameters and it is shorter to write).

I am worried to create memory/resource leaks.

Removing widgets from the Gui and releasing memory are 2 different things (although in many cases they happen at the same time). Because widgets are stored as shared_ptr objects, the memory is only released when all pointers to it are gone. The gui object has pointers to the widgets it contains (and the group has pointers to the child widgets inside the group) and you may store pointers to widgets in your own code. If you remove the group from the gui or destroy the entire gui, the widgets will automatically be destroyed with it unless you were still storing these widgets somewhere in your own code.

If you put one group in one gui then you indeed don't have to do setVisible(false) as you are destroying the group when destroying the gui. My suggestion was however to only have a single Gui object to which both groups are added. Then you have to hide one when showing the other or you will be seeing the widgets from both groups at the same time.
You can of course keep using a Gui per screen. The Gui was intended to be constructed only once per window, but currently creating a new Gui object probably takes less time than creating a widget, so there shouldn't be a problem with recreating it every time.