Messages

Both overriding or using signals could work. I think of overriding as defining the behavior of the widget itself whereas signals are used to inform some external object that the event occurred, but you can use whichever looks easiest.

For the dragging I think it might be easier to work with overriding functions, as you can implement leftMouseButtonNoLongerDown() to know when the mouse was released anywhere on the screen (which you need to know after the mouse was previously pressed on top of the box).

I need to handle passing the event to the child widgets even if I inherited from a widget which normally has sub-widgets?

Yes, but this is easy to do. By overriding the leftMousePressed function you are replacing the existing implementation (which passes the events to the child widgets). You can simply add the following line inside your leftMousePressed implementation to execute the existing TGUI behavior (and then you have your own custom code before or after that line).

Code (cpp) Select Expand

Panel::leftMousePressed(pos);
One of the things that get executed by calling that line is calling processMousePressEvent at Container.cpp#L901 which does the actual work of finding the child widget below the mouse and passing the event along.

So I see "panel" is a "container" but not a "SubWidgetContainer", so I guess it also "does not forward"?

Any Container-based widget will forward events (unless you override its functions to do otherwise). The quote is about the difference between SubwidgetContainer and Widget, where Widget itself doesn't forward anything.

SubwidgetContainer is a special class, is uses a Container internally, but it acts like a regular widget (you don't get access to its children). It's purpose is hiding the Container implementation. If you don't care that the user of your custom widget can access it's internals then you are probably better off inheriting from a class that inherits from Container (like you are doing by inheriting from Panel, which falls in the "Approach 1: extending existing widget" category).

That was the alternative approach that I was also thinking about. I ignored that option earlier because I thought you wanted some quick way to convert an entire form.

The latest TGUI 1.0-dev build now has such a button next to the position and size values.

Implementing it might not be that hard, but I'm not sure how useful it is for any non-trivial forms.
There would be many situations where one or two widgets do need a fixed value, e.g. a sidebar panel that has a fixed width (while having a relative height and relative position).

An issue with just making everything relative is that the text size won't automatically scale, so the offset between a label and an edit box below it would change and they could start overlapping when going too small. The text in the edit box itself will also no longer look correct when you just start changing the height of the edit box based on the window height.

While I don't know what the best way is to make a responsible form, I don't really believe that just making all positions and sizes relative is a good method unless you only display a few buttons. Changing the view of the gui might be more useful in some cases where you need simple scaling. That being said, I'm not against adding some button to the gui builder to make everything relative in the currently opened form.

This issue was fixed last month (https://github.com/texus/TGUI/pull/195/files), but there haven't been any new manual tags since then. (I'm planning on releasing a v1.0-rc soon, but I can't say yet if it will happen in the next days or if it still takes a few weeks).

So for now you may have to rely on the "nightly_build" tag instead of "v1.0-beta"

You don't have to add getPosition() to addClippingLayer, it is already relative to the widget position (since it is relative to the position in the passed states). So the rect should probably be just "{{}, getSize()}".

0xEA8 is a rather low number. A read violation that close to 0x0 usually means that a function is being called on a nullptr object.

In e.g. your 'gui.get<tgui::Button>("USR_Button")->setText(User);' line, are you certain that "USR_Button" exists and is a Button type? Otherwise 'gui.get<tgui::Button>("USR_Button")' would be a nullptr.

If you run the code with a debugger it should tell you exactly where it crashes. If the location isn't in your own code, you should be able to show a call stack that will tell you exactly where it happened.

The way draggable widgets work has now been changed. Containers are no longer draggable by default so widgets inheriting from SubwidgetContainer should now correctly receive mouseNoLongerOnWidget and mouseLeftWidget events.

If you are using gui.mainLoop then it should just work (as it calls gui.handleEvent for all SDL events).

For a custom widget you will need to override textEntered (and probably also keyPressed to handle backspace).

Are you passing the SDL_EVENT_TEXT_INPUT events to gui.handleEvent?

In general, the rule is that you don't have to do anything. The signal and lambda function are automatically freed when the widget on which you are connecting is destroyed.

However, it is very easy to accidentally introduce a memory leak when capturing widgets in the lambda. When capturing a shared_ptr in the lambda by value (and Widget::Ptr objects are shared_ptr objects), the captured object won't be destroyed until the lambda itself is destroyed. So if the captured widget is the widget that owns the signal, or the parent of the widget, then there is circular dependency between the widgets and signals, so nothing will be destroyed and the widget leaks.

If you disconnect the signal manually, the circular dependency would be broken. Another method to prevent this issue is to simply never capture a shared_ptr by value, instead capture the raw pointer:

Code (cpp) Select Expand

button->onPress([panel]{ /* panel->... */ }); // Memory leak if button is part of panel
button->onPress([p = panel.get()]{ /* p->... */ }); // No leaks

I'm not certain what you are asking, but I doubt that I can help as I do almost everything in English on my computer.

TGUI itself doesn't handle localization at all, it simply stores the characters in UTF-32.

It should be fixed now.
When "tgui::getBackend()->setFontScale(dpiScale)" is called, the SVG images will be internally rasterized to a higher resolution.

setScale will always lead to a blurry result, it simply stretches the output when rendering to the screen.

setSize will cause rasterization to be performed. If you don't change the view then it should result in a sharp image.

I'm assuming however that you are still calling setRelativeView on the gui as otherwise everything was rendered too small? The rasterization doesn't take that into account. So I might need to change the code to let rasterization also use the FontScale factor to compensate for the high DPI.

If you run "sudo make install" (assuming you build it with Makefiles) then it will install it to /usr/local and cmake should find it automatically.

Otherwise you have to set the TGUI_DIR variable in your cmake project to the directory containing TGUIConfig.cmake (which is either the directory you built TGUI in or the lib/cmake/TGUI subdirectory at the location where you installed TGUI to).

You can disconnect the signal like this:

Code (cpp) Select Expand

unsigned int callbackId = menu->connectMenuItem(...);
menu->onMenuItemClick.disconnect(callbackId);
This is because the connectMenuItem is a simple wrapper function that connects to the onMenuItemClick and when a menu item is clicked it will check whether it needs to call your callback function or not based on whether the item name matched.

Alternatively, instead of using connectMenuItem to connect multiple callbacks and deal with disconnection, you could just use onMenuItemClick directy (which is triggered for any menu item click).

Code (cpp) Select Expand

menu->onMenuItemClick([](const std::vector<String>& clickedMenuItem){
    if ((clickedMenuItem[0] == "File) && (clickedMenuItem[1] == "Load")) {
        ...
    }
    else if (...) {
       ...
    }
});