Recent Posts

Pages: [1] 2 3 ... 10
Feature requests / Re: Virtual keyboard
« Last post by eugustus on 05 April 2021, 13:21:51 »
I'll Try to implement something. But it won't be in closely the days, I stumble into a new housing ... But I have to emphasize that I don't have to recall gui.handleEvent(...) inside the event handler again ..
Feature requests / Re: Virtual keyboard
« Last post by texus on 05 April 2021, 10:57:29 »
They keyboard could be a Panel widget with a lot of buttons then. To show the keyboard you call gui.add(panel) and when you want to hide it you call gui.remove(panel).

I would implement it similar to what I describe below. Note that I didn't test any of this code or think about it for long, there might be other/better ways to do it (e.g. I know that the keyboardShown boolean could be replaced by querying the gui for whether it contains the panel).

Code: (cpp) [Select]
void EditBoxOrTextAreaFocused(tgui::Widget::Ptr widget, const tgui::String& /*signalName*/)
    focusedTextField = widget;
    if (!keyboardShown)
        keyboardShown = true;
Code: (cpp) [Select]
void EditBoxOrTextAreaUnfocused()
    focusedTextField = nullptr;
    if (keyboardShown)
        keyboardShown = false;
Code: (cpp) [Select]

I'm using connectEx on onFocus instead of a normal connect in this example so that the callback function gets the widget as parameter without you having to pass it yourself. Otherwise you would need something like `editBoxOrTextArea->onFocus(&EditBoxOrTextAreaFocused, editBoxOrTextArea)` in which copy-paste errors are more likely to happen as you always need to pass the same argument as the widget on which you call onFocus.

For each button on the keyboard you could do something like this:
Code: (cpp) [Select]
void VirtualKeyboardKeyPressed(char32_t key)
    assert(focusedTextField != nullptr);


    tgui::Event event;
    event.type = tgui::Event::Type::TextEntered;
    event.text.unicode = key;
Code: (cpp) [Select]
buttonKeyA->onPress(&VirtualKeyboardKeyPressed, 'a');
Backspace and other special keys need a separate function. You can use a KeyEvent instead of TextEvent to pass a backspace to TGUI.

EDIT: After typing this I just realized that unfocus is going to be a bit more difficult. In this code the EditBoxOrTextAreaUnfocused would be called and hide the keyboard each time you press a keyboard key.
Feature requests / Re: Virtual keyboard
« Last post by eugustus on 04 April 2021, 22:02:19 »
I do not want OS-specific keyboard.
I see this so that the keyboard object must 'bind' to the input field. Each time the button is clicked, the input field must be re-focused programmatically. Which would mean that there could be two versions of how the keyboard can be binded to the input field. Either one 'singleton' for all input fields, or one 'no sengleton' for each input field?
Feature requests / Re: Virtual keyboard
« Last post by texus on 03 April 2021, 22:24:12 »
It depends on what you want to do.
If you just want some virtual keyboard to be displayed then you might be better of with calling some OS-specific function.
If you want to create a window with a virtual keyboard yourself then you could use TGUI for it, each key is simply a button.
If you want the virtual keyboard in the same window as your application then it might cause some issues: pressing a key on the keyboard will move the focus to that button, so the edit box that you had selected to type in will lose focus.
Feature requests / Virtual keyboard
« Last post by eugustus on 30 March 2021, 19:29:14 »
Hello to everybody. Has anyone implemented a virtual keyboard with tgui? Can he do it at all? :)
Help requests / Re: Replacement for tgui::Canvas in SDL backend
« Last post by provener on 12 March 2021, 00:20:11 »
Sorry, this is all pretty new to me. On the surface level it seemed like SDL was this API-agnostic layer on top of any renderer that was appropriate for the platform, but it seems like most SDL programs just assume OpenGL is the renderer—not just TGUI but others. So I kind of thought that with the move from SFML to SDL2 I was gaining access to a broader amount of libraries guaranteed to work cross-platform. But it really does seem like most of the ecosystem is just SDL2 with the expectation that OpenGL is available. It's pretty confusing for someone who hasn't really worked with these kinds of libraries before.
Help requests / Re: Replacement for tgui::Canvas in SDL backend
« Last post by texus on 11 March 2021, 22:56:58 »
especially since I'm attempting to use OS-exclusive renderers where I can (i.e. Metal for macOS and Direct3D11 for Windows)
TGUI has to use the same renderer as your code, so if you were to use these renderers in your code directly then you would have to write a TGUI backend for each platform to do so.

You can rely on SDL_Renderer to abstract the backends so that you only need to use SDL_Renderer and don't have to bother with whether it uses metal or directx internally, but SDL_Renderer has its limits (it can't even draw a simple filled triangle or circle). When I started porting TGUI from SFML to SDL I started with the SDL_Renderer, until I encountered things that I simply couldn't do with it and learned that many projects don't use SDL_Renderer and instead use their own rendering code (which makes it very difficult to have the same rendering code in TGUI as in user code, hence why I skipped adding the Canvas class).

Using OS-exclusive renderers isn't always the best approach either. According to, the Metal backend used by SDL_Renderer is even slower than the OpenGL backend on macOS (unless that changed within the last year).

If you wouldn't care about OS-exclusive renderers then perhaps I could consider creating a Canvas widget where you can render simple text and images to (via functions on the Canvas object, e.g. it would have a drawText function). Then you would use TGUI for rendering them instead of accessing SDL directly. It would be a very limited interface and it would require using OpenGL on all platforms though.

Technically TGUI could be made compatible with SDL_Renderer (by adding a new backend for it), but it would have to result to software rendering for drawing triangles, which would make it very slow.

So depending on what you need, TGUI might not work for you.
Help requests / Re: Replacement for tgui::Canvas in SDL backend
« Last post by provener on 11 March 2021, 20:46:27 »
I gotcha. Thank you for the context (hah).

I haven't even gotten as far as to tear out SFML in my GUI code yet, so no actual prototypes with TGUI/SDL, but it seems like I'd end up at the impasse you described above, especially since I'm attempting to use OS-exclusive renderers where I can (i.e. Metal for macOS and Direct3D11 for Windows).

Thank you again!
Help requests / Re: Replacement for tgui::Canvas in SDL backend
« Last post by texus on 11 March 2021, 19:58:08 »
I think I understand what you are trying to do, and you would need a Canvas if you don't want to manually keep track of gui widgets coordinates.

The problem is that what you are describing technically can't work correctly as far as I know. Are you already rendering with SDL while also drawing with TGUI or is this something you plan on doing? From what I read, you can't use an SDL_Renderer and OpenGL context on the same window without messing up the rendering (and TGUI requires an OpenGL context on the window). So even without the Canvas widget, manually drawing stuff with SDL leads to undefined behavior (such as rectangles being drawn instead of text characters).

The only way you would be able to manually draw with SDL_Renderer without causing a rendering conflict is if TGUI's SDL backend would use an SDL_Renderer instead of OpenGL for drawing (but I can't do that because SDL_Renderer can't render triangles).
Help requests / Re: Replacement for tgui::Canvas in SDL backend
« Last post by provener on 11 March 2021, 19:43:34 »
I was using canvas because it seemed like the correct way to use the layout engine to separate your screen into resize-/scale-friendly panels, and then draw all application-related sprites/textures to it. It may be the case that all I need to do is use the layout engine, have it set up a horizontal panel on the side, and draw things directly to the screen in whatever way the API expects (passing sf::Drawables to Canvas#draw for SFML, or SDL_RenderCopy for SDL), in the "left-over" space that is not taken by the GUI.

What makes it awkward without the notion of a canvas is if I have two areas on screen that I want to directly render to, one of which is contained within the layout of a GUI, I will have to keep track of the location of the individual GUI widgets in order to render textures at the right coordinate positions. Does that make sense?
Pages: [1] 2 3 ... 10