[ungod]

Hi,

is there a particular reason why tgui lacks a specific renderer for Pictures? I've added such a thing myself with just a "Texture" property, because its convenient to define what pictures show in a theme file and not rely on hardcoding.

It would be nice if a PictureRenderer is added officially. Should not be very time-consuming.

[texus]

It doesn't exist because I don't see a reason why they are necessary. I don't think mages belong in a theme file which defines how widgets look in general, not how every specific image on your screen looks.

[ungod]

I recently found myself in the scenario where I have complex (in a visual sense) widgets for a game. That means widgets are often groups of base widgets, lets say a progressBar for health, decorated with pictures, lets say small icons for status effects. I think like these kind of pictures are indeed part of "how widgets look in general".
(Take in mind, that tgui::Picture is by definition a tgui::Widget anyway ).
It felt unclean to have some of the gui textures defined in a theme file and some hardcoded in C++.

[texus]

There is a third way to define the texture of picture: widget files. You can load widgets from a file (with gui.loadWidgetsFromFile) instead of having to hardcode them in c++. These widget files contain both the looks (theme) and the widget properties (including picture texture). Although I do admit that these widget files are still not extremely useful in the current state as all theme options have to be embedded inside the widget, the theme is not shared between widgets yet and you can't refer to an external file for the theme. Plus the gui builder is still missing so the only way to generate these files it so first create the widgets in c++ and then save them.

But I will add the PictureRenderer. I've always known that it was inconsistent, I just felt it would be easier to let it be a self-contained class as the original idea was to just encapsulate sf::Texture and sf::Sprite. The only reason why it inherited from the Widget class is to let the gui draw it with the rest of the widgets. When I introduced the renderers, the Picture class just remained unchanged as I didn't have a need for having it in the renderer.

[texus]

PictureRenderer has been added to 0.8-dev now.

Should not be very time-consuming

Things aren't always as simple as they seem. The Picture::setTexture function had an optional second parameter, setters in the renderer can't have a second parameter. So this had to be moved to the renderer as well but as a separate property. This property was a boolean however, no other renderer function takes a boolean. This means that a boolean type had to be added to ObjectConverter first. This messed up some implicit conversions so other functions had to be added, adapted and removed to deal with that. Every ObjectConverter type also has to be serializable so the Serializer and Deserializer code had to be adjusted too. WidgetLoader and WidgetSaver also needed a small tweak. Plus tests have to be written for all these different cases. It turned out that the behavior of when the Picture would change size when a texture is being set after another texture was already set isn't even compatible anymore with the fact that the texture is a renderer property, so that had to be fixed as well.

All in all it was only a couple of hours work and the extra things that I had to add were kinda planned anyway, but I just wanted to point out that I disagree about the "not be very time-consuming" statement

[ungod]

Haha, it should be more accurate than my implementation then. Thanks for your efforts.

btw this ignoreMouseEvents thing is also very pleasant to have. Nice update.