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

[texus]

I can't add such function. Even if I could then it would do exactly what you have to do now manually. I can't use object types because that would make the use of custom objects impossible (and gives me more work for every new object). I can't use the dynamic cast method either because of the problem with Panels and ChildWindows.

Anyway, such a function isn't going to be created even if I could do it.
Actually the getObjects function wasn't supposed to be used. It was added to make my life easier to write the Form Builder.

What you could do is store the child window pointers yourself somewhere, or change your design in some other way. I don't know how the child windows are created and used, but if you don't keep the pointers to them then maybe there is some logic in the names you give them. If you know the name of the child window then you can use the get function to get the pointer to it.

[netrick]

Is there a way to have a buttom without image? I have images drawn with sfml and I need them to act as buttons. Is there a way not to call load function? Or if I load png background file with 100% alpha will it be transparent?

[texus]

If you only need a text then you can just use a Label.
But in this case that probably won't work because then the clicks will only be registered on top of the text.

So I guess you will have to use transparent images.
I would suggest an image with transparentcy 1 (instead of 0), just in case I decide to allow clicking through transparent objects in the future.

[netrick]

I would suggest an image with transparentcy 1 (instead of 0), just in case I decide to allow clicking through transparent objects in the future.

I think if you ever add such a thing it should be optional. As you see there are cases when this isn't wanted and it definitely isn't a common and widely-used thing, so it would be great if there would be some function to enable/disable it.

[texus]

I think such thing should be added to allow e.g. rounded corners in buttons. Right now all objects are rectangles (except Picture which has already been adjusted) and I believe that it would be better if clicks on the fully transparent parts of the images are not registered as a click on the object itself.

But I understand that this is a problem in situations like this so I will definately think about a solution before I make the changes. Although adding something like a ClickableObject or ClickableRectangle would be enough to solve this particular problem.

You can be sure that I'll think about this (and other previously mentioned problems) while writing the next version. Talking about the next version: the callback system in v0.6 is finished and I am planning to upload a development snapshot soon (tomorrow if possible).

[texus]

For those who are interested, you can find the first development snapshot of v0.6 on the download page.

At this point, it only contains the new callback system and some stuff that got renamed.

It should be usable, but there are no tutorials, so if you want to use this version in your project then you will have to look in some header files from time to time. I did generate documention though, so you might find some help there too. Or said in another way: this version is only for experimental use right now or if you really need to use the new callback system.

[netrick]

That's great! I'd like to test v0.6 new callbacks however I have a question - does it support std::bind like sf::Thread?

[texus]

No it doesn't. The parameters of the function has to match, you can't choose your own parameters.
The function either has a void parameter or a const Callback&. The return type is always void.

But why would you need support for std::bind?

Edit: It seems like it is still 'Callback&' instead of 'const Callback&', but this will be adjusted in the next snapshot.

[Nexus]

No it doesn't.

You use boost::function, so it supports any functions and functors with a compatible signature, including the ones returned by std::bind()

By the way: Unless you need support for ancient compilers, you should use function instead of function0, function1 etc. And for the function template boost::bind(), you needn't specify the template parameters. Also, you could use function and bind of the C++11 standard library, or at least TR1 (from 2005) instead of having the Boost dependency.

[texus]

You use boost::function, so it supports any functions and functors with a compatible signature, including the ones returned by std::bind()

I do use boost, but it is completely internal. So when calling the bindCallback functions you can't use std::bind (as far as I know) because the function takes a normal function pointer.

I had a small poll on my site for a day or two asking if c++11 support would be acceptable. From the 9 answers, I got 3 people saying that older compiler support is needed and c++11 should thus not be used. So that is not an option yet.

About TR1, I still don't know enough about it. I know I can use it easily in CodeBlocks, but I have no idea if it works the same on Visual Studio or Xcode.
My main concern is support for VS2008. From what I have just read you would have to install a feature pack separately to get tr1 working on it. I also saw an article about the windows sdk breaking the tr1 extention.
So I think it is best to keep boost for now to avoid those problems.

[Laurent]

I do use boost, but it is completely internal. So when calling the bindCallback functions you can't use std::bind (as far as I know) because the function takes a normal function pointer.

Then you should add an overload which takes a template parameter, so that you can be compatible with functors built by other functions without explicitely supporting it. Of course, what the user passes to this overload has to be directly assignable to a boost::function, but that's not your problem.

[texus]

That might work, thanks.

But I still don't get why anyone would need std::bind to choose its callback function.
I'll wait before trying to add it until someone can give me a good reason why it could be needed.

And I will definitely have to take another look in the source code of sf::Thread. On first sight, it looked a lot better than what I have right now.

[Nexus]

But I still don't get why anyone would need std::bind to choose its callback function.

It's not only std::bind, it's functors in general. When you only support function pointers and no functors in your API, you reduce the use cases dramatically. The user cannot store (bind) other arguments, he has to use global variables to transport information via callbacks, which is very bad. The whole intention behind functionals is to have a more general alternative to C-style function pointers, without losing compatibility to them.

Since you internally use boost::function anyway, I do not see a reason why you only have function pointers in your API. Once you support functors, std::bind() will work, lambda expressions will work, and the user gets much more flexibility.

[texus]

Ok, I see now.
I'll make sure that functors get supported.

[netrick]

Is there a way for picture to send callbacks on click in 0.5?