TGUI: a c++ GUI for SFML (with Form Builder)

[Gan]

I don't suppose that's dynamic enough to handle drawing dynamic(moving) polygons to the background?

Would it be possible for me to subclass the panel, add a public variable backgroundTexture- override panel creation to create the texture, overide resize to resize the texture and override draw to draw the backgroundTexture then the normal draw?
Then to draw I could just do... panel->backgroundTexture.draw(myPolygon);

The tgui Window object, does that allow you to draw to the background of the tgui window object?

[texus]

The problem is that even if I would let you draw to the background of the panel, you still won't be able to render inbetween the tgui objects. This means you can either draw behind the panel or in front of the panel with all objects inside the panel drawn.

You might indeed be able to get there with inheriting from Panel.
You could override the draw function to first draw the polygon and then the other objects.

But it might be even easier to just provide an alternative draw function.
I said that a function called 'draw' would give you ambigious calls, but any other name would solve this problem.
But I will look into this problem later, when I have more time.

So for now this is what you could do:
Copy both draw functions from sfml's RenderTarget to the Panel code, but give them a different name (e.g. directDraw). And then recompile tgui. Or inherit from Panel and add these functions in your own object.

But depending on your needs this still won't work. I just gave you the method to draw directly to the panel (which was your original question), but as I said in the first alinea you might not get very far with it.

So I would just suggest a different approach. Is it really necessary that it is inside a panel? Are the polygons needed? (if it would be images then you could just use Picture)

The tgui Window object, does that allow you to draw to the background of the tgui window object?

tgui::Window inherits from sf::RenderWindow, so yes you can draw anything on it.

[Laurent]

Why don't you simply provide an overload of setBackgroundImage which takes a sf::Texture? This would allow users to draw to a sf::RenderTexture and update the panel with that.

[texus]

That would work even better indeed.
It's stupid that I didn't make the connection. When I looked up the setBackgroundImage function I was wondering why I didn't let it take an sf::Texture, but I didn't realize that it would be exactly what was needed.

But I think that Gan is better off implementing this himself (for now).
Inheriting from Panel and add a function that takes a texture as parameter. The texture has to be stored in the m_Texture member and everything should work. Or instead of inheriting just change the source code of Panel directly.

I really wished I had more time, but I'm too busy right now.
If you would have had this problem one day earlier then I would have been able to help immediately.

[Laurent]

Inheriting from Panel and add a function that takes a texture as parameter. The texture has to be stored in the m_Texture member and everything should work.

If m_Texture is not protected or public in Panel, this won't work. If it is... then I'd say this is not a very clean design

[texus]

You may be right about the bad design part, because I was too lazy to figure out what should be private and what should be protected so I made everything protected. It does make it possible to extend any class as you like it
I still have a few older decisions like this in my gui that I would like to work away, but because they aren't really a problem they usually get delayed.

[Gan]

Ah yes! That's pretty much exactly what I need.
sf::RenderTexture as the background.

I'll look at the code and try to implement it myself.

To answer the question of necessity, it is very necessary.
Imagine having a map editor. You have a panel in the middle of the screen that shows the editable world(takes mouse input). On the border around that panel could be other tools like buttons, drop down menus, lists. In the bottom right corner could be a small panel that shows a minimap of the entire world. Clicking on the minimap would make the main map view go to that location.
And sometimes there may be a button on top of the map view.

[Gan]

I really mangled your code, but hey I got it to compile. Hopefully it still works with all that deleting and commenting and stuff....
but now I got this function!

Code: [Select]

void Panel::setBackgroundTexture(sf::RenderTexture* t)

[Laurent]

Take a const sf::Texture&, not a sf::RenderTexture*.

[Gan]

Right now to draw it I have it make a sprite with the texture then draw the sprite. On every draw.
Is that slow?

[texus]

There is also a m_Sprite in Panel, so when changing m_Texture you can immediately call m_Sprite.setTexture(m_Texture).

I looked at it and there won't be clean solution soon. When setting a texture this way, you still own the texture. However the panel assumes that it created the texture and will try to remove it when it is destroyed.
That shouldn't be any problem in your case, but when I make the change in the gui I will have to choose between letting the panel load it, or passing a texture. I'll probably end up with the second one so the function that takes a filename will get removed. But I won't make desicions like that immediately so you'll just have to continue with your own fix for a while.

[Laurent]

Right now to draw it I have it make a sprite with the texture then draw the sprite. On every draw.
Is that slow?

No.

[Gan]

There is also a m_Sprite in Panel, so when changing m_Texture you can immediately call m_Sprite.setTexture(m_Texture).

I looked at it and there won't be clean solution soon. When setting a texture this way, you still own the texture. However the panel assumes that it created the texture and will try to remove it when it is destroyed.
That shouldn't be any problem in your case, but when I make the change in the gui I will have to choose between letting the panel load it, or passing a texture. I'll probably end up with the second one so the function that takes a filename will get removed. But I won't make desicions like that immediately so you'll just have to continue with your own fix for a while.

Easy fix, have the panel create the texture and all I'd need to do is getBackgroundTexture();
It'd have to return a RenderTexture so I could draw to it, but it's a simple solution that'd fix it.

In fact, you can even keep the setBackgroundImage function, just draw the image to the RenderTexture.

[Laurent]

Easy fix, have the panel create the texture and all I'd need to do is getBackgroundTexture();
It'd have to return a RenderTexture so I could draw to it, but it's a simple solution that'd fix it.

That's really ugly in my opinion, it's a good solution for a quick and dirty fix but nothing more.

Taking a reference to an external texture is much cleaner and flexible, just a little more inconvenient because the user must manage the texture himself.

[quicksilver]

I successfully installed TGUI v0.5 from source using linux, CMake, and Code::Blocks as described in your tutorial. However, when I tried to run a simple program using TGUI, i receive the following:

||=== Test, Debug ===|
/usr/local/lib/libtgui.so: error||undefined reference to 'glGetIntegerv'|
/usr/local/lib/libtgui.so: error||undefined reference to 'glScissor'|
/usr/local/lib/libtgui.so: error||undefined reference to 'glIsEnabled'|
/usr/local/lib/libtgui.so: error||undefined reference to 'glEnable'|
/usr/local/lib/libtgui.so: error||undefined reference to 'glDisable'|
||=== Build finished: 5 errors, 0 warnings ===|

I have the latest SFML 2.0 libraries, also build from source, and have no problems with those. I followed all of the instructions in your installation tutorial. Any idea what I am doing wrong? Thanks in advance for any help.