16

Help requests / Re: Grid and scrollbar

« on: 15 June 2021, 18:50:37 »

This is because the inner size of the ScrollablePanel never changes when scrollbars are visible or not.
I agree that this isn't ideal and it should probably be changed, but right now it is the expected behavior.

Implementing this properly is a bit tricky: whether scrollbars are shown could depends on the widgets inside the panel, but the size of those widgets would depend on whether there are scrollbars.
So when writing the ScrollablePanel widget I decided to just keep it simple and ignored this case.

Edit: Maybe I could change the inner size when Policy::Always is specified and leave the more difficult case for later.

17

General Discussion / Re: Missing some classes in Doxygen docs

« on: 15 June 2021, 08:19:29 »

Thanks for letting me know. I guess I should enable the TGUI_HAS_BACKEND_SFML define next time I build the documentation.

For TGUI 0.9.3 I'm planning to rewrite the backends anyway, so I'll add a note that I have to look at improving the documentation (to make Gui classes from all backends show up).

18

Help requests / Re: ToolTip Auto Position On Screen

« on: 11 June 2021, 19:42:23 »

The TGUI version from github now places the tool tip so that it doesn't fall (partially) outside the window.

19

Help requests / Re: ToolTip Auto Position On Screen

« on: 09 June 2021, 22:40:19 »

It's currently not possible.
I might have a look at implementing this in the next few days. It doesn't look that difficult, I think this line just has to check if the position plus size of the tooltip is larger than the size of m_view.

20

Installation help / Re: Help getting TGUI running - OpenGL

« on: 02 May 2021, 22:53:22 »

I can't help you with that IDE. The only thing I know is how the command that is passed to the linker should look like: for dylibs it should be "-lXXX.dylib" while for frameworks it should be "-framework XXX".

To find a different SFML version you have to change the SFML_DIR option. The value has to be the directory that contains a file called SFMLConfig.hpp. I can't tell you which folder this is, as it depends on your SFML installation, but suppose SFML is installed to /usr/local then the folder would most likely be /usr/local/lib/cmake/SFML.

Alternatively you could always install SFML and TGUI using homebrew.

21

Installation help / Re: Help getting TGUI running - OpenGL

« on: 02 May 2021, 14:27:37 »

It seems like TGUI links to the frameworks then.

I don't think there is an easy way to choose whether TGUI links to dylibs or frameworks in CMake, it probably uses the first one it finds (unless you either set SFML_DIR manually or show the advanced options and manually change the paths of the SFML libraries).

So the solution is probably to either link to the SFML frameworks in your project, or to rebuild TGUI after removing the files from that Library/Frameworks folder (because TGUI will then find the SFML dylib files instead of the frameworks).
Edit: After thinking about it, TGUI might fail to find SFML when the frameworks are removed (when attempting to build TGUI with cmake again). There is an SFMLConfig.cmake file which TGUI finds and that one probably still points to the framework. So you would have to delete that file as well, or set SFML_DIR to a different location. Just keeping TGUI unchanged and linking to the SFML frameworks in your project thus sounds like the easier solution.

22

Installation help / Re: Help getting TGUI running - OpenGL

« on: 01 May 2021, 09:07:40 »

The error about SFViewController means that your project is linking to both the SFML framework and the dylib file, while you should only link to one of them.

The opengl error is probably caused because one SFML version gets initialized properly while the second one isn't initialized and believes it has no opengl support.

In your project you are probably only linking to one of these versions, but TGUI will be linking to the other one. You need to make certain to use the same SFML version in your project and when building TGUI. So how did you install TGUI exactly?

23

Help requests / Re: tgui::FileDialog within a pop-up window.

« on: 23 April 2021, 22:23:45 »

TGUI is probably not the best option for such case. The FileDialog widget was added in cases where you basically wouldn't want to have an external window.

You might be better of using something like https://sourceforge.net/projects/tinyfiledialogs/ or https://github.com/samhocevar/portable-file-dialogs

24

Feature requests / Re: Virtual keyboard

« 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;
        gui.add(keyboardPanel);
    }
}

Code: (cpp) [Select]

void EditBoxOrTextAreaUnfocused()
{
    focusedTextField = nullptr;
    if (keyboardShown)
    {
        keyboardShown = false;
        gui.remove(keyboardPanel);
    }
}

Code: (cpp) [Select]

editBoxOrTextArea->onFocus.connectEx(&EditBoxOrTextAreaFocused);
editBoxOrTextArea->onUnfocus(&EditBoxOrTextAreaUnfocused);
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);

    focusedTextField->setFocus(true);

    tgui::Event event;
    event.type = tgui::Event::Type::TextEntered;
    event.text.unicode = key;
    gui.handleEvent(event);
}

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.

25

Feature requests / Re: Virtual keyboard

« 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.

26

Help requests / Re: Replacement for tgui::Canvas in SDL backend

« 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 https://stackoverflow.com/a/59725539, 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.

27

Help requests / Re: Replacement for tgui::Canvas in SDL backend

« 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).

28

Help requests / Re: Replacement for tgui::Canvas in SDL backend

« on: 09 March 2021, 08:46:36 »

What kind of things do you need to draw on the canvas?

What is the proper way, with the SDL backend, to reserve an area of the GUI window for directly rendering, say, SDL_Textures to?

This is currently unsupported in the SDL backend. The canvas code is behind and ifdef guard because it didn't get ported.

The main problem that I had was not knowing how people were going to use it.
The SDL/OpenGL backend doesn't use SDL_Texture, so that couldn't really be used. The canvas would have to use opengl code, but I don't have enough experience with it to assure that your own opengl code wouldn't conflict with the TGUI code.

The only workaround that I know if performance isn't an issue is to somehow get what you want to render into an image. You can create a tgui::Texture and call loadFromPixelData and then set that texture in a tgui::Picture widget.

The SDL renderer itself was too limited to port TGUI to, which is why I had to use opengl. But that probably also means that your code can't use SDL_CreateRenderer and simple SDL rendering functions.
So I'm not sure how to best solve this situation either.

29

Help requests / Re: How to build tgui on android

« on: 06 February 2021, 11:10:46 »

If you are still interested in trying SFML and TGUI on android then I've build some libraries that you should be able to use.

Download: https://www.dropbox.com/s/efsbs1ni5inzo1d/sfml-tgui-android-debug.zip?dl=1  (42.3 MB)

The zip file contains an "sfml" and a "tgui" folder. These folders need to be placed in "C:/Users/Alexhero/AppData/Local/Android/Sdk/ndk/22.0.7026061/sources/third_party".
They contain debug libraries for both x86 and armeabi-v7a.

(I only build the libraries, I didn't try to run a program with them)

30

Help requests / Re: How to build tgui on android

« on: 06 February 2021, 10:36:56 »

I looked into building SFML, but it still has its issues.
SFML 2.5.1 had 2 issues that prevented me from using it on android in the past.

The first one caused a crash at runtime and has been solved recently (3 weeks ago), so the latest version from github should be able to run on android (but I haven't tested it yet).

The second issue, which still exists in the latest github version, is that it doesn't support NDK 22 (which you are using). There is a workaround to make it work, but it does raise the question: what NDK version were your SFML libraries compiled for?
The TGUI libraries must be compiled with the exact same version of the NDK. If someone just gave you SFML libraries and you are then going to build TGUI libraries yourself, then they may not match and your program will most likely just crash (if it doesn't already fail when linking).

There is also a third issue for some people: SFML has no support for 64-bit platforms, which means you can't publish your app in the App Store.