-
TGUI is an easy to use cross-platform GUI based on SFML and written in C++.
Currently (v0.4) the following objects can be used:
- Label
- Picture
- SpriteSheet
- Button
- Checkbox
- RadioButton
- EditBox
- Slider
- Scrollbar
- Listbox
- ComboBox
- LoadingBar
- TextBox
- Panel
Screenshots:
TGUI v0.3.4 (Black style)
(http://i1119.photobucket.com/albums/k625/texuz/TGUI/TGUIv034-1.jpg)
TGUI v0.4.0 (Black style)
(http://i1119.photobucket.com/albums/k625/texuz/TGUI/TGUIv04Black-1.jpg)
TGUI v0.4.0 (BabyBlue style)
(http://i1119.photobucket.com/albums/k625/texuz/TGUI/TGUIv04BabyBlue-1.jpg)
Video of the TGUI Form Builder v0.2 that shows how easily you can make a login screen.
http://youtu.be/am_RumRUzZQ (http://youtu.be/am_RumRUzZQ)
Features:
* It is extremely easy to use: only a few lines of code and you have e.g. a fully working edit box.
* You can handle object callbacks just like you handle events in SFML.
* You can create unlimited objects, even while the program is running e.g. create object on click.
* Objects can be loaded from a file, you can update e.g. the positions without compilation.
* TGUI uses an internal texture manager so that no image is loaded twice.
* All objects are derived from sf::Transformable, so you can use e.g. setPosition.
* TGUI used the camelCase notation which is the same as SFML uses.
* Just like SFML, it is licensed under the zlib/libpng license.
* Cross-platform: Windows, Linux and Mac OS X.
* TGUI provides an easy to use drag-and-drop form builder.
Tutorials can be found here (http://tgui.eu/tutorials/).
I have also written a fully commented example code that you can find here (http://tgui.eu/example-code/).
TGUI can be downloaded from my download page (http://tgui.eu/download/) or from GitHub (https://github.com/texus/TGUI).
You will have to build TGUI with cmake, but I have provided some Getting Started tutorials (http://tgui.eu/tutorials/) for that.
I hope that someone will find this project useful.
If you have any questions, if you you find bugs or if you have any remarks then just let me know.
-
What I noticed immediately: Inconsistent style (unless that's intended to show off skinning)...
The button is rather flat with slightly rounded edges, the list box is solid with no rounding and a thick black line.
The edit box has some slight lighting/shadow effect and round edges, looking almost 3D (and not sunken like expected from most users I guess). In a similar way, the slider is really flat again and the progress bar looks completely different (also using another blue).
-
looks nice! 8)
I think you should change
slider->m_VerticalScroll = false;
to something like
slider->disableVerticalScroll();
good work!
-
I think you should change
Code:
slider->m_VerticalScroll = false;
to something like
Code:
slider->disableVerticalScroll();
It isn't really disabling something. You just say that you want a horizontal slider instead of a vertical one, but I'll think about it.
Inconsistent style
The style can be changed freely. You can use your own images. I just created these images as an example, and as you noticed I am not a good artist.
Only the listbox isn't made from an image. I'll see if I can change that so that it will look more like the rest.
looks nice!
Thanks
-
Checked it out and it looks very nice indeed. I would change the TGUI namespace to lowercase to conform with SFML's (sf::), also it is increasingly becoming the standard convention.
There really isn't much to add, it seems a well designed and easy to use GUI framework and I will definitely test it on!
Could you tell us a bit about your design philosophy and the main differences compared to SFGUI?
:thumbsup:
-
I would change the TGUI namespace to lowercase
Ok, I will do that.
Could you tell us a bit about your design philosophy and the main differences compared to SFGUI?
I never looked at SFGUI, so I don't know the differences.
I just tried to keep TGUI it as easy as possible to use, but I am always open for suggestions on how to make it easier.
Edit:
something like
Code:
slider->disableVerticalScroll();
I will probably change it to slider->setVerticalScroll(false), but the current way will also stay possible.
-
Nice project :D
I have just a question : It require SFML 1.6 or SFML 2 ?
-
It require SFML 1.6 or SFML 2 ?
It requires SFML 2.
I should have put that in the description.
-
Looks really neat!
-
I just published v0.3.1. Not much changed, it was just a small update.
- Namespace is now in lowercase
- Slider::m_VerticalScroll can be accessed indirectly with Slider::setVerticalScroll(bool)
- The scrollbar didn't really work like it should, the wrong behaviour has now been fixed
- Small bug fixes in EditBox and Listbox
These are my plans for the next few versions (not necessarily in this order)
- Create a text box
- Create a combo box
- Create radio button groups
- Currently when the edit box is full you can no longer add something. This should be changed.
- Some other small things like e.g. double clicking in edit box should select the whole text.
-
For those who are still interested: I just released v0.3.2.
I added a combo box (which can optionally have a scrollbar) and I made some bug fixes in EditBox, ListBox and Scrollbar.
-
TGUI v0.3.3 is out.
(http://i1119.photobucket.com/albums/k625/texuz/TGUI/TGUIv033-sfml_forum.png)
The most important thing I added were:
- Scrolling in EditBox. The text width is no longer limited.
- You can now load the objects from a file.
- Next to the .lib and .so files, I have also added .a files.
A full list of changes can be found on the changelog page (http://tgui.weebly.com/changelog.html).
Some may have already read it on my homepage: I am planning to make an easy drag-and-drop form builder.
I don't have much time right now and I will first have to write horizontal scrollbars, but this will be my current goal.
-
Hello,
You have a nice project here and I'm happy to see that there is another GUI library which for me at least is easier to use :)
I know it has been only 3 days, but I would like to ask how much do you think the form builder might take you ? /nothing too accurate, 1 week or a month seems reasonable for me/ This is because I love the ability to see your GUI on the fly and not hit compile for every minor adjustment of a widget.
Also I would like to say some things about the library, because this should be a two way process and people should not only want new things, but give feedback for already implemented functionality.
I looooooove the ability for skinning which is something not every GUI library can so easily achieve. I do have some questions and suggestions though:
- Can we change the font used by the GUI globally?
- When I hit the "Delete" button from the keyboard to delete text past the cursor in the edit box, nothing happens and everywhere else I think such a feature exists.
- When the arrows are pressed down and held, the cursor in the edit box doesn't move forward/back.
- The text in the edit box in the example code shows only "The tex" and I have to move the cursor to reveal everything else, while there is space in the widget where the text should be drawn, but isn't. /Also on the first run of the example I had a bug with the edit box where the cursor went out of the borders of the edit box and as I typed text, the cursor went on over the image, but unfortunately I can't recreate it again to see what could have caused it./
- IMO there should be a hover event for the items in the combo box and the scrolling list box, because otherwise the GUI seems like it is in lag or dead.
Good work with the project so far :)
Edit 1: Oh it occurred to me now that I have another question:
- How are we supposed to get rid of the GUI elements which we no longer need and delete them from the system, because I see that there is a Hide function, but hiding quite a lot of buttons isn't always effective if we want to gain more speed for other rendering and calculating processes?
-
how much do you think the form builder might take you?
Don't hope too much for it. I would love to start with it, but I will have to write a horizontal scrollbar first. I could do this fast and leave a small bug, or I could first remove the bug, but then it will take longer before I can start with the form builder.
Also with the amount of homework I am getting, I don't think it will be finished this month.
Can we change the font used by the GUI globally?
No, but this is a good idea. I will add a setFont function to the window.
When I hit the "Delete" button from the keyboard to delete text past the cursor in the edit box, nothing happens
This is strange, the delete button should work fine.
When the arrows are pressed down and held, the cursor in the edit box doesn't move forward/back.
Are u using linux? https://github.com/SFML/SFML/issues/122
The text in the edit box in the example code shows only "The tex"
Small mistake in the example code.
When the text is set then the edit box is only one third of the size, because the last line, the SetScale, will make it three times as big.
Putting the SetScale line before the setText should solve this problem.
I am currently writing a setSize function. If you use that one instead of SetScale then this problem will disappear.
there should be a hover event for the items in the combo box and the scrolling list box
I have added it to my todo list, which is currently getting very long.
How are we supposed to get rid of the GUI elements which we no longer need
window.removeObject("objName"); // Removes one object
window.removeAllObjects(); // Removes all objects
I have started the documentation yesterday, but it will take a while before everything gets in it.
About the skinning: you can change the style of all objects by recalling the load function with a different pathname. I could put a function in window which will recall all load functions so that you can change the style with just one function.
I currently only have the Black style, so if you want to use another style then you will have to make the images by yourself.
But the major problem are EditBox, Listbox and ComboBox. You have to set the colors separately with the changeColor function.
-
hey,
i need some instructions where i have to copy the lib / object and include folder.
ps.: i use linux
-
Except for the library file, you can put the folders anywhere you want.
Just make sure that the path is in the include directory of your IDE, just like you configured your IDE to find sfml.
Don't forget to link to tgui. This is also done in the same way as sfml, by adding -ltgui to your linking options.
The place of your object folder doesn't matter either, as you must pass a pathname whenever you load an object.
I don't really know how to decently distribute my project. I don't know how to use makefiles or cmake, so you will have to copy the lib file to the correct place by yourself.
I would think you need to put the libtgui.so file in the /usr/lib folder.
If it doesn't work then you might need to call ldconfig (in the terminal, as root).
I am happy to see that people are starting to test my library, at least I finally know which things I must improve.
-
Thank you for the quick reply, didn't expect to get an answer so soon :D
I'm not using Linux, I have a Windows 7 64-bit with an ATI card, which for the most part of my problems doesn't matter.
Anyway thanks for clearing up the problems with scale and deleting objects :) /because I read in the example code about the things that could be caused by it and borders, but didn't relate that the problem with the text could originate from here/
About the skinning, I realize that I have to make the images by myself, I just wanted to note that the way it is implemented in this GUI library is far easier than the ones I've tried before on other languages as well.
Sorry about clogging your TODO list, I hope you get to do the things YOU want for this project and that more people will find it useful and contribute to its development :)
-
I'm not using Linux, I have a Windows 7
I guess I should test it on my windows then. I always assumed that it didn't work because I was using linux.
Sorry about clogging your TODO list, I hope you get to do the things YOU want for this project
Usually I just try to do whatever I think that other people might need, so it's not a problem. I just meant to say that there are so many things to add and so many small bugs to remove that you shouldn't expect it soon.
-
After fiddling around with the format of the text which enables you to use forms I found out that I don't how whether there is a way to set a callback to a widget. I know that I can get the widget by name in code and set its callback there, but can I write a line in the form text for each widget, which specifies its callback ID ?
Anyway, even without a form editor everything is pretty straightforward, so that you won't get frustrated or confused while trying to configure your GUI :)
-
Setting thr callback id inside the text file is something I overlooked, I will add it in the next release.
Thanks for reporting this.
-
Sorry for spamming the thread, but I had another problem while trying to do screen transitions.
I know that I can delete multiple elements by name, or all by calling a single function, but when I do call removeAllObjects, the application crashes and I don't think that deleting every single object is a good idea, when your loading from text files.
I tried something like:
Window:
{
Panel: "Main"
{
Picture: "Pic1"
{
Filename = "Data/Images/GUI/Backgrounds/Main.png"
}
}
}
and eventually delete the panel "Main" by code and later load another form text file, but to start, nothing renders at all, which leads me to the conclusion that I am not using panels properly, or they aren't meant to hold other objects /which I doubt since window is derived from panel/.
The possible solutions I can think of are:
- Learning how to use a panel properly.
- Having a function removeObjectsFromFile, which takes a form text file and searches for the names.
- After the call of removeAllObjects with the fact that there is a window object in the text file, something could be messing up the GUI window.
-
Panel was never fully tested so it might still contains some mistakes (like e.g. objects from different panels can both be focused).
Unless you really need them for e.g. creating multiple radio button groups (radio buttons have to be in different panels to check both radio buttons), you shouldn't use them.
Having a function removeObjectsFromFile, which takes a form text file and searches for the names.
This might be something for later, when I will allow placing multiple forms in one file.
Then I will add the functionality to load or remove a complete form.
Panel: "Main"
{
Picture: "Pic1"
{
Filename = "Data/Images/GUI/Backgrounds/Main.png"
}
}
This isn't possible yet. I shouldn't have added the possibility to create panels from a file.
Panels can already be loaded from a file, but you can't add objects to it yet (at least not in the text file itself).
The current loadObjectFromFile function isn't capable of loading objects within a panel.
I am thinking on a way to fix it, but whatever I will find as a solution, the function will have to be completely rewritten.
when I do call removeAllObjects, the application crashes
Although this is probably because the loading from the file failed, this is something that is not allowed to happen.
I will try to find out why it crashes when I get the time.
-
Just for reference, the panel file doesn't get loaded, but the one that does get loaded has window and a picture and 5 buttons, but if I call removeAllObjects it crashes, so that you know the problem isn't in file loading :)
Edit1: If I try to set text to an edit box in a form text file, the app crashes.
Edit2: Sometimes the text on a button gets blurry, which is probably because of floating point math for centering it on the button. A simple cast to int should fix it :)
-
The next release has arrived.
The important changes in v0.3.4 are:
- setSize function added to all gui objects. Note that it may not be called before the load function.
- The setGlobalFont function was added to the window.
- Objects loaded from a file can have a callback id.
- You can use a horizontal scrollbar
- removeAllObjects no longer crashes the program
If I try to set text to an edit box in a form text file, the app crashes.
I don't have this problem, but this would mean that the example code would crash too.
Sometimes the text on a button gets blurry
I'll investigate this problem later, but I don't think that a blurry text has anything to do with my code for centering the text.
It can only get blurry when it is scaled instead of just changing it's text size.
Anyway, this problem should only appear when no text size was set, which you don't want to do in most situations (the text size will be different in every button).
Edit: What did you pass to the SetScale function?
-
Thanks a lot for the bug fixes and new features, everything works like a charm now.
After trying to find the root of my crash problem with edit box, I decided to copy everything from the sample form text file and it seems that my problems might derive from encoding or character issues, which were fixed by copying text from the original form file.
And something to say, so that this post would be more useful:
Is it a bug or feature that when an edit box loses focus, if it had text selected it is still selected, while another edit box has some other text selected and so on ...?
Edit: I don't use the setScale function as all the GUI elements I make are match and if something doesn't match, I make a new image. Also I always set the size, because otherwise the text seems too big for me /in this case I set size to 17, which doesn't really matter that much/.
If you want I can send you and image of what happens and the images and files for you to test as well.
-
Is it a bug or feature that when an edit box loses focus, if it had text selected it is still selected, while another edit box has some other text selected and so on ...?
It is not a bug, but it might be better if the colors changed when the focus is lost.
The problem is that this would require four extra colors and I think it will get harder to understand what every color does.
If you want I can send you and image of what happens and the images and files for you to test as well.
You can do that if you want, although I only need the size of the image and the scale factors to reproduce the problem.
-
I had to make another release as the naming convention in sfml just changed.
I did however make some changes since the last release:
- The 'm_' prefix was dropped on public members.
- Picture now sends a callback when you click on it.
- EditBox now also sends a callback when you press the return key.
The full list of changes can still be found here (http://tgui.weebly.com/changelog.html).
-
Apparently my draw function overrides the one from sfml, so this had to be fixed.
The only other thing that has changed in v0.3.6 is that I have added a Label object.
-
What's the rationale for marking a method const and then using const_cast(this)? Doesn't that defeat the purpose of const member methods in the first place?
-
I guess you are referring to my drawGUI method.
It is something I overlooked. Originally this was the draw function from sfml, I just changed the parameters and later even the name. I just forgot to remove the const.
I was getting errors about 'this' being constant, so I wrote that const_cast, forgetting that this was just because the function was made constant.
It was a stupid mistake. I should have known that I didn't need a const_cast.
Anyway thanks for pointing it out, it will be changed in my next release.
-
Ah, okay. I'm a little unclear on the intricacies of const-correctness, so I wasn't sure if there was any reason to do it that way.
-
I can't get your example code to work. It compiles fine but i get linking errors ... I added all the libs... (system,window,graphics,and libtgui.a)
I'm using Code::Blocks , gcc 4.6
C:\TGUI\lib\32-bit\libtgui.a(Panel.o):Panel.cpp|| undefined reference to `_imp___ZN2sf4FontaSERKS0_'|
C:\TGUI\lib\32-bit\libtgui.a(Panel.o):Panel.cpp|| undefined reference to `__gxx_personality_sj0'|
C:\TGUI\lib\32-bit\libtgui.a(Panel.o):Panel.cpp|| undefined reference to `_Unwind_SjLj_Register'|
C:\TGUI\lib\32-bit\libtgui.a(Panel.o):Panel.cpp|| undefined reference to `_imp___ZTVN2sf4TextE'|
C:\TGUI\lib\32-bit\libtgui.a(Panel.o):Panel.cpp|| undefined reference to `_imp___ZTVN2sf11VertexArrayE'|
:-[
Downloaded last version of TGUI
-
I don't have much time right now to search the problem.
I just checked and the library was build with gcc 4.4.1, maybe that's causing the problem.
For now, until I get the time to test my 32-bit lib, you will have to build it yourself.
If you don't want to build it then you can always just add the source files directly to your project.
To build it yourself:
- Make an empty project and add all my cpp files.
- Make sure the include directory is set.
- Don't link to any library.
- Set the build type to "Static library" (Project>Properties>Build targets>Type)
- You might need to compile with -fPic.
I will try to test my 32-bit lib as soon as possible (which means hopefully this weekend).
-
This kind of error happens when you mix two incompatible versions of gcc. Sadly, on Windows there are two versions that are equally maintained and used: the DW2 version and the SJLJ version.
-
This kind of error happens when you mix two incompatible versions of gcc. Sadly, on Windows there are two versions that are equally maintained and used: the DW2 version and the SJLJ version.
If only it were this simple. Exception handling method is probably the least annoying issue, as it causes linking errors when something is wrong. At least sometimes.
As an aside, this distinction applies to every platform on which GCC supports zero-cost exceptions (on these it doesn't, setjmp/longjmp is the only choice). It just happens that on Windows there's no consensus on which unwinding to use.
There are some more possible differences between GCC builds (these affect Windows only):
- runtime library: mingw-rt + w32api vs MinGW-w64
- GCC threading model: win32 vs posix
- GCC version: 4.7+ vs older versions - GCC 4.7 for Windows on IA-32 starts to use different calling convention for non-static member functions by default (thiscall, as most other compilers on Windows do), which is incompatible with the one used by older versions (cdecl).
Hence, if you don't want to take chances, it's best to have compiled everything with the very same compiler.
-
This is even worse that what I thought. I have no idea which precompiled versions of SFML 2.0 for gcc on Windows I should provide >:(
-
This is even worse that what I thought.
Yup. And I didn't even say anything about third-party patches which also can make the thing incompatible with everything else. Therefore...
I have no idea which precompiled versions of SFML 2.0 for gcc on Windows I should provide >:(
...I think the best way is to provide no precompiled versions at all. Just provide clear building instructions, then even inexperienced users should be able to build it themselves.
-
I guess you could set it up for gcc so all they have to do is CD to the folder in the command prompt and run make? The most complex part of that is ensuring that make is in your path.
-
The problem is that CMake create build files with absolute paths inside. To distribute something as simple as "set PATH ... & make & make install" I would have to create specific makefiles.
I think I'll provide a release for the version of gcc shipped with Code::Blocks, since many people are using it (especially beginners). Don't know about other versions.
-
This kind of error happens when you mix two incompatible versions of gcc. Sadly, on Windows there are two versions that are equally maintained and used: the DW2 version and the SJLJ version.
Thx, i didn't know that :)
I just checked and the library was build with gcc 4.4.1, maybe that's causing the problem.
For now, until I get the time to test my 32-bit lib, you will have to build it yourself.
If you don't want to build it then you can always just add the source files directly to your project.
I'll build it and see what happens. thx
-
Good news: the first version of the Form Builder is ready!
(http://i1119.photobucket.com/albums/k625/texuz/TGUI/TGUIFormBuilderv01.png)
I have also made some changes to TGUI. The most important are:
- Mac OS X support
- Label has a callback on click
- All object have a getSize function
- Some bug fixes
And now the bad news: the form builder is far from being finished.
- You can already drag objects around, but for scaling you will still have to change the property manually.
- A lot could be improved if my gui would be able to create child windows, which won't happen anywhere soon.
- There is no load function yet. You can only save a file.
- Negative positions don't work.
- I just noticed that you can't remove an object.
- There are no binaries for Linux yet.
EDIT: I just fixed the most important problem: you couldn't remove objects.
I also made it possible to set an object to a negative position and I provided linux binaries.
The other problems will have to wait until I release TGUI v0.4.
-
Has anybody tried to use this with the latest SFML 2.0 RC ? It compiles correctly but after the init function it seg faults.
-
I wish I could try if it works with the rc version, but I can't even get it to compile and I don't have the time to find out what I am doing wrong.
There were hardly any modifications in sfml2 since the version that can be found on my site. Does it work with this version?
If so then you can use that version until I have the time to compile a new lib.
If you really can't get it to work then without segfaults then you should temporary use the tgui source code directly in your project instead of using the library.
-
The Form Builder didn't work correctly, so I couldn't delay my release till July.
TGUI v0.4 is not finished, but you can already download the latest revision (which is just as stable as v0.3.6 was).
Changes:
- The Panel struct has been rewritten and has been tested.
- Objects can be moved to the back or to the front.
- In the Form Builder v0.2, save and delete buttons now work correctly and a load button was added.
- You can also easily scale the objects in the new Form Builder.
- In the new TGUI Object Files v0.2, you can add panels and use multiline comments.
Because most of my library files didn't work, I now have a complete new way of distributing.
The latest version can now be downloaded on GitHub (https://github.com/texus/TGUI).
You will have to build it yourself with CMake. I have already started with writing tutorials (http://tgui.weebly.com/tutorials.html).
If you are using Mac OS X then you will have to wait a little bit for the libraries.
Until I finish my CMake script you will have to use the source code directly.
The Form Builder is only provided for Windows, but the source code is also provided, so you can use it on Linux or Mac too.
-
Hi, I've got a question. I'm a newbie to SFML and I want clarification on one thing. TGUI includes everything SFML has, correct? E.g. if I create a TGUI window, I can use it in the same way I would use a SFML one? What if I want to use stuff such as SFML/Network.hpp, or even OpenGL?
And one more thing: Is it possible to change the textures/colors if I don't like the default ones?
Thanks a lot.
-
if I create a TGUI window, I can use it in the same way I would use a SFML one?
Yes, my window is just a wrapper around sf::RenderWindow, so you can still use all its functions.
But you will still have to link with sfml, linking to only tgui isn't enough.
What if I want to use stuff such as SFML/Network.hpp, or even OpenGL?
For networking or audio there is no problem at all. You can use it in exactly the same way as when you aren"t using TGUI.
I am not sure about OpenGL. I never tested it so I can't tell you if it would work.
If you use it correctly it will probably work but I will test it in the future to be sure.
Is it possible to change the textures/colors if I don't like the default ones?
Absolutely. The colors can be changed by calling a function like setTextColor, setBackgroundColor or changeColors (look at the example code (http://tgui.weebly.com/example-code) where the combo box is created).
Changing the images is simply a matter of passing a different pathname to the load function.
Just copy the Black folder, rename the new one to what you want, edit the images in it and pass the new pathname to the load function.
It might be a little hard to understand the image filenames and the info.txt file in the beginning, but if you have any questions I will be here to answer them.
-
...
Thank you very much! That covered everything :)
-
I got good news: the TextBox is now working.
The only thing that is still missing is word wrap, but that will be for later.
Example code on how to use the TextBox:
tgui::TextBox* textBox = window.addTextBox();
textBox->load(280, 160, 30); // Width, height, text size, (optional scrollbar pathname)
textBox->setPosition(440, 400); // Set the position of the TextBox
textBox->setBorders(4, 4, 4, 4); // Add a border of 4 pixels on every side
textBox->setText("This is the text that will be displayed inside the TextBox.");
// To change the colors, simply call changeColors (the function has more optional parameters)
textBox->changeColors(sf::Color::White, sf::Color::Black); // background color, text color
-
The GUI looks nice and the code is easy to understand.
I tested SFGUI and TGUI.
On my Windows 7 PC (30% lesser CPU usage then SFGUI? -> Without the sf::sleep(sf::milliseconds(100)); in TGUI Loop).
Why this? is SFGUI to complex? Or because of RenderWindow slower? Or just my imagination? :)
-
I have no idea why this would be, but I think it will depend on the situation. I doubt that sfgui would be slower than tgui.
-
The GUI looks nice and the code is easy to understand.
I tested SFGUI and TGUI.
On my Windows 7 PC (30% lesser CPU usage then SFGUI? -> Without the sf::sleep(sf::milliseconds(100)); in TGUI Loop).
Why this? is SFGUI to complex? Or because of RenderWindow slower? Or just my imagination? :)
On the contrary. You see more CPU usage with SFGUI because indeed more CPU time is being used because we optimized the library to the point where we offload certain portions of the processing from the GPU to the CPU and therefore the CPU and GPU times are equal. Search for my many other posts and you will see my statements about how SFML is bottlenecked by GPU processing power and bus transfer bandwidth. We eliminate this in SFGUI and so the application will pump out more frames per second but also make more use of the CPU which is expected. You can test this by observing the framerate of your test benchmark for both libraries.
It might be possible that at a lower widget count the overhead that SFGUI is associated with won't make it worth using, however it is amortized at higher, more typical widget counts which is what we optimized for.
-
If this feature doesn't already exist, it would be nice to have a picture button. If you add that, I will totally use this GUI.
-
My Picture class can give a callback when clicking on it, if that is what you mean.
-
So, in other words, the picture class can be used as a button?
-
Yes.
The difference with the Button class is that a button can change its image on mouse hover or mouse down, while the Picture is just one image that can (if you want it to) send a callback on mouse click.
A Button is also able to send a callback when it is focused and you would press the space bar or the return key.
-
Sweet. This system looks very promising. You've got my vote.
-
Hi. I did a little looking at the documentation that you have and I couldn't really devise a way to make the text boxes lose focus when you click out of them. Am I missing something? Aside from that I've been enjoying using your library.
Thanks.
-
The text box (and any other object) will only lose focus when focusing another object (by clicking on them or by using the tab key).
I will look into it, if it is easy to solve (which it probably is) then I will fix it within the next few days.
-
Hi texus,
i played around TGUI a bit and I like it very much.
I created some control skins and I plan to write
simple game development articles using it.
Keep up the good work.
-
I am happy that you like it.
-
TGUI v0.4 is now officially released.
To celebrate this, I have created a new style, called "BabyBlue" (actually I copied most of it from Michael Donovan's Baby Blue UI Kit (http://tympanus.net/codrops/2012/07/07/freebie-baby-blue-ui-kit-psd/)).
It can be used as an alternative to the default Black style.
Here is a screenshot of the new style:
(http://i1119.photobucket.com/albums/k625/texuz/TGUI/TGUIv04BabyBlue-1.jpg)
The goals for TGUI v0.5 are not yet set, but I was thinking about adding child windows.
For the rest it will be mostly improvements to what I have already instead of adding new things.
-
I've found a fairly severe bug with tgui (unless I'm doing something wrong). I created a window which is 800x600, and a button which is 600x600, but I have also used a sf::View. The view is created in a larger rectangle so that anything originally 200x200 looks 25x25. This works correctly with the button - the 600x600 button does not take up much of the screen - but the area in which I can click it does not adjust. If I click on the button, it doesn't work, but if I click anywhere where a 600x600 button would be without a sf::View, the button clicks.
-
This is indeed a serious bug.
Edit: It is fixed now.
-
Is the fixed version available for download?
-
Yes, any download you find should contain the fix.
-
Also, the form builder crashes whenever I try and load.
EDIT: On the newest version it doesn't.
-
I am going to need a little bit more information about that.
I tested the form builder yesterday on my windows 7.
What do you mean by 'crashes'? Does it give an error?
If it just immediately closes without giving an error then it is because it can't find the images folder or the 'FormObjectWindow.txt' file. They should be in the same folder as the executable. In the future I will make it output an error for this, but currently the program just closes.
If it does crash with an error then you should give me the error and the way you have build tgui (OS, compiler, static/dynamic linking).
EDIT: Yes there was indeed a small problem with it in the original release, but I've made the fix together with the view problem. I though you were saying that there was a problem with the latest version.
-
Yes, on the version I was using (the one with the View crashes) whenever I pressed 'load' it would just stop responding and windows would close it. It's fixed in the latest version, so now I finally have a working GUI for my game! :D
I've found what I think is an issue with hide(), though. I am running this code:
void TguiWidget::hide(){
for(std::map<std::string,std::shared_ptr<tgui::OBJECT>>::iterator it = objects.begin();it!=objects.end();it++){
it->second->hide();
}
displayed = false;
}
`objects` contains a Button, Label and Button, 'wood_icon', 'money_icon', and 'shop_exit' respectively. 'money_icon' and 'shop_exit' are hidden fine, but 'wood_icon' stays on the screen. Its events get disabled - hovering over it doesn't change anything and it doesn't register any clicks even though the callbackID is not 0 - but you can still see it.
I used the form builder for this. I've attached the form.txt.
[attachment deleted by admin]
-
Ok, it is indeed a bug. Thanks for finding it.
There was something wrong with my drawing code: when ALL objects are invisible then the first object was still drawn.
I've called the fixed version v0.4.1.
-
Hello Texus,
Great work on TGUI. I found it very useful for my JSGameClient project.
I made one significant change for my own use which I thought I would report back on:
I didn't like that the developer has to use a descendant of the RenderWindow class in order to use TGUI so I created a Form class (a modified Window) that removes the subclass and instead requires a sf::RenderWindow * in the constructor. I thought I would recommend this change be included in the main TGUI as an alternative to using the Window class for those like me who think subclassing an SFML Window is unnecessarily restrictive.
One "issue" I encountered was the Panel class hides some public members mouseOnObject, addCallback, and another one. Easy for me to change so no big deal.
A recommendation I have aside from the two things mentioned above would be to remove the loading from a file function in Window and make the loader a separate method or even better break it up and make it a class.
Anyway, I found TGUI very easy to hack on and I really appreciate how you structured the project. I made a V8 JavaScript binding for the modified version so that the TGUI can be accessed from JavaScript.
Thank you,
-Steven
-
I am glad you found the project useful.
Deriving the window from RenderWindow is done to make it easier to use and I don't see any reason why you would want to split them. What restriction is there? In the changelog on GitHub you said that it would make it possible to have multiple forms, but as I already commented there this can be easily done with panels. If you of course see another reason then feel free to share it, but for the moment I don't see any advantages of such a change.
Is there any reason why you want to access these funtions from Panel? I don't see why you would need them.
I would make the mouseOnObject function public, just because it is public in all other objects, but I have no motivation for making the addCallback function public. If you want to fake a callback, then add it directly to the queue in window instead of making my panel send it to the window.
The loading from file function should be rewritten in the future anyway, so I am open for such suggestions.
But I am not sure how I could take it out of the window. The function has to add the objects to a parent in order to load them.
It is worth thinking of, but it won't be for soon.
-
Hello Texus,
As I stated above:
I didn't like that the developer has to use a descendant of the RenderWindow class in order to use TGUI
No point trying to understand it. It is like trying to say why one person considers Picaso a great artist and another person looks at it and says "meh." :)
The suggestion is just an idea, offered for my own benefit. A recommendation to implement these changes would save me time if you would accept them and I could spend less time keeping the custom TGUI in sync, so it falls under the category of there being "no charge for asking you." But I did so with the an expectation of rejection.. Most programmers I know don't like being asked to change their stuff and I myself am no exception.. ;D
-Steven
-
I see no disadvantages, it would make you happy and it only takes a few minutes, so why wouldn't I change it?
The Form class can be usefull in the future too if I ever decide to port my project to sdl.
I'll make the following changes in v0.5 within the next few days.
- There will be a Form class (it will still have the loadObjectsFromFile function).
- mouseOnObject and objectFocused will become public in Panel (addCallback will stay private, you will never need it)
-
Thanks Texus, that is really nice of you. The Group class defines addCallback as public which is why it was giving me issues. There was a couple ways I could work around it, but the easiest seemed to be making it public in the descendant as well. I assumed it was simply an oversight and you intended it to be public.
-Steven
-
http://i.imgur.com/RUUsy.png
I am a novice when it comes to cmake. At first I had an issue with finding the CMAKE directory so I changed it to the mingw located in Code::Blocks
Now I can't get past this. I have just recently dove into stuff like this and am not quite sure what it's looking to fix.
Thanks for any help.
-
I think you are pointing to the wrong MinGW folder. When I start CMake it automatically finds the folder "C:\MinGW" which was the default location when I installed it with CodeBlocks. The folder that u use also exists on my computer, but it is not used in any CMake options.
I think it is strange that CMake doesn't find this folder automatically. I had a similar problem some time ago and I solved it by reinstalling CodeBlocks. After that it compiled without any problems.
-
C:/PROGRA~2/CODEBL~1/MinGW/bin is not a valid make program (CMAKE_MAKE_PROGRAM). Did you change it? It should normally be "C:/Program Files (x86)/CodeBlocks/MinGW/bin/mingw32-make.exe".
And you should avoid spaces in your toolchain paths, make/gcc don't like them.
-
I installed a stand alone version of MinGW and that worked with CMake. I assume it was because my MinGW was located in C:\MinGW.
Now when I try to build the project (install) I get this.
-------------- Build: install in tgui ---------------
Using makefile: Makefile
Execution of 'make.exe -s -f Makefile install' in 'C:\sfml\TGUI\build' failed.
Nothing to be done.
At least I made progress. Where should I proceed from here? Thanks.
-
I am afraid that all I can do is guess right now.
I have tested it multiple times and I never had any problem, so I never experienced your situation.
I think it was even tested on an empty windows, just the codeblocks install with mingw and for the rest nothing installed.
You could try using the 'all' configuration, the only difference is that my Form Builder and the tgui.dll won't be copied to the correct directory.
The only difference I see now is that you have 'make.exe', while in my log it sais "Running command: C:/MinGW/bin/mingw32-make.exe -f "E:/Documents/TGUI/build/Win32_CodeBlocks/Makefile" VERBOSE=1 install".
So either you find a setting in codeblocks to change from make to mingw32-make or you will have to run it from the command prompt.
The only reason why I don't use the command prompt in the tutorials is because it might be to difficult for beginners. But you could take a look at the sfml tutorial (http://www.sfml-dev.org/tutorials/2.0/compile-with-cmake.php) and try the steps from there. U will have to generate 'MinGW makefiles' (not the CodeBlocks ones) and build it yourself from the command prompt with mingw32-make.
-
Hey Texus,
I don't know how easily it could be implemented, but is it possible to have animated interfaces? For example, the button could have multiple "mouse over" and "mouse leave" subimages. Mousing over a button could have 5 subimages that fade dark, etc.
-
It should be possible, I just don't have the time for it right now. But I'll definitely consider it before the final release of v0.5.
-
find a setting in codeblocks to change from make to mingw32-make
This worked!
ok, now I think we are down to the last problem. I assume this is because of the SFML version I am using.
'BackSpace' is not a member of 'sf::Keyboard'|
I am using SFML 2.0 RC. Should I change these lines to anything?
EDIT: Changed all instances of BackSpace to Back and it compiled! I think I can finally get it up and running.
Thanks a bunch!
-
I got a few design questions for those who are using my gui (or anyone else who wants to give his opinion).
First of all, objects can be focused. This means that you can use the tab key to focus another object. Is this really necessary? I don't really see many use cases for focusing objects. Does anyone really needs this? Removing this focussing will not only spare me the work of adding it to the objects that don't have it yet, but it will also open other possibilities (e.g. adding a tab character in a text box). On the other hand, you will no longer be able to focus a button and press enter or space to trigger it.
Secondly, something has to happen with selecting text in edit boxes and text boxes. Currently you can have text selected in multiple edit boxes at the same time. This shouldn't be to hard to solve, but it brings up a question. Is it necessary that when you click outside the edit box, the text stays selected? Currently the text will get deselected anyway when clicking back into the edit box. It would even save another color if it would get deselected right away when clicking on another object.
Let me know what you think about it.
-
Although I'm not using TGUI, I'll still give you my feedback. I mean the questions aren't that specific to TGUI. ;)
This means that you can use the tab key to focus another object. Is this really necessary?
I think this depends heavily on the use cases of TGUI. For GUI applications, removing that feature would be a big no-go. Take for example a login dialog with a username and a password text field and a button. Would you really like to select the first text field, enter the name, then grab the mouse again, then enter the password, grab the mouse again and click 'login', or wouldn't you much rather, enter name, tab, enter password, tab, enter?
On the other hand, when you use TGUI for a game I guess it wouldn't really matter, since you most probably will have your mouse in your hand anyways, then again there could still be some use cases.
My opionion: Don't remove it!
but it will also open other possibilities (e.g. adding a tab character in a text box).
I'm not sure how you handel textboxes at the moment, but normally for GUIs one makes a difference between textarea boxes with multiple lines and a one liner textbox. For a one liner textbox it usually doesn't make sense to allow tabs (tabs are there for formatting, what would one want to format in one line) but they can make sense in a textarea. Now there are diffrent situations where one wants to allow tabs in textarea fields and one maybe doesn't, so a switch that lets the programmer use tab in one or the other way would kind of solve that problem.
Secondly, something has to happen with selecting text in edit boxes and text boxes. Currently you can have text selected in multiple edit boxes at the same time. This shouldn't be to hard to solve, but it brings up a question. Is it necessary that when you click outside the edit box, the text stays selected? Currently the text will get deselected anyway when clicking back into the edit box. It would even save another color if it would get deselected right away when clicking on another object.
Both possibilites exist in other GUIs, so I guess it also depends a bit on the kind of application. If you make something in the direction of a text editor losing the selection can be quite annoying, for other uses IMHO it doesn't really matter. Since the selection gets lost anyway I'd say you can automatically deselect it (or does it stay selected when 'tabbing' the the textbox?
-
Thanks for your feedback.
You are right about the use in a login screen, so I should indeed put an option somewhere to enable/disable the use of the tab key. Then you could add tabs in a (multiline) text box, depending on this option. If tabbing between objects is disabled then you will be able to use tab chars, otherwise not.
I don't think anyone is going to write a text editor with my gui so if it doesn't really matter otherwise then it might be better to just drop the selection. Then you no longer have to provide an extra color for when the textbox is unfocused and it will have some impact on speed as well. If I would keep the selection then I would have to loop through all my objects every time I make a selection, just to make sure that no other edit box has something selected.
Tabbing back to the edit box keeps the selection and it should have been kept too when clicking back on the edit box, but the text gets unselected by a small bug. Normally I would just fix it, but just deselecting the text when focusing another object seems to have it advantages.
-
Hi Texus, I just wanted to alert you to what I think is a bug in your CMake script.
I followed your instructions for setting up with the CMake GUI. I pointed SFMLDIR to ".../SFML/SFML-2.0" and SFML_INCLUDE_DIR to ".../SFML/SFLM-2.0/include". The obj files compiled fine, but I got tons of linker errors all complaining about sfml. This happened with both NMake and VS 2008.
After some investigating, I noticed that in project settings in VS 2008, the Linker/Input was pointing to ".../SFML/SFML-1.6/[libs]". That just happens to be where I keep my 1.6 version. I double checked several times with CMake and tried recreating everything to make sure I wasn't pointing CMake to the wrong folder, but it kept trying to use the 1.6 libs.
Finally I just moved every folder inside ".../SFML/" other than the SFML-2.0 folder somewhere else and tried again. This time it worked. So that's really strange. Somehow the presence of the SFML-1.6 folder makes the generated scripts point to those libs.
-
Hi Texus, I'm having problems with the Form Builder. Strangely, it will only show objects that are in the bottom left of the window (see attachment).
As you can see, there is an obvious rectangle of space at the bottom left where objects show up, but anything outside that space does not. You can clearly see objects being cutoff at the edge of the space. If I create a new object, the properties window will update with the new object's information, but I won't be able to see it at the top left. But I can click on it and drag it to the bottom left where it will show up.
Notice also the Fraps fps numbers in the four corners of the window. The frame rate is around 19-20 fps. You can see it at 19 in the bottom left. However in the other three corners, you see the numbers "19" and "20" pasted on top of each other, never clearing. And in case you didn't know, Fraps only puts the fps in one corner at a time.
Clearly something is wrong here. I've tested TGUI in my own programs and have found no such problems.
SFML2 and TGUI were both built from freshly downloaded src today (8/1/2012).
I've attached the FormBuilder.exe file (see attached rar) so you can test it yourself. Could you possibly send me a working copy of the exe?
[attachment deleted by admin]
-
About the CMake problem, I won't be able to do much about it. The script clearly looks for version 2.0, so I don't know why it wouldn't work. But thanks for reporting, if someone has a similar problem in the future then I at least know how to solve it.
There have been some strange rendering problems in the form builder before, but I think all problems should be solved now in the latest commit of v0.5.
You can find the executable that I compiled here (http://tgui.weebly.com/downloads), it is compiled with this latest version, so it should work.
I can't test it on windows right now, but the exe seems to run perfectly on linux through wine.
I couldn't test your version as it was build dynamically and I couldn't find the corresponding dlls (I have too many different versions on my pc).
-
Sorry for taking so long to point this out after the last view bug - I was on holiday :D The objects will only work correctly with Views if you set the view after the object is created. I set the view then create all the objects but change the view when the window is resized, which means in order to use the GUIs I have to resize my window.
-
I don't have any problems with using a view, neither in v0.4 or v0.5.
A lot more testing happened in v0.5 so you might want to try that version though.
If you still have problems then could you please post some code to be sure that we are testing the same thing?
-
At the moment, the game is created in a window, and the view is immediately set. Then the GUI buttons are created and displayed, but the click positioning is off (exactly like before you fixed it the first time) until I set the view again, after the objects have been created.
-
It's strange. If I debug my program (in linux), a resize event is send when the window is created and thus my gui will get the chance to make the needed calculations. You aren't receiving any resize events until you manually resize the window?
Does it help if you put the following code after you change the view in the beginning of your program?
sf::Event event;
event.type = sf::Event::Resized;
event.size.width = 800; // The width of the window, not the width of the view
event.size.height = 600; // The height of the window, not the height of the view
window.handleEvent(event);
I will try to debug it on my windows tomorrow.
-
Nope, that doesn't have any effect. Also, is there any way to make callback activate when the object is underneath another object? I have a "selection box" object, which is a square with an outline and transparent centre positioned exactly on top of the object , but no callback is fired when I click on the object underneath.
-
I might have an idea on how to solve the view problem, I'll try it tomorrow.
For your other problem, it is not yet possible but it was on my todo list. As it shouldn't be to hard to implement I will give it a higher priority.
If I make a change it will be in v0.5, so I am afraid that even if I make those fixes you will still have to upgrade if you are still using v0.4.
-
That's not a problem, upgrading SFML and tgui was on my todo list too. Thanks!
-
The formbuilder.exe I downloaded works fine. I wonder what could have caused such a strange bug with my build.
-
I wonder what could have caused such a strange bug with my build.
I made a small fix in my uploaded version. Before, the three windows were rendered together. I don't know why, but apparently it gave some strange results. If I had known that it caused that kind of behaviour I would have uploaded it earlier (I already made the fix a few days ago, I just didn't put it online yet).
-
@pighead10
I made some changes with the way the view is used in v0.5, so hopefully this solves your problem.
If your selection box is a Picture then you should now be able to click through it. Other objects will allow this in the future, but for now only a Picture will allow you to click through it.
-
Hi Texus,
I just DL'd you v 0.5 and am building it for Code::Blocks, but I'm getting errors. I've fixed most of them, from this:
const sf::Font* EditBox::getTextFont()
{
return m_TextBeforeSelection.getFont();
}
to
const sf::Font& EditBox::getTextFont()
{
return m_TextBeforeSelection.getFont();
}
Changing * to &, as getFont() returns a reference, not a pointer.
(I had to do that for multiple .cpp's, and I modified where it was calling those functions.
But, then I ran into a bigger issue, which I can guess a fix, but I'm not sure. Calling this:
unsigned int Builder::getClickedObjectID(sf::Event& event)
{
// Check if the left mouse was pressed
if (event.mouseButton.button == sf::Mouse::Left)
{
float mouseX = event.mouseButton.x / (mainWindow.getSize().x / mainWindow.getView().getSize().x);
float mouseY = event.mouseButton.y / (mainWindow.getSize().y / mainWindow.getView().getSize().y);
unsigned int highestID = 0;
unsigned int objectID = 1;
#define FindObjectNr(Object, objects) \
for (unsigned int i=0; i<objects.size(); ++i) \
{ \
tgui::Object* object = mainWindow.get<tgui::Object>(tgui::to_string(objects[i].id)); \
\
if (object->mouseOnObject(mouseX, mouseY)) \
{ \
if (highestID < object->getObjectID()) \
{ \
if (highestID > 0) \
object->mouseNotOnObject(); \
\
highestID = object->getObjectID(); \
objectID = objects[i].id; \
} \
} \
}
FindObjectNr(Picture, pictures)
...
Gives me an error because getObjectID() is not defined anywhere. I searched all through the code, and it's not there. I can modify Objects.hpp, add the funciton, add an id, and just, in the constructor, increment a global ID and assign it that way, but I'm not sure what it is supposed to be used for.
Any ideas?
Thanks! Looking forward to using this.
-
The first problem, the one with the font is because you aren't using the latest sfml version.
I made the change from reference to pointer this morning because it was changed in sfml last night.
I forgot to update my form builder code after my rewrite from two days ago. I'll fix it as soon as possible.
(You might be able to use the executable from here (http://tgui.weebly.com/downloads) until then).
-
WOW! I downloaded the latest SFML snapshot two days ago, he updates sfml yesterday, and you update TGUI between now and then too! Just my bad luck I guess :)
I've made the change to supply a unique ID from getObjectId() and it builds, and I can run Form Builder, but I'm not 100% sure it's right. BTW, running the executable formbuilder.exe you linked just closes immediately with no errors.
Thanks.
-
I should really do something about the error handling in my form builder. It closes immediately because it can't find its recources. If you execute it next to the images folder and the FormObjectsWindow.txt file then it should run.
Edit: The form builder should now work again.
-
A simple request. Would it be possible to make the button be able to also just load am Image as the button? So, whenever anyone clicks the image, the button callback kicks off?
I'm looking for something simple like that, so i figured you could overload tgui::Button::load() to take an image name (or maybe an sf::Image or sf::Texture).
Thanks for the work!
-
I am not sure what you mean exactly. Do you just want a single image, so no hover and down images?
If this is what you want then you can just use the Picture struct. It will also send a callback when you click on it.
-
I am not sure what you mean exactly. Do you just want a single image, so no hover and down images?
If this is what you want then you can just use the Picture struct. It will also send a callback when you click on it.
Oh, yes, that's what I want. I didn't realize it would send a callback, so never mind. Thanks again!
-
I've come across another fatal error - it's either me or tgui. Since upgrading to tgui 0.5 (and to the SFML RC), whenever I try and draw an object an unhandled exception occurs, showing me this code in visual studio 2010:
void RenderTarget::draw(const Vertex* vertices, unsigned int vertexCount,
PrimitiveType type, const RenderStates& states)
{
// Nothing to draw?
if (!vertices || (vertexCount == 0))
return;
if (activate(true))
{
// First set the persistent OpenGL states if it's the very first call
if (!m_cache.glStatesSet)
resetGLStates();
// Check if the vertex count is low enough so that we can pre-transform them
bool useVertexCache = (vertexCount <= StatesCache::VertexCacheSize);
if (useVertexCache)
{
// Pre-transform the vertices and store them into the vertex cache
for (unsigned int i = 0; i < vertexCount; ++i)
{
Vertex& vertex = m_cache.vertexCache[i];
vertex.position = states.transform * vertices[i].position;
vertex.color = vertices[i].color;
vertex.texCoords = vertices[i].texCoords;
}
I tried drawing something in SFML without tgui and it worked fine. I haven't changed any code at all since upgrading other than a few of the function call names to make it work with the new tgui.
-
What objects are you drawing?
Could you try to narrow the problem down by creating just one object and then try to find out which object is causing this?
-
Sorry, I meant an SFML sprite. The only thing I can think of, as it works without tgui, is that the tgui window wrapper is somehow breaking this (or if I needed to change something else for the update, but there is nothing in the upgrading tutorial that I have not done).
-
You need to make use of the call backtrace, which will tell you what function call is causing the error. ;)
-
You need to make use of the call backtrace, which will tell you what function call is causing the error. ;)
I already know what line is causing the error!
window.draw(sprite)
-
So if I understand it correctly, you are just drawing a sprite, nothing more?
If it worked with v0.4, then something must be broken in v0.5, but I don't have any problems here so you will have to find out what is causing it.
- Have you tried with some basic code, nothing more than creating a window and drawing the sprite?
- Try if it makes a difference if you use sf::RenderWindow or tgui::Window. Is the problem with just linking and including, or does it only occur when using tgui in your code?
- Are you using debug libs or release libs for both sfml and tgui? You can't mix them.
If you think that the problem lies in tgui::Window then you can test with tgui::Form (it isn't in the tutorials, you will need to use the documentation or just look in the header file).
-
So if I understand it correctly, you are just drawing a sprite, nothing more?
If it worked with v0.4, then something must be broken in v0.5, but I don't have any problems here so you will have to find out what is causing it.
- Have you tried with some basic code, nothing more than creating a window and drawing the sprite?
- Try if it makes a difference if you use sf::RenderWindow or tgui::Window. Is the problem with just linking and including, or does it only occur when using tgui in your code?
- Are you using debug libs or release libs for both sfml and tgui? You can't mix them.
If you think that the problem lies in tgui::Window then you can test with tgui::Form (it isn't in the tutorials, you will need to use the documentation or just look in the header file).
I'll test with some basic code later, I am going out for a while. Currently what I have tested is my framework doing nothing but creating the window and drawing a sprite - nothing to SFML is done other than that - using a tgui::Window, and another with a completely minimal program without tgui (using a sf::RenderWindow) to draw a sprite which works. I highly doubt it is my framework but I'm unsure whether it is using tgui or using the tgui window which is causing the problem.
-
I built my project again today, and it works! I've absolutely no idea why, but it does.
-
@pighead10
Good to hear that you got it to work.
@Ruckamongus
A full animated interface like you suggested would take too much time and won't come in the near future, but for now I do have an AnimatedButton.
You can use it like this:
tgui::AnimatedButton* button = window.add<tgui::AnimatedButton>("myButton");
button->load("TGUI/objects/AnimatedButton/Example");
button->setFrame(5); // Make the last frame visible, to avoid animation at start
The button is made to replay its animation over and over, but by setting the frame duration of the last frame to 0 you should get the effect you wanted. The only problem I saw so far is that it doesn't really look good in combination with the mouse down image, but it might look a lot better if you don't use the example images (they don't fit together).
-
Bug:
for(int a=1;a<=cols;a++){
std::string name1 = "backpackgui_spacer"+std::to_string((long long)counter);
std::shared_ptr<tgui::Picture> objspacer = std::shared_ptr<tgui::Picture>(SfmlFramework::Singleton()->window->add<tgui::Picture>(name1));
objspacer->load("noitem.png");
objspacer->callbackID = 50+counter;
objspacer->setPosition(m_pRoundManager->getMapSize().x/2*tile_size - tile_size - ((cols/2)*tile_size) + tile_size*a,m_pRoundManager->getMapSize().y*tile_size-100 - tile_size - rows*tile_size + i*tile_size);
objspacer->moveToBack();
The last line, objspacer->moveToBack(), causes the program to exit with:
First-chance exception at 0x775bb9bc in Build to survive.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x003ee408..
First-chance exception at 0x775bb9bc in Build to survive.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x003edd20..
First-chance exception at 0x775bb9bc in Build to survive.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000..
-
Could you try without using shared_ptr and do it like in the tutorials?
I just did a little test (but with boost instead of c++11) and I only got a crash when using the shared pointer.
I don't really know how shared_ptr works exactly, but I do know that moveToBack changes the location where the pointer is stored and this could perhaps be causing the problem.
-
Ah. Well, my framework is entirely structured around shared_ptrs, so that won't be possible. Also, Avast blocks FormBuilder.exe - "Win32:MalOb-HC [Cryp]"
EDIT: Deleted it (I was using the debug version) and regenerated it as the release mode and it is no longer detected as a virus. I probably have some hitherto unknown virus which infected it the first time.
EDIT X2: The formbuilder immediately exits upon opening.
-
As I said a few times before, the form builder will close if it can't find its resources. The latest version should however print an error, so if you start it through the command prompt then you should see what's wrong.
I am going to do some more tests tomorrow, but I fear that your smart pointer is trying to delete the pointer when it is reallocated and as the tutorial says: never delete the pointer. If this really turns out to be the problem then there is nothing else to do then redesign your framework.
-
I got bad news. Although the crash in moveToBack was caused by my code (it's fixed now), the shared_ptr did exactly what I was afraid of. At the end of your for loop, when the smart pointer goes out of scope, it deletes the pointer. So the program will crash on the next draw call.
But I don't see what big changes you would need to make in your framework to solve this. It's not like you can't keep using smart pointers at other places, just not with my objects.
As far as I see (I don't have your full source of course, so I could be wrong), all you have to do is change this line
std::shared_ptr<tgui::Picture> objspacer = std::shared_ptr<tgui::Picture>(SfmlFramework::Singleton()->window->add<tgui::Picture>(name1));
into thistgui::Picture* objspacer = SfmlFramework::Singleton()->window->add<tgui::Picture>(name1);
That should work fine and, unless you are storing the pointers somewhere (which you normally shouldn't do), you don't even have to change anything else.
edit: You will probably have more of these lines and thus more to change than just one line, but the point is that only the declaration of the objects should change.
-
I got bad news. Although the crash in moveToBack was caused by my code (it's fixed now), the shared_ptr did exactly what I was afraid of. At the end of your for loop, when the smart pointer goes out of scope, it deletes the pointer. So the program will crash on the next draw call.
But I don't see what big changes you would need to make in your framework to solve this. It's not like you can't keep using smart pointers at other places, just not with my objects.
As far as I see (I don't have your full source of course, so I could be wrong), all you have to do is change this line
std::shared_ptr<tgui::Picture> objspacer = std::shared_ptr<tgui::Picture>(SfmlFramework::Singleton()->window->add<tgui::Picture>(name1));
into thistgui::Picture* objspacer = SfmlFramework::Singleton()->window->add<tgui::Picture>(name1);
That should work fine and, unless you are storing the pointers somewhere (which you normally shouldn't do), you don't even have to change anything else.
edit: You will probably have more of these lines and thus more to change than just one line, but the point is that only the declaration of the objects should change.
There's the problem - I'm storing every pointer for every object, and the resource freeing process is based around std::shared_ptr's. However, in my code here:
for(int a=1;a<=cols;a++){
std::string name1 = "backpackgui_spacer"+std::to_string((long long)counter);
std::shared_ptr<tgui::Picture> objspacer = std::shared_ptr<tgui::Picture>(SfmlFramework::Singleton()->window->add<tgui::Picture>(name1));
objspacer->load("noitem.png");
objspacer->callbackID = 50+counter;
objspacer->setPosition(m_pRoundManager->getMapSize().x/2*tile_size - tile_size - ((cols/2)*tile_size) + tile_size*a,m_pRoundManager->getMapSize().y*tile_size-100 - tile_size - rows*tile_size + i*tile_size);
//objspacer->moveToBack(); BREAKS
if(i==1 && a == 1){
std::string name = "backpackgui_selected";
std::shared_ptr<tgui::Picture> selected = std::shared_ptr<tgui::Picture>(SfmlFramework::Singleton()->window->add<tgui::Picture>(name));
selected->setPosition(objspacer->getPosition());
selected->load("selected.png");
selected->moveToBack(); //works fine
objects[name] = selected;
The moveToBack() call that is commented out crashes, but selected->moveToBack() later on works fine.
-
I wouldn't know why the moveToBack works in only one of the two cases, but from what I saw when I was debugging this morning, I am even suprised that it works in one case. In my tests, the pointer was deleted at the end of the for loop and the program would just crash at the next draw call.
I don't know if you already tested with the version that I uploaded this morning, but for the rest there is nothing I can do. When I started with this gui I made the choice to store all objects inside the window and returning pointers to those objects so that you can change them. I did this because you wouldn't have to store the objects yourself, nor would you have to take care of cleaning them up. But the smart pointer just seems to take too much ownership and destroys the object when the pointer goes out of scope.
If you want to keep using my gui then there will be no other way then to change your design, as I can't change mine anymore. I don't like to say this, but the only solution I see is either to not store the objects, using the get function to retreive them and use normal pointers, or find another gui. In both cases you will have to redesign your framework.
Don't understand me wrong, I am still open for suggestions on how to improve my gui, but I just don't see a way how I can fix this problem on my side.
-
I'm not using the latest version right now, so I'll post what happens when I am. I'll find a way around it.
-
There seems to be a nasty crash in the 0.5 version of TGUI with editboxes. I use SFML 2.0 RC.
It happens when you write something in an editbox and then highlight the first character in it, the same happens when you do a double left click in the editbox becouse that too would hightlight the first character. The same functions work on textboxes perfectly without crashes.
The crash happens at the drawGUI() function
Microsoft Visual Studio C Runtime Library has detected a fatal error in insertnamehere.exe.
The culprit maybe the variable called m_SelChars. By editing the source code in EditBox.cpp
void EditBox::leftMousePressed(float x, float y) by setting m_SelChars to 0 instead of m_Text.getSize()
the crash seems to be gone, but it ruins the highlighting.
-
It is fixed now.
Thanks.
-
Hi texus,
I have been thinking about trying tgui for a while now, but a single design decision has kept me from doing so:
The replacement of sf::RenderWindow with tgui::Window.
What is the rationale behind this? It seems rather intrusive to me. I would much rather see this than what you have now:#include <SFML/Graphics.hpp>
#include <TGUI/TGUI.hpp>
int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "TGUI window");
tgui::GUI gui(window);
while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
gui.handleEvent(event);
}
window.clear();
gui.draw();
window.display();
}
return EXIT_SUCCESS;
}
It is literally 2 extra lines than the current solution, providing clear separation between TGUI and SFML, and extra documentation.
Besides, what if someone was to make, say, a particle engine that also replaced sf::RenderWindow? Then we wouldn't be able to use it together with TGUI. It is just bad practice in my (not so) humble opinion. :P
-
Someone else has already said this before and I have already implemented it.
If you are using v0.5 then you can just change GUI with Form and your code should work.
It looked easier to my to do everything with the same window that is why the Form wasn't in the tutorials.
-
Yeah, I thought someone else might have had the same opinion, and I admit I didn't bother to read through all 9 pages in this thread.
Anyway, it's a good thing you at least gave the option to not use the tgui::Window class, and I guess I will download TGUI and give it a whirl, then.
I have also bee trying out SFGUI after dropping my own GUI project, and I am glad that there now are several options for GUI systems. Keep it up, texus!
-
I've started playing around with TGUI, and have a suggestion:
Why don't you change the private widget members and methods to protected? That way people could expand and modify existing widgets instead of always having to write new ones from scratch.
Example:
I need a history window to display and interact with undo actions, and the Listbox is almost perfect for that. All I need to do is remove the ability to deselect an entry, so one will always be selected, and change the text color of the entries below the selected entry. If the private members were protected, I could simply inherit the Listbox, add the members I needed, and overwrite the appropriate methods.
-
As this isn't really a high priority, it will have to wait until I have my Grid and Tab objects finished.
For now you can just copy the whole listbox to an new file and edit it. So you don't really have to start writing it from scratch.
-
For now you can just copy the whole listbox to an new file and edit it. So you don't really have to start writing it from scratch.
That is exactly what I am trying to do now, but I am running into some trouble.
It seems that Listbox is a friend of Scrollbar, because there is a lot of accessing private members going on. I would suggest that you don't make widgets friends of each other for 2 reasons:
- You will learn of any shortcomings of the public API first hand. This will help you greatly in the design process.
- It will serve as good practical documentation for anyone trying to design their own widgets.
The problems I am having right now is how to do this:
if ((m_Scroll->m_MouseDown) && (m_Scroll->m_MouseDownOnThumb))
This:
m_Scroll->m_MouseHover = false;
And this:
m_Scroll->m_MouseDown = false;
There also seems to be a "using namespace sf" in one of the included files, or maybe a typedef, because I had to add "sf::" in front of every "Vector2f". This is more a question of personal taste I suppose, but I don't think saving a couple of keystrokes is worth losing the extra documentation.
-
Sorry, I completely forgot that it depended so heavily on the scrollbar.
I know I made some pretty bad design decisions in the past, but this is because I never expected to get this far.
I never planned custom objects so a lot of thing had/have to change.
I will make all methods virtual and all private members protected asap.
If this change is not done in the next hour then it means you will have to wait until tomorrow.
-
That is awfully kind of you - thanks!
Don't get me wrong, texus, I am not questioning your abilities or trying to be mean. I know first hand how hard it is to write a GUI library. I rewrote mine from scratch 4 times before finally dropping it - or at least putting it on hold, we'll see.
The tiniest, seemingly insignificant decision can have enormous consequences as the project grows, and I think I finally understand why Laurent sometimes spend months thinking about design before doing anything - even if a solution seems obvious to some.
One thing is for sure: TGUI will make you become a much better coder. If I ever decide to reboot my own project, I will be most fortunate if you take the time to criticize some of my decisions.
/EDIT
About your recent change to Form's constructor
m_Window = &window;
Won't this simply copy the RenderWindow? Shouldn't you be using the initialization list and make m_window a reference?
-
Its done.
I am not really a planner, I usually just start coding and I'll see where it ends. This will hopefully change as I get more experienced.
But the best way to become a better coder is by getting critics. If I wouldn't have put tgui online then I would still be coding like in v0.3, which was a version not really worthy to be released.
But looking at sfml code also helped me a lot.
EDIT:
It will make a pointer to the window, so it isn't copied.
It should be exactly as before, only I will get the pointer inside the constructor instead of letting you pass the pointer to the constructor.
-
I am not really a planner, I usually just start coding and I'll see where it ends.
When Notch was developing Minecraft, the only documents he kept we a list of bugs, and a list of features he wanted to implement, but thought he might forget about. I believe it is called "iterative design" and is all the rage.
Anyway, that is also how I do things, except I start keeping documents as things get complicated. My brain just can't hold that much info at once, I guess. I also use a whiteboard, which I can really recommend!
EDIT:
It will make a pointer to the window, so it isn't copied.
It should be exactly as before, only I will get the pointer inside the constructor instead of letting you pass the pointer to the constructor.
How did I miss that '&'? I must have special powers! ;)
-
As I am looking through the code, I noticed certain things, and have these suggestions:
All the methods that doesn't change any members should be made constant. Examples of this are the getSomeColor methods.
You should generally also make arguments const, unless you have a good reason for not doing so.
Why use this ID system for items? I would simply use their index directly and return an int instead of unsigned int in the getters. '-1' could then be used to indicate failure, which is quite common.
If you want to go the ID route you should implement a true unique ID system, completely decoupled from item index.
Instead of doing this:
/// The string will be empty when the id was too high or when it was 0.
sf::String getItem(unsigned int id);
You could also take a string reference, fill it, and return a bool to indicate success, like so:
bool getItem(const unsigned int id, sf::String &returnValue);
This is a common strategy when you want to return more than one piece of information.
In the constructor of Listbox you have:
m_ObjectType = listbox;
What is the purpose of this? It is never used in the class.
I hope you can use my critique. :)
-
If you dig deeper into my code I am sure you will find more of these things, but I appreciate the critiques.
The constants are something that I could easily improve.
Changing the ids is a bigger change, but still something I will probably do.
The change in getItem (and other similar functions) might not be made soon.
I believe I made enough api breaking changes in v0.5. It will probably be changed the next time I rewite a big part of my gui.
The m_ObjectType has lost its purpose after the introduction of custom objects. I still keep it in there for 2 reasons: to find out if the object is a radio button (I don't want to add a bool just for that) and for safety on callbacks. It might be a bad habit to do so, but if you want to cast the callback object to a listbox then you might want to make sure that the pointer really points to a listbox and that you didn't accidentally passed the same callback id to e.g. a button.
-
I am sorry if this question has been asked before, but what features does this library have that make it different from sfgui? Which library should I use?
-
Hi texus,
I found a bug that would sometimes make item text in a Listbox appear blurry.
I fixed it by changing 2 lines in the draw method:
states.transform.translate(2, (static_cast<float>(static_cast<int>((i * m_ItemHeight) - m_Scroll->getValue()) + ((m_ItemHeight / 2.0f) - (bounds.height / 2.0f) - bounds.top))));
to
states.transform.translate(2.f, static_cast<float>(i * m_ItemHeight) - static_cast<float>(m_Scroll->getValue()));
and
states.transform.translate(2, (i * m_ItemHeight) + ((m_ItemHeight / 2.0f) - (bounds.height / 2.0f) - bounds.top));
to
states.transform.translate(2.f, static_cast<float>(i * m_ItemHeight));
TheVirtualDragon, I am in the process of evaluating both libraries, and here are my thoughts so far:
SFGUI is a really well thought out library, designed by a team of experienced coders. Unfortunately, it is no where near complete, and has many bugs. Its design makes the learning curve a little steep, certainly for newbie coders, and especially concerning its system for automatic widget positioning. If you want to fundamentally change the look of the widgets, you will also have to write your own rendering engine.
TGUI is designed by a single coder, and from looking at the code, it is clear that he wasn't very experienced when he started. The design is, shall we say, minimal. However, from what I have gathered, texus' skills, and thus the quality of his code, is quickly improving. In contrast to SFGUI, TGUI's widgets are purely drawn with sprites, and that makes changing their looks very accessible.
Please keep in mind that I have only been looking at how to style widgets, design a new one, and display them on screen. I haven't even looked at handling state changes, button clicks, etc. in TGUI.
One thing the libraries have in common is that their developers are doing a great job at supporting their users. Messages are answered quickly, and bugs are fixed promptly.
So in conclusion, which one to use depends entirely on you, what you want to do, and your level of expertise. But why not try both? They are completely free you know, and not just for evaluation purposes!
-
I cannot tell you which is better because I have never used sfgui.
I would say it depends a little bit on your personal preference and the only persons who can really give you a good answer to your question are those who have used both tgui and sfgui.
For the bug, it is something that I have seen before, but I ignored it.
The text is drawn at a float position and the scaling done to it doesn't do any good to it either.
So in most objects the text will sometimes appear blurry, depending of the text.
I haven't been able to solve it as it seemed to completely depend on the text. But I must admit that I never really tried very hard to solve it. If your solution works then I will add it to the code and I will look at the other objects as well, but this problem will have to changed object by object.
-
The text is drawn at a float position and the scaling done to it doesn't do any good to it either.
So in most objects the text will sometimes appear blurry, depending of the text.
Since the values the item's positions are based on are all integers, the positions you will end up with wil all be "something point zero". If it were a problem, you could always do this:std::floorf( floatValue + .5f )
Anyway, your mention of scaling made me try setScale, and the text at least now renders equally blurry on all the list items, unlike before.
But then I stumbled on another couple of bugs:
If you scale a Listbox, the hit boxes on the items no longer fit the graphics.
Also, if you scale down, long strings will display outside the Listbox.
What scaling were you talking about? The text in an unscaled Listbox appears nice and sharp for me with the patch.
-
I wasn't just talking about listboxes, but about all objects. Buttons for instance can auto-scale the text to fit into the button, but this will make it a lot more blurry then with a fixed size. But these are all things that I wrote some time ago and I should review them and see what I can change.
The text in the listbox looks sharp to me even without the patch.
I think it is all about the combination of font, text size and the text string.
So I will have to do some more tests before I implement the patch.
There is one simple rule in tgui right now: never call setScale, always use setSize.
I used to support setScale, but after many changes some of the objects didn't work properly anymore and I haven't had the time to fix it. I am not planning to supporting setScale, just to break the support the next day when I make a change to the object.
I think listbox is the only object were I literally decided to write code that didn't check the scaling of the object and thus won't draw correctly with setScale. ListBox and ComboBox should never be scaled if you want to keep everything working.
This is all going to be fixed before v1.0, but you can (and you should) use setSize, so I don't really see it as a big issue.
-
Yeah, I was actually about to suggest that you simply removed setScale, as I didn't seem very useful to me. But then I thought you might have some reason not to, and decided not to mention it.
But I will make this suggestion, then: Just remove the auto scaling of text from the system entirely. I seems like a wasps nest to me, and something better left to the end user. Most good graphical designs use at most a couple of different font sizes anyway.
I also noticed the naming inconsistency in Listbox and EditBox. How about changing to ListBox?
Also, is it possible to change text alignment in the EditBox? I would really like that feature...
-
I can't remove setScale unless I would create my own Transformable class. And the effects of setScale and setSize won't always be the same so it might still be handy in some situations. Try scaling a panel or a child window, you will see the difference.
Scaling texts is used in multiple places so removing it would not be something I would do right away.
When I created the listbox I noticed that it was spelled differently at different places. I couldn't find out if it was listbox or list box, and eventually I chose for listbox. It could be changed, but I won't do that just based on one opinion.
Why would you need alignment in edit box?
If you have a good reason (which you probably have, otherwise you wouldn't be asking) then I will try to implement it. EditBox should be completely rewritten anyway. The clipping method isn't as good as the one from the later objects.
-
I found another bug. (sorry)
This code:
tgui::EditBox *myEditBox = gui.add<tgui::EditBox>( "myEditBox" );
myEditBox->load( "TGUI/objects/EditBox/Black" );
myEditBox->setSize( 400.f, 18.f );
std::cout << "Width: " << myEditBox->getSize().x << " Height: " << myEditBox->getSize().y << std::endl;
Outputs
Width: 120 Height: 40
I can't remove setScale unless I would create my own Transformable class. And the effects of setScale and setSize won't always be the same so it might still be handy in some situations. Try scaling a panel or a child window, you will see the difference.
I am not suggesting that you don't use some class internally, only that you don't expose methods in the public API that doesn't make sense, or as in this case, specifically should not be used.
When I created the listbox I noticed that it was spelled differently at different places. I couldn't find out if it was listbox or list box, and eventually I chose for listbox. It could be changed, but I won't do that just based on one opinion.
Well, the free dictionary doesn't list listbox as an English word: http://www.tfd.com/Listbox (http://www.tfd.com/Listbox)
The built-in spell check in Firefox agrees.
Why would you need alignment in edit box?
If you have a good reason (which you probably have, otherwise you wouldn't be asking) then I will try to implement it. EditBox should be completely rewritten anyway. The clipping method isn't as good as the one from the later objects.
Currently I need center-aligned text to fit in a graphical design that needs it. It does so because, compared to the window size, the widgets are few and spread out. Centered at the top of the screen is an EditBox that ties the whole design together. If the text is aligned left or right, the whole design will 'tilt' to one side.
Right alignment is useful for presenting numbers vertically. Just think of a spread sheet. In this case, right alignment will make it much easier to compare the size of the numbers.
-
I found another bug.
It isn't a bug, but it is something I am planning to change.
You should use getScaledSize, because getSize returns the size of the original image (which has a height of 40).
I am planning to remove getSize in the future and rename getScaledSize to getSize, but until that moment you will just have to type a few more characters every time you want to know the size of an object.
only that you don't expose methods in the public API
As far as I know, there is no way to simply hide the function as it is public in sfml.
I keep the setScale function working for as much objects as possible though. Simple objects like pictures, labels, buttons and edit boxes can perfectly use it.
I was just using the scaling in a wrong way in ListBox and calculations became too dificult and confusing. I have learned my lesson and when I reimplement scaling in ListBox, it will work better than before.
the free dictionary doesn't list listbox as an English word
Thats of course more convincing. I'll see if I can change it tomorrow.
I don't know why I picked Listbox. If I just look at google now I almost always see ListBox.
Right alignment is useful for presenting numbers vertically.
Right alignment for numbers makes sense. And adding center alignment would be a small extra.
I can't put a date on this though. Maybe tomorrow, maybe next week. I'll see about it.
-
As far as I know, there is no way to simply hide the function as it is public in sfml.
You could overwrite it with a private or protected one. It is a bit of a hack, though.
If a class inherits one or more methods that doesn't make sense, then it shouldn't have an is a relation ship with that other class.
If that is something that pops up in your code, it is an indicator that you should probably start thinking about your inheritance scheme.
-
There is nothing wrong with my inheritence scheme (at least not if it comes to sf::Transformable).
But you did make me realize that I should do something. I can't be left like this.
If I can't fix it before tomorrow evening then I will indeed have to override the functions as private until the scaling problems are solved.
-
I have started playing with the "callback" system, and have some notes:
First of all, when I think of a callback system, I think of a system where you can register a callback function. I would describe what TGUI has as a type of event system. This is a little confusing, and I would personally rename it.
I am also having trouble seeing how I could separate out which events were handled by TGUI, and which ones I should let my own code handle. Example:
Let's say I have a system that responds to mouse down events. I also have a TGUI button. How can I tell if a mouse down event happened on the button or not? If it did, I don't want to also handle it in my own code.
The tgui:Button only seems to respond to click events, and I would need at least an isMouseOnWidget method, or a mouse down event.
-
Thanks for the info, I think I will use TGUI as I am making a quick map editor which doesn't really need many widgets.
-
I'll think about the renaming.
Before the first public release, there was a real callback system but it wasn't good enough so I made this event system.
It is something that I have been thinking of rewriting again, so if you have ideas on how to improve it then please let me know.
I am afraid that there is no mouse down event. You will only receive click events.
I don't want to overload the program with callback events that aren't needed in most situations.
You could always call mouseOnObject to see if the mouse is on top of the button at the time the mouse went down. But you would have to do that for all objects so that isn't really a solutions.
But why would you need to know when the mouse went down on a button? Why can't u just wait to do something until the user really clicked on the button?
I am making a quick map editor which doesn't really need many widgets
It depends on what kind of map editor and how you are going to do it.
You could create a map editor with just tgui. If you have a tilemap then you could use SpriteSheet objects, you can draw all images with Picture and all texts with Label, ...
It has the big advantage that your drawing loop exists of only the drawGUI call at any time. You no longer have to to use bools to decide when to draw what as everything is made visible or invisible before and with just one draw call u can draw everything.
The amount of widgets u use depends completely on how you are going to write it, not on the kind of program.
-
OK, so I have just gone through the TGUI documentation and I don't know if there is anyway to do the following.
Basically, there is an image. I do not want all of the image to be displayed at the same time, but instead allow the user to scroll through the image using scroll bars. Is this possible in TGUI? If not, then is there anyway to do this, like using views?
EDIT: I think I need to use a sprite sheet and merge it with a scroll bar...
Double Edit: I think I have figured it out! TGUI is sooo easy to use...:D
-
If you don't want an object to be displayed then just call the hide function.
U will need to use a view if you want to shift around the objects. You could put scrollbars to change the view of course.
I have been able to create a small test game where the character walks around in 2.5d perspective and I used a SpriteSheet objects for every tile. The view was following the character, so I know that it is perfectly possible to display a whole map with tgui. Some might argue that it is faster with sf::VertexArray, but but the 600 fps I was getting were more than enough imo.
EDIT: No, what you are trying to do isn't possible with tgui I think. You can't display a random part inside an image. You can only divide it into rows and columns with a SpriteSheet, but you can't just display the part that starts from e.g. left pixel 3 to right pixel 20.
If that is what you want then you indeed can't use my gui for that part.
-
What I have done is divided the SpriteSheet in to columns, then used a scrollbar to shift through the objects. Basically, here is my code (which I just put together very quickly):
#include <iostream>
#include <TGUI/TGUI.hpp>
using namespace std;
int main()
{
tgui::Window window(sf::VideoMode(800, 600, 32), "Mapped Out");
window.globalFont.loadFromFile("data/DejaVuSans.ttf");
tgui::SpriteSheet *tileSheet = window.add<tgui::SpriteSheet>();
tileSheet->load("data/TileSet.png");
tileSheet->setPosition(0, 0);
tileSheet->setCells(1, 2);
tgui::Scrollbar* scroll = window.add<tgui::Scrollbar>();
scroll->load("objects/Scrollbar/BabyBlue");
scroll->setLowValue(1);
scroll->setMaximum(2);
scroll->verticalScroll = false;
scroll->setPosition(0, 50);
scroll->callbackID = 1;
while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
window.handleEvent(event);
}
tgui::Callback callback;
while (window.getCallback(callback))
{
if(callback.callbackID == 1)
{
if(callback.trigger == tgui::Callback::valueChanged)
{
int scrollValue = scroll->getValue();
tileSheet->setVisibleCell(1, scrollValue + 1);
}
}
}
window.clear(sf::Color(100, 175, 255));
window.drawGUI();
window.display();
}
return 0;
}
My current tile sheet only has 2 tiles in it, but later on - when it gets bigger - I can divide in to 3 or more and go through them (so it will be like a "slide" on a Powerpoint presentation).
I will also have a look at using views, I think that might give me a smoother animation of scrolling.
-
I will also have a look at using views, I think that might give me a smoother animation of scrolling.
It won't. At least not with my SpriteSheet. If you want smooth animation then you will have to just draw the whole Picture, but with a view to limit the part that is drawn.
I could write a small example code if you like.
But in this case you might be better of with just using sf::Sprite and setting a texture rectangle instead of using Picture or SpriteSheet.
-
Yeah, that is exactly what I was thinking. I am implementing it just now...
-
It is something that I have been thinking of rewriting again, so if you have ideas on how to improve it then please let me know.
I will try to keep this in mind as I poke around.
But why would you need to know when the mouse went down on a button? Why can't u just wait to do something until the user really clicked on the button?
That works OK where the button is concerned. What I am concerned about is my own code, separate from TGUI. How should I distinguish if a mouse down event happened on the button or not?
In the first case, I don't want my code to to respond to it, and in the latter I do.
-
I have added a mouseDown event to the button, so you will also get a callback when the mouse goes down.
If this isn't what you need then you will have to be a little bit more specific about what you are trying to do.
-
That would work for the button, but not for other widgets. It also works only for button down events, and possibly only with the left mouse button.
What I am looking for is a more general way of determining whether some mouse event happened on a widget or not.
One solution could be an isMouseOverWidget method on all widgets. Such a method should of course also check all sub-widgets contained by a widget, such as a scroll bar.
The same applies to keyboard events, but those are really only handled by EditBox I believe, and in this case you can simply check if an EditBox has focus.
I hope that clarifies my question. :)
-
I can even give you 3 solutions.
1)
if (event.type == sf::Event::MouseButtonPressed)
{
if (button->mouseOnObject(event.mouseButton.x, event.mouseButton.y) == false)
{
// The click did not occur on the button
}
}
Like this you can find out when you clicked on the button or not.
The only problem is that you will have to manually check every object.
2)
You want to find out if the mouse went down next to my widgets, so on something else.
You could make that 'something else' a custom tgui widget so that it can make use of the EventManager in tgui?
3)
Another solution to your problem could be to put a Picture behind all tgui objects (the Empty.png image from my Form Builder).
Then you ask me to implement a mouseDown event for Picture as well.
And when the Picture gives you a mouseDown callback you will know that the mouse didn't went down on any other tgui object.
TextBox also has keyboard events.
-
Option 1 definitely seems like the preferred method with TGUI. Thanks!
-
So...Are you planning on releasing any themes? I am working on a OSX theme right now...
-
You can already use the Black style and for most objects also BabyBlue.
I am not planning to make any more styles/themes, but if you create one then feel free to share it with the rest.
Currently you will have to point every object to its own images.
Loading a complete theme at once is planned, but not something that you should expect soon.
-
tgui::Form::handleEvent currently has a reference to an sf::Event as its parameter. This usually means that the user should expect the passed in variable to be altered in some way.
I suspect this isn't the case, and suggest that you change it to a const reference.
-
You already suggested to make all unchanged parameters constant, which is something I will do in the near future.
This parameter will also be changed then.
I am currently working on getting setScale to work correctly with all objects, which has a higher priority to me than placing a few constants in the code.
-
Did I? I thought I had only mentioned making methods that don't change members constant. Sorry about that.
-
Texus can you make Panel's draw function public? It's just I'd like to be able to use Panels to layer the order in which i draw things, so I can draw things outside of TGUI in-between the drawing of the GUI. I'd rather not have to make a new object just so I can draw things in the correct order.
Sorry if I'm being an idiot and missed something to let me do this already.
Turns out I'm an idiot who should have tested window.draw(PanelName); before posting this.
Also can I request a feature for the form builder? The feature being the ability to use percentage based values for size and position. I'd like to use form builder generated/self made text files for all my interfaces but I simply can't while allowing my program to have different resolutions set for it.
-
I don't really understand what you are trying to do with the Panel, but the draw function doesn't has to be public.
To draw an object you can just do this:
window.draw(myPanel);
But if you don't let the gui handle the objects and you draw them manually then you will soon find some limitations.
I can't add the feature to the form builder right now. It is not something that can be added very easily and I will have to rewrite the whole form builder in the future anyway. But when I do rewrite it, I will see if I can implement something like this. However chances are big that you can already do this directly in tgui itself by that time.
But maybe I could make a small workaround for now.
Would it be enough for you to be able to define the window size at the top of the object file and for the position and size just put a calculation instead of a number? You will of course have to write the object files yourself, but you could let the form builder generate one so that you only have to change the position and sizes.
Like this, you will only have to change the window size in the file and all objects will be repositioned.
-
Yeah sorry about asking a stupid question when the answer was already there.
What limitations will I run into?
That workaround would work fine :)
-
If you call drawGUI then all objects will be drawn, even the object that you are drawing manually earlier or later. This might no be what you want. You can always try to not add the object to the window at all and then draw it, but then the objects won't receive any events.
I just don't see why you are drawing an object yourself. Unless you are drawing all the objects manually.
I'll see if I can make that workaround.
I just have to allow calculations as it is already possible to define numbers.
Edit: Don't expect this today. I am resizing my partition and it is going to take more than two hours before I can access it again.
-
Oh It's not I'm trying to stop an object from being drawn, as I could easily hide and disable it. What i'm trying to do is draw Spritesheets as one layer in a Panel, then draw Particles from Thor, then draw the interface Panel ontop of it all.
So i'd be doing this
draw()
{
window.draw(*worldpanel);
window.draw(particles);
window.draw(*interfacepanel);
}
I'm not worried too much about having it today, I can make due with doing the interface in code as I have it atm till you're done. :)
-
Hi texus,
I seem to have run into a problem with the text scaling now.. Is there currently any way to re-size an EditBox in TGUI without scaling the text? I wanted to make a small EditBox, but the text became so blurry that it was hardly readable.
-
You could try to set the text size yourself with setTextSize.
-
I did try that, but the text didn't event display. I guessed it was because the scaling was still applied, and now the text was simply much smaller to begin with.
-
I was afraid of that.
This will be another thing to fix when rewriting EditBox.
But I was already planning to see if I could fix the blurry text during the rewrite, so with a little bit of luck you won't even have to set the text size yourself.
This might take a few days to get fixed.
-
Sounds good, texus.
Now I have another problem, though. Well, actually 2, also with EditBox:
First of all, it would be nice with a "lost focus" event. I can simulate that by checking if an sf::Event::MouseButtonPressed happened outside a focussed EditBox, before passing the event to TGUI.
It would be more practical if it could happen automatically, though.
Second, I would like to unfocus an EditBox when the return key is pressed, but I can't figure out how to do so. I tried objectUnfocused(), but that seems to do nothing.
-
The problem with the events is that I don't want to slow the program down by sending too many events. There are so many events that are missing and that might be useful in certain situations, but I can't send all of them. So right now, only the most important events are send and this will stay until I find a good method to choose the needed events.
The objectUnfocused funtion is called automatically when the object gets unfocused but it doesn't unfocus the object itself.
I though I had added focus and unfocus functions to the objects, but apparently I didn't. So you will have to ask the parent object to unfocus the object for now.
window.unfocus(myEditbox);
-
It is now possible to make calculations in the position and size of the objects inside the object files.
You will have to use left/top/width/height instead of position/size to make use of it.
You should also note that a calculation has to be inside quotes, while a fixed number should be written without quotes.
Here is an example to create a picture that is centered and has a size of a third of the window.
// Set the size of the window
// You are currently limited to lowercase characters in the define
define: window_width = 800
define: window_height = 600
Window:
{
Picture: "myPicture"
{
// Load the image
Filename = "ThinkLinux.jpg"
// The image size will be a third of the window
Width = "window_width / 3"
Height = "window_height / 3"
// Position the image in the center of the window
Left = "(window_width - (window_width / 3)) / 2"
Top = "(window_height - (window_height / 3)) / 2"
}
}
-
... you will have to ask the parent object to unfocus the object for now.
window.unfocus(myEditbox);
I tried that, but I can't make it work. Here is a minimal example of what I am trying to do:
#include <SFML/Graphics.hpp>
#include <TGUI/TGUI.hpp>
int main()
{
sf::RenderWindow window( sf::VideoMode( 1024, 768 ), "TGUI" );
sf::Font myFont;
myFont.loadFromFile( "resource/TGUI/DejaVuSans.ttf" );
tgui::Form gui( window );
gui.globalFont = myFont;
tgui::EditBox *myEditBox = gui.add<tgui::EditBox>( "" );
myEditBox->load( "resource/TGUI/objects/EditBox/Black" );
myEditBox->callbackID = 1;
while( window.isOpen() )
{
sf::Event event;
while( window.pollEvent( event ) )
{
if( event.type == sf::Event::Closed )
window.close();
else if( event.type == sf::Event::KeyPressed &&
event.key.code == sf::Keyboard::Return )
gui.unfocus( myEditBox );
gui.handleEvent( event );
}
tgui::Callback callback;
while( gui.getCallback( callback ) )
{
std::cout << "There was a callback event" << std::endl;
}
window.clear();
gui.draw();
window.display();
}
return EXIT_SUCCESS;
}
-
I am an idiot. I was telling the event manager to focus the object instead of unfocusing it.
It is fixed now and I have also added focus and unfocus functions to all objects.
-
Don't be so hard on yourself.
I once spent an hour debugging a condition in an if statement that would seemingly always evaluate to 'true'. I tried everything I could think of, but the code in the pointy brackets would always execute, no matter what I did.
Then I noticed the semicolon after the close parenthesis.
Programming is a humbling experience. :)
-
I'm getting "tgui::LoadingBar has no member 'setText' " with the newest version. Not sure if it's my fault but I thought I built it correctly.
EDIT: No mention of "setText" in LoadingBar.cpp. Maybe I should redownload the source.
EDIT #2: Fixed now.
EDIT #3: Unresolved external symbols - OBJECT::textEntered(char) and Label::draw
Ah. Nothing I am doing is changing this last problem - I rebuilt it, debug/release are matching with the CMake options, and I'm getting unresolved symbols as described above. Is this a bug or am I still doing something wrong? (would appreciate a quick answer as I'm using this as part of Ludum Dare, 48 hour game making competition, and I only have 9 hours left).
Tried the latest gitHub TGUI and I get build errors. Going to go back a version...
-
I have no idea what is going wrong, but OBJECT doesn't has a method textEntered.
Are u linking statically or dynamically?
I guess you are using Visual Studio?
On what OS?
I will try building with the same configuration (if possible) and see if I get the same problem.
Edit: What build errors?
-
The latest version on here: https://github.com/texus/TGUI (when I pressed 'download this repository as a zip file') produced a few build errors but I can't remember them - I have now reverted to an older version. There was something about return type being invalid. I think I remember something about a font not being able to be returned as a const when it was a pointer... or something :)
I'm linking dynamically on Windows 7, Visual Studio 2010 express.
-
I hope you selected the v0.5-dev branch and didn't download the master as this is v0.4.
Of course if you are using the RC version of sfml then you will need v0.4.
Edit: Just build sfml and tgui from the latest sources and I don't have any problem. The only difference is that I used vs2008 but that shouldn't matter.
-
It was the 0.5 dev version. Following the link from the website gave me the linker errors and the latest github page gave me build errors. I tried redownloading/building it 3 times and I still got the same errors. =/
-
Following the link from the website gave me the linker errors and the latest github page gave me build errors.
The one on my site is just a link to the one on GitHub. Are u sure that you aren't downloading the master branch?
You do have the latest sfml version, right?
Anyway, this has to be solved and it seems to be something on your side because I don't have this problem.
Could you send me the libraries and dlls that you have build and a small test code to reproduce it?
-
Hello? I make my own level manager by our library "TGUI". So i make objects in this way:
void CreateEditBox(tgui::Window &window, tgui::EditBox *editbox, int x, int y, string value, int w=225, int h=20)
{
editbox = window.addEditBox();
editbox->load("objects/EditBox/Black");
editbox->setBorders(4, 2, 2, 4);
editbox->setPosition(x, y);
editbox->setText(value);
editbox->setSize(w, h);
}
so in loop of tgui's events i want to get Text of edit box. How i can do it? if i use function EditBox->getText()? i get error "segmentation fault".
-
Following the link from the website gave me the linker errors and the latest github page gave me build errors.
The one on my site is just a link to the one on GitHub. Are u sure that you aren't downloading the master branch?
You do have the latest sfml version, right?
Anyway, this has to be solved and it seems to be something on your side because I don't have this problem.
Could you send me the libraries and dlls that you have build and a small test code to reproduce it?
I'll try again later. Right now I have a game to make ^^
-
I tried the fix, and it works some of the time.
I have 3 EditBoxes.
1 of them is added directly to the Form, and that works as it should.
The other 2 are both added to the same Panel, and when I call unfocus() on one of them, while it is focussed, the other one gets focussed.
I have tried calling unfocus() on the panel, but that gives an error that the call is ambiguous.
Also, Building worked fine, but I did get an error when building the INSTALL target in release mode. I am having no problems after copying the appropriate files, though.
Building in Debug mode gave no error.
-
Your CreateEditBox should be defined like this. (note the & after EditBox*)
void CreateEditBox(tgui::Window &window, tgui::EditBox*& editbox, int x, int y, string value, int w=225, int h=20)
If you don't do this then your pointer outside this function will not point to the created object.
-
thank you? it work. Did i can use you lib v 0.5 in SFML v 2.0 RC?
-
The behaviour with the edit boxes is as expected. Unfocusing is similar to using the tab key.
I didn't know you were trying to unfocus all of the objects. But I have just added an unfocusAllObjects function, so you can now just use window.unfocusAllObjects().
I was a little bit too fast with adding focus and unfocus to all objects as it indeed makes the calls ambigious in Panel.
I have renamed the ones from Group (and thus the one in Panel and Window) to focusObject and unfocusObject.
The install target is something I haven't got working either in visual studio. So until I take the time to figure out how to get it working, you will just have to copy the form builder executable to the right place yourself.
Did i can use you lib v 0.5 in SFML v 2.0 RC?
No you will have to compile the latest sfml version to use tgui v0.5.
-
The behaviour with the edit boxes is as expected. Unfocusing is similar to using the tab key.
I didn't know you were trying to unfocus all of the objects. But I have just added an unfocusAllObjects function, so you can now just use window.unfocusAllObjects().
How about changing the name of unfocus() to focusNext(), then? It is always good to avoid side effects.
Also, is it possible to disable the tab key functionality entirely?
-
I'll change the name to focusNextObject tomorrow.
To disable the tab usage, just do this:
tgui::tabKeyUsageEnabled = false;
-
To disable the tab usage, just do this:
tgui::tabKeyUsageEnabled = false;
That gives me a linker error:
error LNK2001: unresolved external symbol "bool tgui::tabKeyUsageEnabled" (?tabKeyUsageEnabled@tgui@@3_NA)
-
That gives me a linker error
It is fixed now.
I had always been wondering what dllimport was good for, now I finally know it.
-
EditBox is now rewritten.
- The clipping has been improved.
- Scaling has been fixed.
- You can now change the layout of the text.
- Cleaned up some parts (more than 30% of the file was removed).
All changes were internal, so you can still use the EditBox the same way as before.
I just hope that I didn't introduced new bugs during the rewrite.
The text can be centered like below. If you want the text to be on the right side of the edit box then just change Center to Right.
editBox->textLayout = tgui::EditBox::Layout::Center
-
Wow, that's cool, texus!
Unfortunately, there are some new problems with the EditBox:
On small (50x20) Left-aligned EditBoxes, the top and left of the first character is clipped. On right-aligned, it's the top and right of the last character.
Center-aligned text is not centered. In my case, with a 400x27 EditBox, it is 5 pixels to the right of the center.
I also think you should change "Layout" to "Alignment", since that is the right term.
Also, as I was building the library, I decided to look through all those compiler warnings, and they seem pretty easy to fix. Is that something you plan on doing at some point? All you need to do is to explicitly cast some variables, and not compare integers with booleans.
-
I fixed the clipping problem and I renamed Layout to Alignment.
I tested the center alignment with an edit box of the same size and I don't see any problem at all (perhaps I fixed it together with the clipping problem). But if you still have this problem then I will need to know a little bit more e.g. what text you have inside the edit box.
You should just ignore the warnings in visual studio. I build in visual studio from time to time to fix them but most of the time I work on linux in CodeBlocks and it doesn't tell me where those conversions are wrong.
It has been some time ago that I have build with visual studio, so I will see if I can do it somewhere this week.
-
First I have an embarrassing confession: I may have had a space at the beginning of the string I was testing the center alignment with. I have deleted the library files, so I have no easy way of going back to conform it, but it would explain the 5 pixel misalignment.
Anyway, it seems to work perfectly in this build.
The left and right clipping issue is gone. Unfortunately, the top is still being clipped.
With a 50x20 EditBox, the text size has to be set as low as 12 for the issue to disappear, and there seems to definitely be more room to draw the text.
I also tried the setBorders method, and that is producing some unexpected results. For instance, doing setBorders( 0, 4 ) on the 50x20 EditBox will enlarge the font.
-
You can now go up to 16 pixels. It was another small mistake in the clipping calculation.
I also tried the setBorders method, and that is producing some unexpected results.
Actually, what you see is the expected behaviour.
The borders define in what area the text will be centered.
If you set the bottom border from 4 to 0 (which you are doing when only passing 2 parameters to setBorders) then the text will be placed lower. If you are auto-sizing then the text will also be given more space so it will become bigger.
You should usually stay away from the borders. They are set to make sure that your text will not be drawn on specific parts of the edit box. The Black style defines its borders as (6, 4, 6, 4) which means that on the left and right side there should be 6 free pixels and on top and bottom 4 pixels (when the images are drawn at full size). You are drawing the images at half size, which leaves 2 pixels at bottom and top, hence the maximum text size of 16.
If you do want the to be drawn the text as big as possible then you should change the borders to 0. You might want to keep the left and right border at 6 though to avoid the text from being drawn over the rounded edges of the edit box.
-
Ah, that makes sense, then. Thanks for the explanation.
In the new build the EditBox is much more usable. Nice work.
-
I cannot get buttons to throw any callbacks. I have commented my program back down to effectively nothing, even setting default views and such. But I never get any "mouseover" highlight, and it never enters the callback block. The button otherwise displays correctly. I just rebuilt SMFL2 (latest snapshot) and TGUI (0.5 from "download latest revision" on homepage) again to make sure I was up to date, but that did not change anything.
////////////////// Setup Window //////////////////////
sf::VideoMode mode = sf::VideoMode(1024,768,32);
tgui::Window window(mode, "Terran Command 0.0001 Alpha");
window.globalFont = defaultFont;
tgui::Button* button = window.add<tgui::Button>();
button->load("Gui/Button/Black Square");
button->setText("BUTTON");
button->callbackID = 1;
//////// Main Loop //////////////////
while(window.isOpen())
{
HandleEvents(window);
tgui::Callback callback;
while(window.getCallback(callback))
{
std::cout << "Anybody?" << std::endl;
}
window.clear();
//window.draw(bg0);
window.drawGUI();
//window.setView( sf::View( sf::Vector2f(750, 500), sf::Vector2f(mode.width*4, mode.height*4))); // Set view for drawing game objects
window.setView(window.getDefaultView());
//vertexArray.s = texPage.GetTexPage(); // Select texturePage for vertexArray
//window.draw(vertexArray, vertexArray.s); // Draw vertexArray
window.display();
}
What am I missing?
-
I guess you are not sending events to the button.
You will need to poll the sfml events and pass them to tgui with window.handleEvent(event).
-
Ah, yep. Missed that one in your setup tutorial. Works now, thanks for the speedy reply.
I think the name "handleEvent(event)" kind of blends into the woodwork of the SFML event system that is already there. It isn't very clear that it is related to the GUI working.
Maybe something like
"HookEventsToTGUI" or something similar that makes it clear what its really doing.
-
Something like hookEventsToTGUI or passEventToObjects should indead be more clear.
I'll probably just put another poll on my site and let everyone vote on which name they think is best.
Talking about the poll, those who requested a Tab object won't have to wait much longer as it is almost finished.
-
Minor thing...
setText() seems to lose leading spaces in the string. I am having some trouble with text overlapping on my checkboxes, and I cannot space it out this way.
-
Something like hookEventsToTGUI or passEventToObjects should indead be more clear.
Only for those who choose not to separate the GUI from the window. This is one of the reasons why I think inheriting sf::RenderWindow is a bad idea to begin with. A GUI system is not a RenderWindow, and pretending it is will lead to things like this.
-
setText() seems to lose leading spaces in the string.
If I would allow spaces in front of the text, do you expect the area of the spaces to be clickable or not?
Only for those who choose not to separate the GUI from the window.
I'll leave it like it is now in the Form class.
-
setText() seems to lose leading spaces in the string.
If I would allow spaces in front of the text, do you expect the area of the spaces to be clickable or not?
By all means, do not show leading spaces. But I can't figure out how to make my text not overlap the button.
It's entirely possible I just don't know what I'm doing. In fact, that's very likely.
(http://www.cargoclass.net/CombatWombat/CheckBoxOverlap.png)
-
I never had overlapping text. Could you show me how you initialize the checkbox?
I can only fix it when I can reproduce the problem, so if I have the code against tomorrow then I will see what I can do.
Did you by any chance change the text size? I know that this was never fully tested.
But if you did change it, what happens when you don't change it?
-
Loading font...
sf::Font defaultFont;
defaultFont.loadFromFile("Fonts/DejaVuSans.ttf");
...
tgui::Window window(mode, "Terran Command 0.0001 Alpha");
window.globalFont = defaultFont;
Code for panel checkbox is inside:
tgui::Panel* menuPanel = window.add<tgui::Panel>("menuPanel");
menuPanel->load(500,300, sf::Color(50,50,50,175));
menuPanel->setPosition(0,35);
Code for checkbox...
tgui::Checkbox* checkbox = menuPanel->add<tgui::Checkbox>("Fullscreen");
checkbox->load("Gui/Checkbox/Black");
checkbox->setText("Fullscreen");
checkbox->setSize(25,25);
checkbox->setPosition(15, 15);
checkbox->callbackID = 2;
Drawing code:
window.clear();
window.setView( window.getDefaultView() );
window.draw(bg0);
window.setView(mainView); // Set view for drawing game objects
vertexArray.s = texPage.GetTexPage(); // Select texturePage for vertexArray
window.draw(vertexArray, vertexArray.s); // Draw vertexArray
window.setView( window.getDefaultView() );
window.drawGUI();
window.display();
I don't rescale the text anywhere and am using the default "Black" theme.
-
It is fixed now.
-
The Grid and Tab objects are now finished.
Grid is the first object that allows you to position objects relatively to each other, so you won't have to use exact positions for every object.
As with all objects you can find tutorials (http://tgui.weebly.com/tutorials-v05.html) for the basics and you can take a look at the documentation (http://users.telenet.be/tgui-documentation/v0.5/) to find the more advanced functions.
-
So,
Any specific strategies for using this on a "larger" scale. I only have a few buttons, and already I can see that hard coding each panel and having a giant "switch" block in the callback loop is pretty much unwieldy and error prone.
Should I wrap panel in my own class and load things like position, size, text, etc from XML or similar files?
Do you just make one generic "OK/Cancel" confirmation dialogue box and show() it when needed. If so, how to hook his outputs to different targets?
-
Any specific strategies for using this on a "larger" scale. I only have a few buttons, and already I can see that hard coding each panel and having a giant "switch" block in the callback loop is pretty much unwieldy and error prone.
If you have any suggestions on how to make my gui easier for bigger projects, there always welcome.
If you have a lot of objects then you could reduce the loading to a single line by loading them from my object files which can be generated by the form builder. You will have to add Panels manually as the form builder doesn't support them yet, or you could output a file with the form builder and load its objects into the panel. The object files are loaded like 'window.loadObjectsFromFile("form.txt")' which is a lot shorter than loading every object one by one, but loading will of course be slower.
For the callbacks you will have to put a little bit more structure in your code. In bigger projects you will probably have different game phases of which each handles their own callbacks. So you will get a few callbacks loops of which each checks a few ids instead of having one giant loop that checks for all ids during all phases of the game.
Do you just make one generic "OK/Cancel" confirmation dialogue box and show() it when needed. If so, how to hook his outputs to different targets?
I provide the means to create such a dialog box, but how you do it and what you are going to do with it is completely up to you.
I don't think I can help with how to hook its output.
-
Should I wrap panel in my own class and load things like position, size, text, etc from XML or similar files?
In my project, I have a GUI class that handles anything to do with widgets. The styles are simply hard-coded in the constructor, and positioning is done in another method so I can easily handle window resizing.
That also makes it relatively easy to switch to a different GUI system, if I so desire, because all calls to TGUI are encasulated in that class.
If you have any suggestions on how to make my gui easier for bigger projects, there always welcome.
I still think using function callbacks would be the best solution for widget events. Getters for states like isFocussed is fine.
If I was to revive my own GUI project today, that is what I would aim for.
-
I still think using function callbacks would be the best solution for widget events.
Would it be enough if I would provide a class with a virtual handleEvent function? You would just have to derive your class from it and then the function would be called instantly when a callback occurs. If you do not derive from the class then the callbacks would still be handled like now. At least this is what I had in mind for v0.6.
I am also willing to give every object a seperate callback function, but all callbacks from the objects will still be send to it. I won't allow different callback functions for mouse hover, mouse click, key press, ...
Especially not now I am making plans to add callbacks like mouseEnter, mouseLeave, focused, unfocused, ...
-
Would it be enough if I would provide a class with a virtual handleEvent function? You would just have to derive your class from it and then the function would be called instantly when a callback occurs. If you do not derive from the class then the callbacks would still be handled like now. At least this is what I had in mind for v0.6.
That might be useful, although it wouldn't be a callback. What is enough is entirely up to you - it is your library after all.
I am also willing to give every object a seperate callback function, but all callbacks from the objects will still be send to it. I won't allow different callback functions for mouse hover, mouse click, key press, ...
Especially not now I am making plans to add callbacks like mouseEnter, mouseLeave, focused, unfocused, ...
The down-side to not implementing the filtering on your side will of course be that the user will have to do it on their side.
If you go this route, whatever you do, at least make sure you can register both free functions and members.
Also, I can certainly understand why you won't allow callbacks for mouse hover, since that is more of a persistent state than an event. :P
-
I have just made a lot of internal fixes, mainly problems with scaling objects.
The difference between setSize and setScale should now be very clear in (almost) all objects.
When using setSize, the object will resize itself, whereas setScale will simply stretch the object.
So in e.g. a ListBox, setScale will scale the text and borders while setSize will simply provide more space for the text.
So you should still be using setSize in almost all situations.
I have also made a few fixes of objects with blurry text. If you still find a situation in which an object has blurry text, then just let me know and provide a bit of code to reproduce it.
When updating to this version, you might notice that Slider::verticalScroll is no longer public and can no longer be changed directly. You must now use the setVerticalScroll function. This was done to fix a small bug in the slider.
I made a few bug fixes in Scrollbar as well, but you shouldn't notice them.
The down-side to not implementing the filtering on your side will of course be that the user will have to do it on their side.
I was thinking in letting you choose which callback you receive. All callbacks will still be send to one function, but at least you will only get the relevant callbacks. Like this, you won't have to filter them when you only need a single callback for the object.
It should become something like this:
button->callbacks = tgui::Button::MouseEnter | tgui::Button::MouseLeave | tgui::Button::MouseClick;
So you will be able to simply pick the callbacks you want for all objects.
But of course these are just plans for a future version and a lot can be changed before I even start writing it.
What is enough is entirely up to you - it is your library after all.
Yes, but I am not the person who uses it, at least not right now. So I try to base my decisions mostly on other opinions (and on the few things that I will need in the future myself).
-
hi, congratulation for your work.
How can i set the size for tgui::Slider ?
if i use setSize() method , i have got display bug. i think the bug is at line 871 of slider.cpp.
-
It took my a moment to find the right line because your tgui version seems to be more than two weeks old.
I think that you are changing verticalScroll after you have called setSize.
The bug should have been fixed by now. In the latest version you can no longer access verticalScroll directly and you must call setVerticalScroll.
-
I think that you are changing verticalScroll after you have called setSize.
Yes, work fine now. thanks.
-
I'm having trouble compiling tgui (Git-version) using GCC in Linux with the latest SFML git.
-- The C compiler identification is GNU 4.7.1
-- The CXX compiler identification is GNU 4.7.1
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
Found SFML: /usr/include
-- Configuring done
-- Generating done
-- Build files have been written to: /var/aur/sfml-tgui-git/src/TGUI-build
Scanning dependencies of target tgui
[ 4%] Building CXX object src/TGUI/CMakeFiles/tgui.dir/TGUI.cpp.o
[ 8%] Building CXX object src/TGUI/CMakeFiles/tgui.dir/Objects.cpp.o
[ 12%] Building CXX object src/TGUI/CMakeFiles/tgui.dir/Label.cpp.o
/var/aur/sfml-tgui-git/src/TGUI/src/TGUI/Label.cpp: In member function ‘const sf::Font& tgui::Label::getTextFont()’:
/var/aur/sfml-tgui-git/src/TGUI/src/TGUI/Label.cpp:106:29: error: invalid initialization of reference of type ‘const sf::Font&’ from expression of type ‘const sf::Font*’
make[2]: *** [src/TGUI/CMakeFiles/tgui.dir/Label.cpp.o] Error 1
make[1]: *** [src/TGUI/CMakeFiles/tgui.dir/all] Error 2
make: *** [all] Error 2
-
The master branch is still v0.4 which only works with the RC version of sfml.
You must download the v0.5-dev branch.
-
The master branch is still v0.4 which only works with the RC version of sfml.
You must download the v0.5-dev branch.
Allright. 2 issues with formbuilder:
1. I'm having issues with creating an ArchLinux PKGBUILD for TGUI (basically a package so users can install TGUI without having to compile it themselves etc), Everything seems really messy, when doing 'make install', the lib-file is gently placed where I want it (/usr/lib), but the formbuilder is placed in whatever directory I built it in, + /src/TGUI/FormBuilder. Also it is placed there with just the binary(not fonts and txt-files needed). I suggest you create a data-directory (something like "/opt/tgui/" or "/etc/tgui/" or whatever) to make it more linux friendly. Fonts should be placed in /usr/share/fonts so their cache can be easily updated etc. Is this something planned or am I on my own here? Maybe I should exclude the formbuilder from the package?
2. Placing a button and entering a "!" in the Text-attribute segfaults the application.
(gdb) backtrace
#0 0x00007ffff7b943ad in tgui::EventManager::handleEvent(sf::Event&) () from /usr/lib/libtgui.so
#1 0x00007ffff7bbeff5 in tgui::Window::handleEvent(sf::Event) () from /usr/lib/libtgui.so
#2 0x00000000004111d9 in main ()
this MIGHT be sfml though
-
1. I use ubuntu, so I can't really help you much with ArchLinux.
But if you use 'make install' then the form builder should be copied to the 'Form Builder' directory automatically. This directory does contain all needed resources.
The font is just something I distribute so that you can directly start programming without having to look for a font on your pc to use.
I don't think it is really necessary to install it, unless there would be an advantage in placing it in the /usr/share/fonts folder.
2. I will look into this. I have been able to reproduce this when using the library, however I didn't have it when using the source code directly.
-
1. I use ubuntu, so I can't really help you much with ArchLinux.
But if you use 'make install' then the form builder should be copied to the 'Form Builder' directory automatically. This directory does contain all needed resources.
The font is just something I distribute so that you can directly start programming without having to look for a font on your pc to use.
I don't think it is really necessary to install it, unless there would be an advantage in placing it in the /usr/share/fonts folder.
2. I will look into this. I have been able to reproduce this when using the library, however I didn't have it when using the source code directly.
The advantage of having the font in the /usr/share/fonts and having a data directory is that you can place the executable ( or symlink to it ) in /usr/bin, and creating a streamlined package that just goes with the linux system and philosophy etc. I think you will come to the same conclusion if you try and create a deb-package for ubuntu. My point is you simply dont do the windows-way of multiple-storing files in every folder it is needed when creating a linux-package. /usr/bin, /etc, /usr/share and so forth is the standard in linux.
-
I have fixed the problem with typing a '!' in the edit box, together with some other small bugs that I noticed.
So the font should be in /usr/share/fonts, but where exactly?
The font that I am using can be found in the truetype/ttf-dejavu folder, so should I put it there if it wasn't found there already?
I don't know about other linux distros, is it always installed in that folder?
The form builder will be installed in /etc/tgui and a link to the executable will be created in /usr/bin.
Is that the correct way to do it, or did I still miss something?
If you can answer these questions then I'll make the changes today or tomorrow.
-
I have fixed the problem with typing a '!' in the edit box, together with some other small bugs that I noticed.
So the font should be in /usr/share/fonts, but where exactly?
The font that I am using can be found in the truetype/ttf-dejavu folder, so should I put it there if it wasn't found there already?
I don't know about other linux distros, is it always installed in that folder?
The form builder will be installed in /etc/tgui and a link to the executable will be created in /usr/bin.
Is that the correct way to do it, or did I still miss something?
If you can answer these questions then I'll make the changes today or tomorrow.
Thats great effort!
Well I've been thinking it through, the font-deal really should be up to the distribution to provide, regarding arch: I found a package called ttf-dejavu, ill just make that a dependency and that problem is solved(if the code doesnt load a specific file).
Regarding where to place the binary: Most people nowadays seem to just place the binary in /usr/bin, but since it is a library, you should really just place the binary in /usr/lib/tgui/formbuilder/ or something, and make a symlink from there.
There still is 1 problem to make this optimal: Dataloading. since we now run the program from /usr/bin (does not matter if it is a symlink or not), we need a specific place to load data. This needs 2 things:
1. Create a configuration file in /etc/tgui/formbuilder.conf or something, with a string, lets name it "DataDirectory".
2. Create a folder /usr/share/tgui/data/ or something, where we place all the solid, readonly data(textures, the formdata for the formbuilder etc)
Then, in your program, do something like:
#ifdef LINUX
LoadConfiguration("/etc/tgui/formbuilder.conf");
#elifdef WINDOWS
LoadConfiguration("./formbuilder.conf");
#endif
LoadData(Configuration->DataDirectory);
It feels like im telling against what I've said before, You'll have to excuse me but I hadnt done enough research then to come with solid answers.
-
if the code doesnt load a specific file
The code does load a specific file. I wouldn't know how to do it otherwise.
I don't think the config file is really necessary, I guess I could just skip it and load the data directly from /usr/share/tgui/data/.
Maybe I'll add a conf file later when I allow to change some settings, but right now it would only contain the data directory.
-
I have create a new branch on github: install-test.
You should see if this is better to create the package with.
-
I have started planning the new callback system for v0.6 and I could use some opinions.
Note that v0.6 probably won't be released this year, so you won't see this new callback system soon.
Right now, callbacks are send after changing the callbackID of the object. All callbacks are polled later in the main loop (so no immediate callbacks). This also means that all callbacks come together in one place, where you have to distinct them from each other with the callbackID.
In v0.6 you will be able to intercept callbacks on 3 different levels:
- You can tell a single object to send callback to a specific function (so the callbacks can be spread over multiple functions).
- You can set a global callback function which receives the callback from all objects (unlike with polling, you get callbacks immediately).
- Or you can keep using the current way, by polling them from the window.
Objects will also send callbacks for more reasons. Until now callbacks were limited and were either on or off.
In v0.6 you will be able to choose exactly which callback you want.
If you e.g. want to make a button react on mouse down instead of on mouse click then you can simply do this:
button->callbacks = tgui::Button::LeftMouseDown;
(Right now, a button will send both mouse down and mouse click events, so you must filter it when you receive the callback)
Callbacks can be combined, so if you want to know when your edit box get focused or unfocused then just set both triggers:
editBox->callbacks = tgui::EditBox::Focus | tgui::EditBox::Unfocus;
The following four triggers will be added to all objects: Focus, Unfocus, MouseEnter, MouseLeave. And even more may be added in the future. They couldn't be added before because you would be overwhelmed by callbacks, but when you can choose the needed callbacks, I can easily add them.
Let me know what you think about this new way of handling callbacks.
Any ideas, comments or critics are welcome.
-
I just upgraded from V0.4 to V0.5 (and SFML 1.6 -> 2.0) and after changing the broken methods I've been noticing some segfaults that weren't there before.
A backtrace shows it happening when the window handles events.
#0 0x00000000682e7473 in ?? ()
#1 0x000000000042e2e8 in tgui::EventManager::unfocusAllObjects (this=0x9920a8)
at /home/*****/Desktop/WarBound/src/TGUI/EventManager.cpp:346
#2 0x000000000042d984 in tgui::EventManager::handleEvent (this=0x9920a8,
event=...) at /home/*****/Desktop/WarBound/src/TGUI/EventManager.cpp:122
#3 0x0000000000511980 in tgui::Window::handleEvent (this=0x992020, event=...)
at /home/*****/Desktop/WarBound/src/TGUI/Window.cpp:93
#4 0x000000000051c902 in ClientGame::gameLoop (this=0x7faee0)
at /home/*****/Desktop/WarBound/src/client.cpp:181
#5 0x000000000051fe87 in main (argc=1, argv=0x7fffffffe1f8)
at /home/*****/Desktop/WarBound/src/client.cpp:563
I thought it would be from me handling my callbacks incorrectly but in this section of code there are no callbacks being processed. i.e. my code for the callbacks in that section is:
tgui::Callback callback;
while(window->getCallback(callback))
{
continue;
}
It might also be good to mention that I don't have any active objects attached to the window at the point of the segfault.
Let me know what you think about this new way of handling callbacks.
Any ideas, comments or critics are welcome.
I think that is a wonderful idea. I was just thinking that callbacks should have this functionality.
-
I never had crashes there before.
According to what I see in the backtrace, this happens when you press the mouse button, right?
unfocusAllObjects can't crash if no objects were created. The only thing I can think of is that somehow the m_FocusedObject variable is messed up, but it is changed in many places.
Could you show a minimal example of how to reproduce this crash?
Some other info might also help (OS, compiler, static/dynamic linking).
-
Could you show a minimal example of how to reproduce this crash?
Some other info might also help (OS, compiler, static/dynamic linking).
It turns out there were objects attached to the window at the time of the crash. I removed all objects from the window before the crash point and the crash stopped happening. At that point I decided to simplify my code to make it easier to make a minimal example. After simplifying the code, the crash is no longer there. (yes I removed the remove all objects part)
I was displaying an alert window in the form of a button and every time I wanted to show another alert I would create another button. At the point of the crash, all alert buttons should have been deleted; which apparently was not the case. In my simplified code, I use one button and just change the text for each new alert. (Which is much more elegant for my implementation.) I assume it was just bad code on my part. Thanks for your help.
-
Considering the contents of the unfocusAllObjects function, I think a crash in that function can only be caused by a bug in tgui.
If you have the time and you don't mind then you should add all tgui source files in your project and link to opengl.
In debug mode, you should be able to find out in which situation the crash ocurred. If m_FocusedObject turns out to be corrupted (higher than the amount of objects) then it is indeed a bug in tgui and it should be fixed.
Whether you test the thing above or not, if you don't mind then I would like to see the code you were using so that I can do some debugging and hopefully find out why it crashed.
-
I never had crashes there before.
According to what I see in the backtrace, this happens when you press the mouse button, right?
unfocusAllObjects can't crash if no objects were created. The only thing I can think of is that somehow the m_FocusedObject variable is messed up, but it is changed in many places.
Could you show a minimal example of how to reproduce this crash?
Some other info might also help (OS, compiler, static/dynamic linking).
I don't know what you meant with linking to openGL so I made a code::blocks project which links to SFML 2.0 and has the TGUI source in it. There is some very minimal code in the main file which reproduces the crash. You might have to change the location of your SFML lib files in the project settings to get it to compile.
For some extra info: I'm using Ubuntu 12.04 x64 with gcc 4.6.3. Let me know if you find anything interesting or need anything else!
(The project was too large to attach to the post so I sent you a PM with a link.)
-
I don't know what you meant with linking to openGL
I didn't want to give too much details, because I didn't know your os yet. What I meant was add -lGL to the linker flags in case an undefined reference error would show up.
There is some very minimal code in the main file which reproduces the crash.
Thanks, the code lead me to the bug immediately.
I once made a change in one of the remove function (the one that takes a pointer to the object), but I forgot to add it to the other remove function (the one that takes a string, which you were using).
It has been fixed now. Thanks for your help.
-
Feature requests:
1. Texts inside progressbars (either centered, left or rightaligned).
2. Z-ordering or being able to have panels inside panels (containers etc)
3. Smaller fonts and controls in the formbuilder. Unusable on 1366x768 with textboxes
Btw, haven't forgotten about the archpackage, just havent had the time yet.
-
1. Texts inside progressbars (either centered, left or rightaligned).
2. Z-ordering or being able to have panels inside panels (containers etc)
3. Smaller fonts and controls in the formbuilder. Unusable on 1366x768 with textboxes
I'll make sure that all those things will be fully supported in v0.6.
1. Centered text is already possible with loadingBar.setText. I will add left and right alignment later.
2. Panels inside panels is already possible (even child windows inside child windows is possible).
3. The Form Builder will be completely rewritten. It will be a lot more useful when I am finished with it.
-
1. Texts inside progressbars (either centered, left or rightaligned).
2. Z-ordering or being able to have panels inside panels (containers etc)
3. Smaller fonts and controls in the formbuilder. Unusable on 1366x768 with textboxes
I'll make sure that all those things will be fully supported in v0.6.
1. Centered text is already possible with loadingBar.setText. I will add left and right alignment later.
2. Panels inside panels is already possible (even child windows inside child windows is possible).
3. The Form Builder will be completely rewritten. It will be a lot more useful when I am finished with it.
Ohh, fancy news :D
-
lol no matter what I don't CMake keeps giving me the error mentioned in the tutorial for setting this up. I know for a fact that I have the right locations and even sectioned off an area with the directories it wanted with no such luck.
(http://i.imgur.com/qv6hV.png)
-
What does your SFMLHeaders folder contain?
As stated in the error, it has to contain an include AND a lib folder (which contains the libraries).
It would be easier if you didn't create your own folders, as SFML2-RC already contains these folders in its root directory.
-
the SFMLHeaders folder is where the include and lib files are so the only things I can think of being the issue is the root folder name itself. Other than that I have no clue since all the files are where they should be.
-
Apparently it can find the headers, but not the libraries. What's inside the "lib" folder?
-
Apparently it can find the headers, but not the libraries. What's inside the "lib" folder?
lol it was the way the lib folder was setup causing the issues since I just copied it from the build file. When I copied the lib folder from the build of SFML I have I forgot to remove the two sub folders in it and move the files within into the lib folder itself. Strange thing is I have a differently named copy of the folder it was wanting setup with all the lib files in one folder and it doesn't seem to see it. :o ???
-
Hello Texus,
I want to congratulate and also thank you for making this great GUI. I find it very simple and intuitive to use, just like SFML, which is just perfect. I'm looking forward to be using it in a game I'm making for a college project.
This is maybe an old topic, but I have a suggestion on the new callback system. It would be interesting to be able to connect a function to a certain event that is triggered on the widget. For instance:
editBox->addCallback( [&]() { cout << editBox->getText() }, tgui::EditBox::Focus | tgui::EditBox::Unfocus );
Keep up the good work!
-
I find it very simple and intuitive to use, just like SFML, which is just perfect. I'm looking forward to be using it in a game I'm making for a college project.
Nice to hear that you find it useful.
This is maybe an old topic, but I have a suggestion on the new callback system.
It isn't an old topic. After this rewrite I hope that I won't have to change the callback system again, so all suggestions to make it better are welcome right now.
It would be interesting to be able to connect a function to a certain event that is triggered on the widget. For instance:
editBox->addCallback( [&]() { cout << editBox->getText() }, tgui::EditBox::Focus | tgui::EditBox::Unfocus );
I am not sure what you are trying to do. Could you explain what you expect with passing that first parameter?
-
Well, say I have a function that I would like to be called every time a button is clicked. A function like
void MyCallbackFunc()
{
cout << "The button was clicked!";
}
, or any other appropriate reaction to the button click.
So I would callbutton->addCallback(MyCallbackFunc, tgui::Button::Clicked)
, or something like that. I think that would make things very easy.
-
The current idea is to implement it like this: (might still be changed though)
button->callbacks = tgui::Button::LeftMouseClick; // This can be set to multiple callbacks by using '|'
button->callbackFunction = myCallbackFunc;
You will even be able put the callback function in a class.
class myClass: public tgui::CallbackManager
{
bool callbackFunction(const tgui::Callback& callback);
}
button->callbackClass = myClass;
Of course in the above way, it isn't possible to have a callback function for every event (e.g. send unfocus and focus events to different functions). You can only have one callback function per object.
Also every class can only hold one callback function, as it has to be named 'callbackFunction'.
The last disadvantage is that the function has to be very strict: bool as return type and tgui::Callback as parameter.
However, the above code has been tested and I am thus sure that I could implement this.
I will of course see if it is possible to do something like you suggested, but I fear that I won't get very far.
In bigger projects you will probably use classes and the above implementation is the only one that I found so far that can send callbacks to a non-static member function.
But as your suggestion with the addCallback method seems easier to use than what I have implemented so far, I will definately keep looking to get something like that to work (whenever I find the time for it).
-
You could also do an array(or some other kind of list) of callbacks along with the addcallback if you can figure it out. :) That would wipe out a few issues people are mentioning and add some more functionality in the process.
-
Maybe making use of some C++11 features (or boost, previously) would make things a little easier?
#include <iostream>
#include <functional>
#include <map>
#include <vector>
class Button
{
public:
typedef std::function<void()> callbackfunc ;
enum Clicked { LeftMouseClick } ;
void addCallback( callbackfunc cbf, Clicked click )
{ callbacks[click].push_back(cbf) ;}
void doCallbacks(Clicked c)
{
switch ( c )
{
case LeftMouseClick:
for ( auto cb : callbacks[c] )
cb() ;
break ;
}
}
private:
std::map<Clicked, std::vector<callbackfunc>> callbacks ;
};
class myClass
{
public:
myClass ( Button & b )
{
// onMouse = std::bind(&myClass::onMouseClick, *this) ; Don't need this!
b.addCallback(std::bind(&myClass::onMouseClick, *this), Button::LeftMouseClick) ;
}
private:
void onMouseClick()
{ std::cout << "onMouseClick()\n" ;}
// Button::callbackfunc onMouse ; Don't need this!
};
void myCallbackFunc()
{ std::cout << "myCallbackFunc()\n"; }
int main()
{
Button b ;
b.addCallback(myCallbackFunc, Button::LeftMouseClick) ;
myClass mc(b) ;
b.doCallbacks(Button::LeftMouseClick) ;
}
Edit: myClass doesn't need to keep a copy of the std::function object. Commented it out.
-
I don't want to use C++11 (I am trying to keep the same compiler support as sfml, so I don't want to force anyone to the latest compiler just to use my gui), but I was just considering using boost. I have been trying to avoid it for some time because I don't want another dependency, but I am starting to realize that I will have to use it eventually.
Thanks for the code example. I will take a better look at it when I find some more time.
-
Thanks to the code that cire posted, I have been able to get the callback system to work like this:
void function1();
void function2(const tgui::Callback& callback);
class myClass
{
void function3();
void function4(const tgui::Callback& callback);
}
button->bindCallback(function1, tgui::Button::Focus);
button->bindCallbackEx(function2, tgui::Button::Focus);
myClass app;
button->bindCallback(boost::bind(&myClass::function3, &app), tgui::Button::Focus);
button->bindCallbackEx(boost::bind(&myClass::function4, &app, _1), tgui::Button::Focus);
The function passed to bindCallback takes no parameters while the function passed to bindCallbackEx takes a tgui::Callback parameter (so that you can send multiple callbacks to a single function and still distinguish the callbacks from each other.
I wish I could make the last two lines easier, but I guess it will have to stay like that.
It would also be nice if the bindCallback and bindCallbackEx were merged, but I haven't found a way to do that yet.
PS: A part of boost will be included with tgui so you won't have to install it yourself. You can just use boost::bind without including anything extra.
-
For Function and Bind, you don't need Boost. They are part of the TR1.
-
Well I don't really know enough about these things and I don't have the time to find out and test how to use it on different compilers.
It will be a temporary solution anyway. I will try to make v0.6 support older compilers, but from v0.7 on I will probably drop this support and start using c++11.
So whether I decide to use boost or tr1, it will only be for the next release.
-
Mouse wheel support was added. You can now scroll through the list boxes, text boxes, ... without having to drag the thumb around.
I think I have also found a nice solution for the new callback system.
There is no need for boost, tr1 or c++11 in the user code and the function name can stay the same.
void function1();
void function2(const tgui::Callback& callback);
class myClass
{
void function3();
void function4(const tgui::Callback& callback);
}
// Bind free functions (either with or without the callback parameter)
button->bindCallback(function1, tgui::Button::LeftMouseClick);
button->bindCallback(function2, tgui::Button::LeftMouseClick);
// Bind member functions (either with or without the callback parameter)
myClass app;
button->bindCallback(&app, &myClass::function3, tgui::Button::LeftMouseClick);
button->bindCallback(&app, &myClass::function4, tgui::Button::LeftMouseClick);
// Make the button send the callback to its parent so that it can later be polled from the window
button->bindCallback(tgui::Button::LeftMouseClick);
The above code is just an example, it wouldn't work as you can only bind one function at a time (to a specific callback trigger). Also there probably won't be any definite decision in the next month, so the implementation can still be discussed and changed.
-
Nice! I believe this kind implementation would allow binding of lambdas as well.
-
Lambdas should work. I just did some tests and you should be able to do the following:
auto function5 = [] () { /* ... */ };
auto function6 = [] (const tgui::Callback& callback) { /* ... */ };
button->bindCallback(function5, tgui::Button::LeftMouseClick);
button->bindCallback(function6, tgui::Button::LeftMouseClick);
-
The post is a bit long, if you don't want to read it all, voting on the polls at the bottom of my home page (http://tgui.weebly.com) will already help me a lot. But I hope that some people will take the time to read it and give me their opinion about how the new callback system should be implemented.
First a small explanation on how the new callback system will work.
The current implementation is just polling the callbacks from the window, which is only a small part of the new system.
(http://i1119.photobucket.com/albums/k625/texuz/TGUI/NewCallbackSystemProposal.png)
When a callback is triggered (e.g. the button has been clicked) then the following process will happen:
A: If bindCallback was used to bind a function to the callback trigger (mouse click), then the function will be called.
When a callback was requested for the trigger which isn't bound to a function (a bindCallback call were only the trigger was passed) then the callback will be passed to the parent object.
B: If a global callback function was set then this function will be called. Otherwise the callback will again be passed to the parent until it reaches the window.
C: If a global callback function was set then this function will be called. Otherwise the callback will be added to the callback queue and you will later be able to poll it from the window with getCallback.
When starting implementing it, I found out that it's not a big problem to bind multiple functions to one trigger so forget what I said before about binding only one function. You will be able to bind as many functions as you want to.
There are still a few things that could be changed.
First of all, I am not sure if bindCallback is a good name. Functions aren't really bound as you can connect multiple functions and calling the function with only the trigger parameter won't bind anything, it just tells the object to warn its parent on a callback.
Secondly, wouldn't the name pollCallback be better than getCallback (looks more like pollEvent)?
I have added polls for this on my site, so you can tell what you think is best there.
That leaves one last issue. When either in A, B or C, the callback is send to a function, it will never reach the callback queue. To illustrate it in the picture: if an arrow to the right is followed, then the process will stop and not continue going up.
This might be what you want, but in some situations you might want to silently bind a function, so that you are alerted about the callback but the process still continues.
I could make callback functions return a bool to signal if the callback has been handled or if it should continue to the other callback functions. An other option would be always go through all steps and don't stop when one callback function is called, but this means that all callback will reach the queue in the window and you must thus always poll the callbacks, even if you already handled them in different functions.
Any opinions on what the best option would be?
-
Hey, I have a question. Your lib looks great and I want to use it for my project. However, as you posted here on new callback system (which I like a lot), I have a question if it's already implemented in 0.5? Because I need the api to be stable in terms of callbacks, so I don't want to change it in 2 months.
Thanks
-
No, the new callback system won't make it in v0.5.
Actually v0.5 is ready, I am just waiting for sfml2 to be finished before I call v0.5 the stable release.
So v0.5 won't change anymore (except for perhaps bug fixes) and the first preview of v0.6 isn't coming before February, so you won't have to make any unexpected changes.
-
Okay thanks mate.
But, you know, I wouldn't count for SFML 2.0 going stable before we retire :P So you may as well stable it now, as SFML 2.0 api won't change and it's now as close to stable as it can ever be.
Is 0.5 good enough for a hmm medium game (well, not tetris clone and not very big one too)? Or there are any design "bugs" that make some things hard to do and I should wait for 0.6?
-
I was very close to decide to call v0.5 finished, but I am glad I didn't do it. The next day the convertCoords function got renamed to mapPixelsToCoords, so I had to change my code again. So although sfml2 is stable, I'd like to wait until I am 100% sure that no more changes will be made.
I think v0.5 will be good enough. There will always be some things to improve, but definitely don't wait for v0.6. Although I am planning to improve so many things, it won't be until August or so before all those changes are done. Even if I have enough time to launch an early prerelease in February, it won't contain much more than the new callback system.
-
Hey,
I am trying out your lib for my current project. I think the design is great; very flexible and straightforward. It would be great to have some tutorials on your website about the way the different controls work with regards to the "load" function, that is, what my pngs should be named, what their functionality is, and what should go in the config text file. For example, I want to use a SpinButton, but you supply no example theme (that I could find) for that type of control, so I don't know how to create one.
Also instructions for writing forms would be helpful. The current FormBuilder does not support all the controls available, so I need to be able to hand-write forms.
Thanks!
-
There should be two example themes in the TGUI/objects/SpinButton folder.
An example code of a panel can be found in the tutorial (http://tgui.weebly.com/v05---panel.html) section.
I admit that the loading isn't always the easiest thing. If I would know a better way then I would change it, but for now you will just have to experiment a little bit with those info.txt files. (There is some information here (http://tgui.weebly.com/infotxt.html), but it is a bit outdated)
-
Ah, I only saw the "objects" in the "FormBuilder" folder, so that explains it.
The main issue for me now is that I don't know what parameters to put into my form.txt. If you could just put up a list of form parameters for each object, that would be great (because they don't all use the same parameters).
-
The parameters that you can use for all objects are size, width, height, scale, position, left, top and callbackid.
For now, for the parameters per object, you should take a look in Group.cpp in the loadObjectsFromFile function.
It checks for the object and looks at all possible parameters.
I will try to create a list tomorrow, I don't have time right now.
EDIT: I Created a tutorial about the Object Files (http://tgui.weebly.com/v05---objectfiles.html) which contains the list of all options.
-
Btw, there is a little error on tgui's page. It should be "Texus' GUI" not "Texus's" ^^ (and it does not mean plural in this case)
-
Is it really wrong?
According to this (http://www.englishforums.com/English/ApostropheAfterNameEnding-S/cwcnp/post.htm) and this (http://www.grammarbook.com/punctuation/apostro.asp) (which were the two first search results) it is correct to write "Texus's".
I am not a native English speaker, but from what I have read it looks like both ways are correct but "Texus's" is the preferred form.
-
Either is correct. I don't know that there's a preferred form. It would certainly vary by source, but I think appending the 's' is more common than not since it more closely resembles the actual pronunciation.
-
I really like the new callback system, I think you're in the right track, good luck!
-
I decided to no longer wait until sfml2 is finished.
TGUI v0.5 is now considered to be the (first) stable version.
Here is a small summary of the most important changes:
- New objects
- ChildWindow
- SpinButton
- AnimatedPicture
- Tab
- Grid
- Performance boost (in some situations)
- Better design, to allow custom objects
- Unicode support
- Many bug fixes
I really like the new callback system, I think you're in the right track, good luck!
Thanks. I will make the development version of v0.6 public as soon as I finish this new callback system.
With a little bit of luck, this can already be in a few days (otherwise it will be February as originally planned).
-
Where can I download 0.5 stable? The link on the site is broken. (https://github.com/texus/TGUI/zipball/v0.5-dev (https://github.com/texus/TGUI/zipball/v0.5-dev))
And a question, is it possible to have a subwindow but that is only managed by tgui? That I can move inside the window and put widgets there? Something like here http://www.mobygames.com/images/shots/l/262890-guild-wars-eye-of-the-north-windows-screenshot-a-sample-of.jpg (http://www.mobygames.com/images/shots/l/262890-guild-wars-eye-of-the-north-windows-screenshot-a-sample-of.jpg) but of course less fancy. I think that panel may be the thing, but I'm not sure. Do I have to write my own widget?
-
Where can I download 0.5 stable? The link on the site is broken.
Sorry about that, I forgot to update it. It should be fixed now.
And a question, is it possible to have a subwindow but that is only managed by tgui?
Yes, that would be the ChildWindow object.
-
Great. Your gui is a no-brainer, I'm going to use it for my game. Very easy to use and integrate into my code. Btw, I downloaded master branch snapshot directly from github, is it the same version as the one you have just uploaded on your site?
-
I downloaded master branch snapshot directly from github, is it the same version as the one you have just uploaded on your site?
Yes, it is exactly the same version.
But once I start with v0.6 then the master branch will become v0.6 and a separate branch will be created for v0.5.
-
I have having difficulties with Cmake 2.8.10.2, tgui 0.5, and visual studio 10 express. I hope this is the most appropriate forum in which to ask such a question, but if not let me know. here goes
I have SFML 2.0 working just fine, i did not have to use cmake to make the project files. I've had success before with cmake on another project (box2d)
the problem is I cannot get cmake to work without error for tgui (and other items i've tried) so I suspect something with my visual studio changed, perhaps i am missing a path variable? i have tried to figure out which one, anyways, the error(s) i get with Cmake are as follows
The C compiler identification is unknown
The CXX compiler identification is unknown
Looking for sys/types.h
CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeCInformation.cmake:37 (get_filename_component):
get_filename_component called with incorrect number of arguments
Call Stack (most recent call first):
CMakeLists.txt:3 (PROJECT)
CMake Error: Internal CMake error, TryCompile configure of cmake failed
Looking for sys/types.h - not found
Looking for stdint.h
CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeCInformation.cmake:37 (get_filename_component):
get_filename_component called with incorrect number of arguments
Call Stack (most recent call first):
CMakeLists.txt:3 (PROJECT)
CMake Error: Internal CMake error, TryCompile configure of cmake failed
Looking for stdint.h - not found
Looking for stddef.h
CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeCInformation.cmake:37 (get_filename_component):
get_filename_component called with incorrect number of arguments
Call Stack (most recent call first):
CMakeLists.txt:3 (PROJECT)
CMake Error: Internal CMake error, TryCompile configure of cmake failed
Looking for stddef.h - not found
Check size of void*
CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeCInformation.cmake:37 (get_filename_component):
get_filename_component called with incorrect number of arguments
Call Stack (most recent call first):
CMakeLists.txt:3 (PROJECT)
CMake Error: Internal CMake error, TryCompile configure of cmake failed
Check size of void* - failed
CMake Error at cmake/Config.cmake:14 (message):
Unsupported architecture
Call Stack (most recent call first):
CMakeLists.txt:24 (include)
Configuring incomplete, errors occurred!
this is from cmake-gui started from the visual studio command prompt,
i've tried looking up most the messages without any clear definite leads
i've tried adding includes for visual c++ to my system path (i do have sys\types.h, its right there with all the others)
i've tried a lot of things for hours over the past few days, so I'm hoping someone can help me even a little because i'm burnt out on google
Thanks in advance
-
I found a bug in child window - you can move it outside the window, and if you move it up so the title bar disappears you cant move it back and close it. I see 2 solutions:
- function to set if you want childwindow always fully stay in your main window
- ability to move it through alt + hold (but this will be in conflict with linux windows managers, so maybe it's better to move it through LMB + RMB hold)
The solution #1 is often used in MMORPG games. It can be tweaked so for example when you move it to bottom, you can hide it all except title bar etc. but plain simple "stay fully in window" flag would be really great.
I thought I could handle it myself in my code, but I don't see getPosition function in child window :/
What do you think?
In case you will want to fix in 0.6, could you make v0.5.1 with some kind of getTopLeftCornerCoords (including titlebar) for childwindow? It won't break stable API, it will just add new function (many libs do it, I think you don't need the api to be fully frozen in stable branch, it's not widely-used for production library). Altough, I don't see a reason why it won't become widely-used one day!
Please, I really need it in my game. Your GUI is great, but I just need that little problem to be fixed.
Thanks!
EDIT:
And just a little question, do you plan to add a simple menu? I don't know what's the proper english name, but that of a menu like "File" menu, when you press it you have a vertical list with options to choose. Maybe a suggestion for 0.6 :)?
EDIT2:
Oh and another question. Is it possible to have a panel which has fixed height and it's width is always 100% of the window (so it's resize proof)? And vice versa - fixed width and height in %.
I hope that you will find time to answer me :)
-
I am going to reply very briefly (I had typed a whole message, but because the preview wasn't loading fast enough I pressed F5. Very bad habit, I lost the whole text with it.)
@Venevus
I can't help with the cmake problem. I never had a problem like that (but I don't have the express version).
You could try with cmake directly instead of cmake-gui but I don't know if that's going to help much.
Otherwise the only thing I can think of is try to re-install VS.
@netrick
All objects are derived from sf::Transformable, so they all have a getPosition function.
I will look into a way to keep the child window fully in the window when I have more time. I remember trying this once and for some reason I didn't do it. So I must have hit some problem with this.
MenuBar is planned for v0.6.
Objects don't have the possibility yet to have their size as a percentage of the window so you will have to do this manually. I even doubt that it will be possible in v0.6, but I am going to add it someday.
-
Okay, so getPosition + getTilebarHeight is enough for me, thanks.
And as for % size, the best way to do it manually without changing TGUI code is to catch resized event and reload widgets, yes? I won't lose any texts in editbox etc this way?
-
The best way to do it manually without changing TGUI code is to catch resized event and reload widgets, yes? I won't lose any texts in editbox etc this way?
If by reloading you mean call the load function again then you will probably lose some stuff.
You should rather just call the setSize function of the objects.
-
Hey, I wrote code to keep child window in window myself. You said you had some problems, so I will post it here just in case. Of course, the code could receive some optimization and you will need to call it in your child window's move function, but here it is:
if (tgui::ChildWindow * pointer = tguiWindow.get<tgui::ChildWindow>("childWindow"))
{
if (pointer->getPosition().y < 0)
{
pointer->setPosition(pointer->getPosition().x, 0);
}
if (pointer->getPosition().x < 0)
{
pointer->setPosition(0, pointer->getPosition().y);
}
if (pointer->getPosition().y > window.getSize().y - pointer->getTitleBarHeight())
{
pointer->setPosition(pointer->getPosition().x, window.getSize().y - pointer->getTitleBarHeight());
}
if (pointer->getPosition().x > window.getSize().x - pointer->getSize().x)
{
pointer->setPosition(window.getSize().x - pointer->getSize().x, pointer->getPosition().y);
}
}
You will need to wrap it into function (taking name as argument). I call it after updating input and before rendering.
It has wanted behaviour - in top, right and left window border the childwindow must stay fully in window, and it can hide under bottom border but the titlebar will stay in window. I use separate sfml window (called window) and tgui form (called tguiWindow). This is also segfault proof in case child window was deleted (the first if).
EDIT:
Also, I found a apperance bug in child window moving. When you move your OS windows (by holding titlebar), the mouse is always fixed at one point on the title bar. However in TGUI's child window the mouse moves very clearly when moving, even outside the titlebar. And it goes back to proper place when you stop moving mouse. This looks very inconsistent, could you look into it? If you don't understand me (my english is poor) I can make a video.
Maybe that's because TGUI child window tries to follow the mouse (and smooth it by movement animation) rather than just render at the mouse position (of course, taking in account that mouse position isn't top left corner but some specific point)?
-
After seeing that code I remember what the problem was (and still is).
I cannot ensure that the parent object of the child window will be the tgui window. It is perfectly possible that the child window is inside a panel or another child window. The point is that I cannot access the getSize method. With the current design of my gui it is just not possible.
So you will have to do it manually like you are doing it now. All I could do to make it easier is let the child window send callbacks when it is moved, but that will come with the new callback system in v0.6.
in TGUI's child window the mouse moves very clearly when moving, even outside the titlebar. And it goes back to proper place when you stop moving mouse.
I don't have such a problem. Here the child window seems to respond like it should.
-
I will keep doing it myself. Btw, is there a way to re open child window after it was closed?
And on the bug:
when I disabled vsync, everything is great. However, the bug is present with vsync enabled (especially with fast moves, but with normal ones it is visible too). Do you have any idea? Could you look yourself with enabled vsync and doing fast moves? This bug is especially visible when doing quick top-down moves. When I enable vsync, the bug is so annoying. The thing is, I need vsync for my fast paced game.
EDIT:
With setFrameratLimit(60) the bug doesn't happen too! And at @60Hz Vsync there is the bug... I don't know, do you have any idea?
EDIT2:
I have an idea... I looked into TGUI source and the reason may be it uses window events. I just think that it *may* work better when using tracking window focus + using real time mouse input. I will try it, but please let you look into this vsync issue too.
-
is there a way to re open child window after it was closed?
If you change the callbackID of the child window and you thus allow it to send callbacks then you are responsible for destroying the window (see tutorial (http://tgui.weebly.com/v05---childwindow.html)). So you could choose to cancel the closure for instance.
Otherwise, if you want the window to really disappear, but you don't want the window to be recreated every time, then instead of destroying it you could just hide it.
Maybe it would be better if you make a video so that I can see the bug. I think I am able to reproduce it but it doesn't look that bad to me so perhaps its worse on your pc. To me the mouse goes of by only 1-3 pixels.
But I don't think it can be solved easily. My code is pretty simple: when mouse goes down remember the position, when mouse moved check how far the mouse moved and move the window accordingly. So there isn't much place for mistakes there. I only notice that I am using floats there, but that is not so easy to adjust and even with rounding the numbers (which I just tried) the result stays the same.
It looks more like the screen doesn't update enough to follow the mouse.
-
I'll make a video tommorow and also test the drag and move code which uses real time OS mouse input. However, the bug happens on linux with vsync in windowed and fullscreen mode. BUT, on windows, with vsync on, it only happens in fullscreen mode. I think it's a bigger problem here.... I tested in Guild Wars on windows, and the bug is also there, of course only on full screen vsync. Strange.... But I just don't know why on linux this happens also on windowed vsync.
And another thing that I don't understand is why vsync causes this bug and limiting to 60 fps using waiting at the end of frame doesn't. Clearly there is something going on with window events while vsynced, but it's different on windows and linux... I hope real time input will solve it.
edit:
From my research, it looks like that vsync indeed causes mouse lag related to double buffering in some way. And it also may be that you will only get mouse moved event 60 times a second and it isn't "you get it when you ask". but rather "vsync makes an event for you every 1/60th and you won't get exactly at the time". Of course, setting frame limit to 60 using timers, gives you "you get event when you ask for it". I think real time mouse input not based on event is a solution, but currenctly I'm fixing some bug in my drag and move code so I can't tell for sure... This is wrong, the input lag is not based on input - the app gets input perfectly right (even just window events), but just the display() operation lags, because it waits for vsync. And the mouse moves independent of your app, so that causes the lag. It's not a bug in TGUI, it's just classic vsync input lag.
Well the solution may be to use triple buffering - which would be a question to Lauren. But, I doubt we will see it quickly...
edit2:
No, at least in my poor drag and move code real time os input didn't help... The question is why on windows the bug is only on fullscreen vsync while on linux it happens on both windowed and fullscreen vsync...
edit3:
When using both vsync and framerate limit @ 60, the bug is... not present. I don't get it, I have no idea what's going on and why on Windows in windowed vsync the bug isn't present....
-
Just a tip : Laurent said you're never supposed to use both framerate and vsync at once.
-
So, I think I know it now. Indeed, vsync makes input lag, because you give the window.display() command and it displays a bit later (and with limiting fps using internal timers, window.display() will display on screen instantly). I also know why on windows xp in windowed mode the vsync doesn't cause input lag. The thing is that on all pre-vista windows, vsync in windowed mode isn't true vsync - it's more like limiting fps using internal timers (not exactly, but the point is there is no input lag). On windows vista/7 however, in windowed vsync there is an input lag. The solution? Well, there are few:
1) Don't use vsync at all (it depends on the game really if it looks good without it)
2) Just limit framerate @60 fps using internal timers (but this still keeps tearing in some cases)
3) It's especially used by FPS gamers and it seems to work in 2D games too. Enable vsync AND enable framerate limit to 59 FPS (screen framerate - 1). This is the approach I'm going to use in my game.
4) vsync + triple buffering - impossible in sfml, reduces input lag to minimum but it is still there.
Sorry for that wall of text in my poor english, I hope you get. In case you have something to add on this topic, I would be very glad to hear it. Thanks and merry christmas mate!
@FRex
Well, it is commonly used approach especially by FPS gamers. It is the only way to avoid both tearing and input lag. The only. The vsync + triple buffering approach helps, but still leaves small input lag. And I tested it on amd, nvidia, windows and linux and I didn't see anything wrong - but I've seen no tearing and no input lag. Maybe it's in theory not fully defined behaviour, but well, it works.
-
Sorry for that wall of text in my poor english, I hope you get. In case you have something to add on this topic, I would be very glad to hear it. Thanks and merry christmas mate!
I have nothing to add to that. Its just good to know that the problem wasn't in tgui and I am glad that you could solve the problem. Merry Christmas to you too.
-
Is it possible to set texture rect in tgui::Picture? And draw it multiple times before drawing the whole gui? I mean in the single loop run I do:
I have a picture object.
- picture.set rect and position
- picture.draw
- picture. set rect and position
- picture draw
- do it a few times
- call tguiWindow.draw() and have all those pictures drown (like normal sf::Sprite)?
Currently I have a panel, on panel I render using sf::Sprite but this way child window is drown under the sfml sprites and it looks ugly. I need have layer #1 panel, layer #2 images, layer #3 childwindow and the only way to do it is to have images managed by tgui but tgui::Picture doesn't inherit from sf::Sprite and probably don't have that multiple draw behaviour so I'm stuck.... How can I do it?
The only way I can think of is to render those images using sfml to a render texture and set this texture as tgui::Picture, but I'd like to avoid it because render texture in sfml has serious problems on intel cards right now and it won't be fixed soon.
EDIT:
Oh I see that the intel gpu render texture isue has been fixed. That's great. However I'd still like to hear an answer on my tgui::Picture questions, as if there is a way to do it the code would be much cleaner.
-
Picture wasn't really made for advanced usage like setting a rectangle, it is just a simple wrapper around sf::Texture and sf::Sprite.
If the rectangle is a specific cell in the picture (the picture can be divided in several rows and columns and you want to draw just one cell of it) then you can use tgui::SpriteSheet.
No way is provided to split the drawing in two parts. All objects are rendered at once.
But from what I read in your description you won't need to do this. If you can use the SpriteSheet then the pictures will be drawn on the panel and the child window will be drawn on top of it.
-
Okay. It is indeed a tileset, so SpriteSheet looks good for it, however - it can have only one visible rectangle at once if I'm correct. So if my tileset has 128 tiles, I will need 128 SpriteSheets, yes?
That would be a very big memory waste :/ Tileset is big.
This is all because i need to display all tiles from tileset in a grid as GUI element. It's not for a map render but for editor, and honestly I have no idea.
edit:
I have an idea. Can multiple SpriteSheets share one texture (tgui::Picture)?
edit2:
I know! I will create custom object called "TileSheet" and I will just almost copy-paste sprite sheet code, but it will just hold a pointer to tgui::Picture, so I will just create an array and set the pointer trough a loop (I will only to do it at start up, so no performance problem). Hail open source!
But if you have an idea for easier way of doing it, feel free to tell me about it ;)
-
There is an internal texture manager in tgui. The same filename won't be loaded twice.
Just load the 128 SpriteSheets, they will all use the same texture. There shouldn't be any memory waste.
-
Oh lol. That's great, amazing job.
EDIT (as always):
I have another question. In my game I need key pressed event repeating to be set to false all the time. Of course, it must be enabled when edit box is active. So my question is as follows:
Is it possible that editbox send callbacks when it's focused and unfocused? So I can handle it and enable/disable it when needed.
Thanks in advance!
-
Is it possible that editbox send callbacks when it's focused and unfocused? So I can handle it and enable/disable it when needed.
I am afraid not. This is part of the new callback system. Focused and Unfocused callbacks are only send in v0.6.
I know that its not optimal, but you will probably have to find a way by constantly call isFocused and check if the status changed.
-
Hmm does the object know when it gains/loses focus? If yes, then maybe I can easily add one function to editbox code and recompile TGUI?
-
The objects have objectFocused and objectUnfocused functions.
EditBox already has objectUnfocused so you will only have to add the objectFocused function.
If you add the function to EditBox then it will automatically be called, you don't have to do anything else.
From inside these functions you could send your custom callback.
if (callbackID > 0)
{
Callback callback;
callback.object = this;
callback.callbackID = callbackID;
callback.trigger = 50; // Set the trigger to something to identify the callback
m_Parent->addCallback(callback);
}
-
Thanks. I have three questions:
1) Is there a way to get names of all objects that exist in panel/window?
2) If in panel there is added object called for example "object5", and I add another "object5" of the same type to the panel what will happen?
- the former "object5" wil be overwritten?
- or the former "object5" will be kept without changes?
3) What happens if I delete an object which doesn't exist?
-
1) getObjectNames
2) When you add an object with the same name (same type or not) then the previous object will remain unchanged. But this is a bad thing to do because the get or delete functions will only look for the first match.
3) The remove function won't do anything if the object doesn't exist.
-
Thanks. Uhm I'm stuck now with rendering tiles on panel.
Well, I think that sprite sheet isn't for me :/ Rendering 1200 32x32 tiles using sfml and texture rectangle gives me about 550-600 fps, and rendering 160 32x32 sprite sheets using the same tileset (AND disabling rendering of normal map), gives me 120-150 fps, so there is a serious performance problem. I don't know, I must find a way to do it with SFML speed on TGUI level. I can easily add tgui::PictureRect, but that will be still performance problem because it can't be used like that: set position -> draw -> set position -> draw -> drawTGUI. So I don't know, I have no idea why sprite sheets work so slow for me.
All I do in my sprite sheets drawing function is:
- I have 256 sprite sheets already loaded (every uses the same tileset) and every of them has a cell already set (sheet0 is tile 0 etc)
- Then, in my drawing function all I do is:
hide all sheets
set positions for visible sheets the same way I set positions for sfml sprites (so it's not performance problem)
call show() for visible sheets
I need hide and show at every call because it is in scrolled panel. But, after removing show and hide calls (so i always render every sheet) fps went up only to 180. So the bottleneck is in other place. Could you look into it, why sprite sheet is so slow?
-
Is there a way to remove every object of one type from a panel?
Not directly, but you can use getObjects to get pointers to all objects, use object->getObjectType to find out if it has the correct type and then delete it with the remove function.
I think that sprite sheet isn't for me
Performance wasn't really important when I started, so there is indeed a lot to improve.
Ok, I have another suggestion to get this done:
window.updateTime(elapsedTime); // You need to make this call if you don't use drawGUI
window.draw(panel);
// draw images directly with sfml
window.draw(childWindow);
The only problem with the above is that the child window should not be part of the panel and should be part of the window. But depending of the situation this isn't a problem.
-
Thanks, I will try it out.
All my childwindows belong to a window (I don't see a reason why they should belong to a panel), so it's not a problem.
EDIT:
I have an easier idea:
while (true) //main loop
{
draw panel background with pure sfml
draw tiles using sfml
call drawtgui which will handle all childwindows for me (and it will draw a transparent panel which won't hide tiles and the visible widgets on the panel like scrollbar don't interfere with tiles
}
I hope this one will work. But there is a little problem - I hope that panel background can be transparent in 0.5.
edit2:
It works! However I still don't understand something. Rendering only map (1200 tiles) - 550fps, rendering map + 160 tiles on panel using sfml - 450fps.
For sure there is something that I can improve in my render code, however fps now is fine.
-
What's the way of working with get object type? Because something doesn't work here:
std::vector<tgui::OBJECT*> & objects = tgui.getObjects();
for (int i = 0; i < objects.size(); i++)
{
if (objects[i]->getObjectType() == tgui::ChildWindow) correctChildWindow(objects[i]);
}
And in the "if" line I get "error: expected primary-expression before ‘)’ token" and I have no clue what's wrong, probably I check type in wrong way.
EDIT:
Also, I think the design of this function has a flaw. Because when I get a pointer to a child window (but is OBJECT* actually), i can't use getTitlebarHeight(). Any idea on this one too? Maybe reinterpret cast? But I think that's a bad idea.
-
What's the way of working with get object type? Because something doesn't work here
getObjectType returns a member of the ObjectTypes enum defined in TGUI.hpp.
This is the class name, but without the capital letter. So it should be tgui::childWindow instead of tgui::ChildWindow.
It seems like this isn't in any tutorial, I'll have to change that when I have some more time.
In tgui v0.6 tgui::childWindow will be renamed to tgui::Type_ChildWindow for more clarity.
I think the design of this function has a flaw. Because when I get a pointer to a child window (but is OBJECT* actually)
All you need is a static_cast. The reason why you get OBJECT* is because the window isn't allowed to make any difference between objects. If you are sure that it is a pointer to a child window (which you are because you check the object type first) then you can just do the following to get the pointer to it.
tgui::ChildWindow* child = static_cast<tgui::ChildWindow*>(objects[i])
-
Thanks a lot! I also looked into my c++ book and it says the ideal solution for my problem is to use dynamic cast (which was actually made for casting from base class pointer to child class pointer). However, in this case static cast is indeed enough.
-
In tgui v0.6 tgui::childWindow will be renamed to tgui::Type_ChildWindow for more clarity.
Can't you just use tgui::ObjectTypes::childWindow if you need that level of clarity?
-
That would be another possibility, yes.
My main concern is that childWindow looks to much like ChildWindow.
Either Type_ChildWindow or ObjectTypes::childWindow would solve that.
But I do prefer Type_ChildWindow because another reason for the change in v0.6 is that all enums will start with capital letters. Of course a possibility would still be tgui::ObjectTypes::ChildWindow, but this is getting a bit too long.
-
Anyway, what's the point of type being named differently than a class? Actually class is a type. I just don't get it, it's counter-intuitive to me. Just put all classes' names in enum and that's it. It's very clear that tgui::Label is a type.
-
As far as I know you can't compare against a class.
And giving enum values the exact same name as the class isn't possible.
If you have an alternative solution then I would love to hear it. The only reason why there is an ObjectTypes enum is because I don't know any other (easy) ways.
-
Virtual method that returns magic number(enum maybe) or hashed string name of class(could choose some fast hash and just check it against all class names you have atm)? Maybe virtual and static methods that return same number so you'd do:
if(someptr->dynamicID==someclass::staticID)
{
//this someptr points at someclass
}
Maybe just use dynamic_cast for everything, not own type checking? That's why it's there.
Also, putting enums inside their own namespace or making them strong(since you're going c++11 anyway) so they don't collide with class names?
Sorry if you don't want input of someone who's sfg user, just say if you don't.
Edit: Oh, you already have virtual method that returns type, ops.. :-[
-
Virtual method that returns magic number(enum maybe) or hashed string name of class(could choose some fast hash and just check it against all class names you have atm)?
Possible, but a simple enum that lists all types seems a lot easier to me.
putting enums inside their own namespace or making them strong so they don't collide with class names?
So instead of Type_ChildWindow it would by Type::ChildWindow. This looks nicer than using the underscore, but in the end it is as good as the same.
Sorry if you don't want input of someone who's sfg user, just say if you don't.
I appreciate any input.
EDIT:
if(someptr->dynamicID==someclass::staticID)
{
//this someptr points at someclass
}
That could be a solution.
Then you could just check against ChildWindow::Type or something like that.
-
dynamic cast was kind of created because people were rolling their own rtti(I think..), why not just use that and instead of doing
if(ptr->getObjectType==Type::ListBox)
{
//cast ptr to listbox ptr and do something
}
do that:
ListBox * ptr2;
if(ptr2=dynamic_cast<ListBox>(ptr))
{
//do something with ptr2, its valid for sure
}
-
I learned something new today. I didn't knew what happened when casting to a wrong type.
I still prefer the first one, but as I don't have to do anything for the second one I can just let the user decide.
I will keep providing the Type::ObjectName so that people can check against the result of getObjectType() and those who want to use the dynamic_cast can do so.
That seems like a nice solution to me.
-
I learned something new today. I didn't knew what happened when casting to a wrong type.
With all due respect for being author of tgui and all, but I'm facepalming hard now. :)
I don't have copy of standard but I think it says classes must have virtual methods to be dynamic castable.
And references throw bad_cast exceptions while pointers come out as nulls, since they can't be 'null' or point to invalid location.
-
I learned something new today. I didn't knew what happened when casting to a wrong type.
With all due respect for being author of tgui and all, but I'm facepalming hard now.
That's what you get from not learning with a book, but learning only what you need at a given moment: you'll skip small parts.
I am going through "The C++ Programming Language" right now, so eventually (when I reach chapter 15) I will finally get a decent explanation. I only need to know the first 12 chapters this year for university, but I'll probably read the rest too.
Thanks for helping to find an alternative method for checking the objects type by the way.
-
Oh god, I never learned from a book. Don't scare me. :'(
That's how sfgui does that, they have their own cast(the reason why new style casts mimic template function is so that you can roll your own and use it similarly) that does some magic with their smart pointer class but inside it's dynamic cast too.
-
do that:
ListBox * ptr2;
if(ptr2=dynamic_cast<ListBox>(ptr))
{
//do something with ptr2, its valid for sure
}
+1 to it and it's also what I'm using in my project. This way, you don't have problems with types' names and you even don't need get type function at all. I think that's very clean C++ish solution. Of course you can keep the enum, but you can as well remove it.
Look at it, so easy and clean. I think it's faster than get object type (not that it makes any difference, but you know :P) I think many libs I know don't provide get object type at all.
std::vector<tgui::OBJECT*> & objects = tgui.getObjects();
for (unsigned int i = 0; i < objects.size(); i++)
{
if (tgui::ChildWindow * ptr = dynamic_cast <tgui::ChildWindow*> (objects[i])
{
//do your stuff
}
}
EDIT:
I looked a bit through tgui docs and you can improve some things:
- when you pass int by value, why you have it like "const int argument"? const is pointless here, just pass basic types by normal value
- you pass strings as "const std::string argument", while it should be "const std::string & argument", and the same applies for every object, like sf::String (look at sfml for example)
Actually you pass some objects by const reference and some by const value, you should correct it (will be faster and better designed)
Also, there is another thing to improve. Your install script for linux is inconsistent. First of all, usually when you "configure make make install" lib on linux, it goes to /usr/local/lib and headers go to /usr/local/include. Your script gives libs to "/usr/lib" and doesn't copy headers anywhere at all (which is very windowish solution and you should just copy everything to /usr/local, as this way you don't need to set include/lib/code completion paths, but just #include or -ltgui. And much more transparent system. Of course, when you make install sfml it goes to /usr/local/lib and /usr/local/include. Its just default location for make install (sudo make install on ubuntu).
You know, windows itself doesn't offer any place to keep user libs and headers so you need to store them on your own, but linux has such an amazing location as /usr/local :) And adding libs to /usr/lib isn't good, because that's place for libs that aren't compiled by user, but for those that are already provided by system.
Just sugestions to make TGUI even better :)
-
Of course you can keep the enum, but you can as well remove it.
It will be kept for a very simple reason: if you try to look for all Panels then with the dynamic_cast method you will find ChildWindows as well (because they inherit from Panel). So the enum will definitely be kept for such cases where the exact type is important.
I looked a bit through tgui docs and you can improve some things
I'll look into those things. The problem with the consts is caused because I added const parameters and functions in just one evening. I should have taken more time and do it a bit more concentrated.
Also, there is another thing to improve. Your install script for linux is inconsistent.
I think I used /usr/lib instead of /usr/local/lib because I read something about some distros not looking in the /usr/local/lib folder. But the install script should be redesigned anyway, together with the whole installation way on linux (the Form Builder should be installed to the correct place and stuff like that).
But I am not going to spend all my available time in fixing something that isn't broken, so this will be delayed for a while.
Just sugestions to make TGUI even better
Thanks for the input, I'll try to change all those things.
-
To my experience, dynamic_cast is not "the clean solution". It is often considered bad design among the C++ community ;)
Case differentiations with dynamic_cast, typeid or enumerators share one problem: They defeat polymorphism. Polymorphism intends to access objects of different types uniformly, internally they dispatch to different functionality using virtual functions. The user need not know what dynamic type an object has in order to perform operations on it. In addition, dynamic_cast may be rather slow depending on the class hierarchy and the RTTI implementation. Of course, it has its use cases, but one should look for alternatives when available.
Where appropriate, prefer virtual functions over dynamic_cast. Here, this is of course difficult, because you can't change the TGUI class hierarchy. Some time ago, I couldn't accept this limitation any longer and had to write dispatchers in Aurora (http://en.sfml-dev.org/forums/index.php?topic=7330) :)
aurora::SingleDispatcher (http://www.bromeon.ch/libraries/aurora/v1.0/doc/classaurora_1_1_single_dispatcher.html) extends virtual functions in order to work non-intrusively with existing class hierarchies. You can have functions or functors for different dynamic types, and register them at the dispatcher. When you invoke them without knowing the dynamic type, the correct function is looked up and invoked. Like this, you can cleanly separate different functionalities in their own functions, and do not need to perform an explicit case differentiation.
#include <Aurora/Dispatch/SingleDispatcher.hpp>
#include <Aurora/Tools/ForEach.hpp>
#include <iostream>
#include <vector>
#include <memory>
// Example class hierarchy
struct Widget { virtual ~Widget() {} };
struct Button : Widget {};
struct ListBox : Widget {};
// Your function for buttons
void MyFunction(Button& b)
{
std::cout << "MyFunction(Button&)\n";
}
// Your function for list boxes
void MyFunction(ListBox& l)
{
std::cout << "MyFunction(ListBox&)\n";
}
int main()
{
// Create dispatcher, register both functions
aurora::SingleDispatcher<Widget&> dispatcher;
dispatcher.add<Button>(&MyFunction);
dispatcher.add<ListBox>(&MyFunction);
// Create container of widgets
std::vector<std::unique_ptr<Widget>> widgets;
widgets.emplace_back(new Button);
widgets.emplace_back(new Button);
widgets.emplace_back(new ListBox);
// For each widget (VC++10 lacks range based for), invoke correct function
AURORA_FOREACH(std::unique_ptr<Widget>& w, widgets)
dispatcher.call(*w);
}
Output:
MyFunction(Button&)
MyFunction(Button&)
MyFunction(ListBox&)
-
To my experience, dynamic_cast is not "the clean solution". It is often considered bad design among the C++ community ;)
If they seen the sh*t that goes on in SFGUI and SFML.. :D
Singletons, reinterpret casts to void* and back, const casts, mutables, memset on a RenderWindow to hack into vertex and view cache. And it works great.
-
@Texus
As for that install script - you should just call make then sudo make install - this will install form builder to /usr/local/bin and libs and headers to proper locations. What's more, if you run this on distro which doesn't support /usr/local it will copy the files to proper location! So that's the best way imo.
@Nexus
That looks um... stunning, but to be honest I'm yet to see library which uses that solution to this problem. I think tgui is such a small project that such compilcated designs aren't needed. I may be wrong though. You know, KISS!
Also, if I understand correctly it won't solve tgui's problem. The class hierarchy is quite good and when you have virtual function like setsize etc everything goes okay. The problem is that the base object class can't have getTitlebarHeight functions which is only for child window and that's why polimorphism won't help here.
-
As for that install script - you should just call make then sudo make install
To do that you need a makefile. The whole idea from the install script was to provide an easy alternative to using cmake and makefiles. The install script was mainly added for people to lazy to download and setup cmake. Perhaps it would be better to just remove the install script instead of trying to optimize it.
-
You know - sfml on linux requires cmake (2.0 is not in repos) and tgui requires github sfml version, so that may be the best option. Because we can assume that if you have github sfml2 version, you have cmake installed.
-
The problem is that the base object class can't have getTitlebarHeight functions which is only for child window and that's why polimorphism won't help here.
But why would you need to call a specific function on an object that you don't store, that you need to find within the untyped children of a parent object?
The whole idea from the install script was to provide an easy alternative to using cmake and makefiles
CMake provides a unified and simple way to do things, especially on Linux. All you have to do is:
cd tgui
cmake .
make
sudo make install
Scripts may simplify things on Windows, but definitely not on Linux ;)
-
That looks um... stunning, but to be honest I'm yet to see library which uses that solution to this problem.
I know, you won't find most parts of Aurora anywhere else, that's why I have written this library. Also the principle of copyable smart pointers, which I meanwhile use all the time and which simplify my life a lot, is widely unknown in the C++ community. Interestingly, people prefer to rewrite the Big Three all the time and to use new/delete ;)
I think tgui is such a small project that such compilcated designs aren't needed. I may be wrong though. You know, KISS!
It wasn't a proposal to include this in TGUI, the problem occurs on client side anyway. I wanted to show an elegant alternative to explicit type differentiations. I am aware that in simple situations, a dynamic_cast can be the easier approach.
dynamic_cast becomes problematic when many classes are involved. The central case differentiation turns out to be a dependency bottleneck (all types have to be complete), and the order of the if/else if statements must be correct, and kept synchronous with the class hierarchy. In such a case, a more scalable solution might be worth while.
The problem is that the base object class can't have getTitlebarHeight functions
If I've understood correctly, the problem is rather that the user wants to call getTitlebarHeight(), but he only has a base object. That is, he must find out if this object is also a derived object.
-
If I've understood correctly, the problem is rather that the user wants to call getTitlebarHeight(), but he only has a base object. That is, he must find out if this object is also a derived object.
That's what I meant but my english is bad. The user has a pointer to basic object and wants to call function that only exist in child class. If base class had getTitlebarHeight() virtual function then there would be no problem. But of course it's impossible, so as you said we need to check type of the object that pointer shows on.
Thanks for explaination, now I see the purpose of your approach. I will remember it, maybe one day when I will be doing really big project it will be useful. However I think that we can agree that for current state of tgui, simple dynamic cast approach is enough (there aren't really that much classes in hierarchy).
edit:
A little off topic. You said about foreach loop in C++ 11. I love it from script languages and now I see that my g++ supports it :D C++11 is really great, I still don't know much of it, but every part that I know is so useful.
@Lauren
Well if I understand you correctly, that's what I need to do in TGUI. There parent class object and child class child window. I only have base class pointer and I need to find out if it's child window to call non-virtual function which only child window has.
-
I only have base class pointer and I need to find out if it's child window to call non-virtual function which only child window has.
But why are you in this situation? Can't you store/access the object directly with the correct type?
I use Qt all the time. Things are similar: it has a QObject base class, functions to get/find children, a custom metatype system, and a qobject_cast conversion function similar to dynamic_cast. But I never use this stuff. Objects that I need to manipulate are stored directly (often as members of their parent class), and I don't have to find and typecast them.
-
Well, because in tgui there isnt getAllObjects<Type>() (hmm Texus, what do you think about such a function?), but only getAllObjects() which gives pointers to base class. And I need to call for every child window function which keeps them in window, because there are some design problems with it and I must do it manually in my loop.
There are 2 solutions to avoid the whole problem:
1) Make child windows stay in window at global level (but currently it won't be done because there are some design problems, but I would just keep every child window inside main window and ignore panels for this)
2) Write function getAllObject<type>() which returns proper pointer for proper type (pointer to child class)
-
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.
-
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?
-
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.
-
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.
-
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).
-
For those who are interested, you can find the first development snapshot of v0.6 on the download page (http://tgui.weebly.com/download.html).
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Ok, I see now.
I'll make sure that functors get supported.
-
Is there a way for picture to send callbacks on click in 0.5?
-
Sure, just change its callbackID and it should start sending callbacks on click.
-
I followed the suggestions to improve the new callback system.
Here is what you can do with it now.
Because a boost::function is now accepted as parameter, you can of course do more.
void function1() {}
void function2(const tgui::Callback& callback) {}
struct myClass {
void function3() {};
void function4(const tgui::Callback& callback) {};
} myObj;
auto function5 = []() {};
auto function6 = [](const tgui::Callback& callback) {};
struct myFunctor {
void operator()() {}
} function7;
unsigned int trigger = tgui::Button::LeftMouseClicked;
button->bindCallback(function1, trigger);
button->bindCallbackEx(function2, trigger);
button->bindCallback(&myClass::function3, &myObj, trigger);
button->bindCallbackEx(&myClass::function4, &myObj, trigger);
button->bindCallback(function5, trigger);
button->bindCallbackEx(function6, trigger);
button->bindCallback(function7, trigger);
button->bindCallback(trigger); // just handle the callback the old way
-
Nice! You are doing very nice job!
I have a performance question regarding buttons. If button texture files are 256x256 and I set button's size to 32x32, the textures will be cut internally by TGUI for drawing, yes?
-
No, the setSize function doesn't cut the texture, it just scales it.
-
Okay. Anyway, is there a chance that clickable rectangle object will be added anytime soon? I think that it's just needed to remove some code from button and it would help me, as messing with transparent buttons isn't the clean way.
-
I wasn't really planning on adding them soon.
But it shouldn't be difficult to write it, so I'll see if I can get this done today.
-
I have a question. From source it seems that click callbacks are send on mouse release rather than on mouse down. Is there a way to have the callback on the press without waiting for release?
-
Only in tgui v0.6 is this possible without making any changes yourself.
If you want it in v0.5 then you will have to change the source code.
Just add the following lines to the leftMousePressed function of the object:
if (callbackID > 0)
{
Callback callback;
callback.object = this;
callback.callbackID = callbackID;
callback.trigger = Callback::mouseDown;
callback.mouseButton = sf::Mouse::Left;
callback.mouseX = x - getPosition().x;
callback.mouseY = y - getPosition().y;
m_Parent->addCallback(callback);
}
-
Thanks. If I add that code, do I need to remove callback code from leftMouseReleased?
-
That depends on what you want to do.
If you leave the code in leftMouseReleased then you will get 2 callbacks: one when the mouse went down and one when the mouse was released again. The callback.trigger is different, so you are perfectly able to distinguish the callbacks from each other.
If you only need callback on mouse down then you can remove the code.
-
Thank you, it works.
-
Just a question not related to my problem which I pm'ed you - when I have objects that I add to the panel, is there a way to set their position relatively to the tgui window instead of panel? That would be quite useful.
-
No, the whole idea of a Panel was to allow objects to be placed on a relative position instead of an absolute position on the window.
All you can do is subtract the panel's position from the object.
object->setPosition(sf::Vector2f(300, 200) - panel->getPosition());
-
That's enough, thanks. I need the windows coordinates because as you know I draw images with sfml and then I need them to be tgui clickable objects.
-
Is there a way to disallow user to click on checkbox? I mean I controll if it's checked/unchecked and the user can only see it and can't click on it.
EDIT:
Also, is there a way to have a group of checkboxes in which only one of them can be checked at once? It's quite important feature.
-
Radio buttons are for that. http://users.telenet.be/tgui-documentation/v0.5/structtgui_1_1RadioButton.html
-
I often see that feature on checkboxes as well. Also I need checkboxes for look.
But I think I can just copy the images, so that is no problem. But I still have 3 questions:
1) Is there a way to disallow user to click on checkbox? I mean I controll if it's checked/unchecked and the user can only see it and can't click on it.
2) I found a bug. Using check() on the radio button doesn't send callback. Why? It should send callbacks, there is no difference whether user or the code checked it, because there are some actions to do after its checked. Any fix?
3) Why there is no checked/unchecked callback trigger for checkbox? I really need it.
-
Only one radio button with the same parent can be checked at a time.
If you want to group them then you should take a look at the tutorial of Panel.
1) Call object->disable(). This will block all events from going to the object.
2) It seems like I placed the callback when you clicked on the checkbox instead of in the check function. I think I probably did this so that no callbacks would be triggered when you manually check the checkbox.
You can always adjust the source code to your needs and remove the callback code from leftMouseReleased and keyPressed and place it in the check and uncheck functions (in both CheckBox and RadioButton).
3) Any callback coming from the checkbox means that the state was changed in some way. So when you receive a callback you should just look at callback.checked. If it is true then it just got checked and if it is false then it just got unchecked.
v0.6 works with checked/unchecked triggers by the way. Too bad that the version is currently not stable enough.
-
Thanks for answers.
2) It seems like I placed the callback when you clicked on the checkbox instead of in the check function. I think I probably did this so that no callbacks would be triggered when you manually check the checkbox.
You can always adjust the source code to your needs and remove the callback code from leftMouseReleased and keyPressed and place it in the check and uncheck functions (in both CheckBox and RadioButton).
But I think that callback shouldn't be done that way by default. Callback isn't reaction for mouse movement done by user, rather it is reaction for checked/unchecked. From my experience with gui systems (not game ones), it doesn't matter if the user or the code uses it - the onWhatever() functiong gets called in both cases. I really think you should change it by default. There aren't many reason why you should separate code and user checks, it makes the code MUCH uglier. See, sometimes you check one chekbox and it automatically checks another checkbox - and why in this point the functions related to that checkboxes shouldn't be called?
From the callback handling code point of view it really shouldn't matter what is the reason why the checkbox is checked, when it's checked the callback handler should always be called.
The very simple example from wxWidgets - when you close the application from code, the onExit() function gets called even though the user didn't press the close button. The same applies to other callbacks as well.
I really think that the current way is counter-intuitive and you should change it. And if someone really needs to do it the other way (checking in code doesn't send callback), you can always have a default argument in check function (send callback = true). But to be honest, I'm yet to see an use for that in any well designed gui application (i've done some wxwidgets gui programming before).
It's not only my point of view - as I said other guis send callbacks even when it is triggered by code. I hope that I explained it well and you can see the point.
The another example is not related to gui but shows the idea too - for example when you have networking code and you have callbacks when receiving packets (ie enet library), it sends the callback even though the user of application doesn't have any control on it. The callbacks should be related to code, not to the user.
-
I fully agree with you. That's why v0.6 already does it in the exact way that you expect it.
But I am not really planning on changing v0.5 anymore unless it is to fix a real bug.
-
Oh, I didn't realise that in 0.6 it's fixed! That's great to hear!
Anyway, do you plan to include clickable object in 0.6 by default? It would be nice.
-
I'll do that (when I have more time).
-
How do you do communication between widgets in tgui? Do you use observer or publish-subscripe pattern? Or do it less fancy way?
-
There is an EventManager which holds a list of all objects. When you call the handleEvent function from the window then a function from all these objects is called (which function depends on the event).
So something like the observer pattern.
Objects themselves cannot communicate with each other directly because they don't know about each other.
They can only talk to their parent object.
-
For those who are interested, I have added precompiled libraries for MinGW 4.7 to the download page (http://tgui.weebly.com/download).
If you downloaded CodeBlocks 12.11 with MingGW, then you can use these libraries instead of having to compile them yourself.
Precompiled libraries for other compilers and versions will be added in the future.
Edit: Libraries for Visual Studio 2010 are also online now (untested).
-
I have a suggestion, but I think it would be rather long-term. Do you plan to add open and save file dialogs? Something like irrlicht's gui has. It doesn't have to be fancy, just basic features.
-
That is indeed on a long-term, but the FileTreeDialog is planned to be written eventually. But probably not in v0.6.
-
How can you make child window's title to be centered?
-
Currently, you can't.
But it's not such a bad idea to be able to do that.
EDIT: I will add it to v0.5.1, which will come in a week or two.
-
A new development snapshot is now available for v0.6.
Next to the new callback system it also includes the MenuBar object.
There still aren't tutorials for this version, but the documentation might be enough for some.
In the previous snapshot the form builder was left out (it didn't compile anymore). This has been solved by now.
I have also included precompiled libraries for those working with CodeBlocks 12.11 or Visual Studio 2010.
An example code for the menu bar:
tgui::MenuBar* menuBar = window.add<tgui::MenuBar>("myMenuBar");
menuBar->addMenu("File");
menuBar->addMenuItem("File", "Save");
menuBar->addMenuItem("File", "Load");
menuBar->addMenuItem("File", "Exit");
menuBar->addMenu("Edit");
menuBar->addMenuItem("Edit", "Undo");
menuBar->addMenuItem("Edit", "Redo");
menuBar->addMenu("View");
-
Very good job Texus.
i think is more easy for final user ( not you ;) ) to use simple image for customize the gui.
did you plan to include this feature ?
-
I am planning to do that in the future for ListBox, ComboBox and MenuBar (all others are already loaded with images).
But I wouldn't really know what images should be loadable. I still have to make dicisions about whether it should be just a background image or seperate images for all items.
For now you will just have to work with a simple background color for these objects.
-
Now that the callback system is finished, I plan to make another design change.
When getting the objects from the window you would only get pointers to the base classes. And because not all functions are available on that level you would have to cast the object to the correct type. Some time ago, this led to a little discussion on how to figure out what the type of the object is.
I want to propose a different design in my gui that will get rid of this problem.
Until now, the objects have always been stored inside the window. This had the great advantage of not having to store the objects on your own. You could let your pointer go out of scope and get it back from the window when you needed it. However, the window would not be able to distinguish the objects from each other and a cast was required.
What I want to ask is whether it is really necessary to give the window full control of the object?
It is nice that you don't have to store it yourself, but is this really needed?
Storing those objects isn't that much of a problem and you will be able to access the correct object when you need it (when you have a good design). So there will be no problem with casting because you decide where and how you store the objects.
If I make the change that I am planning then the following things will happen:
- You will be responsible for keeping the object alive (you may not let the pointer to it get out of scope)
- The get functions will most likely be removed from the window (or kept, but not intended to be used)
- The remove functions won't be needed either in most cases: just delete the object (if using a pointer to it).
- I will be able to simplify the add function so you no longer have to explicitly give the template type.
tl;dr Is it really necessary for the window to store the objects?
Might it not be better if you stored the objects yourself and keep full control of them?
EDIT: This change will make it impossible to copy groups of objects or to load objects from a file.
This will make my form builder obsolete unless I add a way to load single objects from a file.
-
I think that for simplicity and easy-to-use the window should keep to store widgets. What do you need to do is to have containers in the window for every type of widget. You can hard-code container for every type and make specialized templated version of get and add.
But if you want, there is a simpler solution (creating containers on the fly on runtime!). Look at this question on stackoverflow and the top answer (selected one). LINK: http://stackoverflow.com/questions/14781901/class-that-creates-new-containers-for-type-known-from-its-template-member-functi (http://stackoverflow.com/questions/14781901/class-that-creates-new-containers-for-type-known-from-its-template-member-functi)
I believe that would be the best. This way, if users calls add<tgui::one> the container is created and the next time it is there. If the user doesn't add object of this type, the container doesn't exist. The code is very simple and you don't have to hard code function for every type. What do you think?
Also, I don't know any gui lib which requires you to manually store the widgets. It's just so uncomfortable.
-
Thanks for the link, it looks interesting indeed.
I am currently looking to see how to implement a way with shared pointers which should solve this problem.
I guess I should take a look at how sfgui handles this exactly.
-
You can also have a look at Qt and wxWidgets.
-
Hello,
i'm using v0.6-dev and cant draw a label or sf::Text from a class.
When i put the code in my main.cpp, it works well.
Maybe a bug?
// Interface class
Interface(tgui::Window &Spiel)
{
// Ebene
tgui::Label* Ebene = Spiel.add<tgui::Label>("label");
Ebene->setText("Ebene 0");
Ebene->setPosition(360, 25);
Ebene->setTextColor(sf::Color::White);
Ebene->setTextSize(12);
}
Also doesn't work when i create tgui::Label* Ebene at my attributes, doesn't work when i call Spiel.drawGUI() in my drawmethod.. it doesnt draw sf::Text also anymore.
Any help would be nice.
-
If you can't draw sf::Text either then I don't think the problem will be with tgui.
Did you load a font?
I don't see anything wrong with that code, so if you are sure that you loaded the global font, could you provide a bit more code then?
-
When i use sf::RenderWindow instead of tgui::Window, i can draw sf::Text.
// Main.cpp
tgui::Window Spiel(sf::VideoMode(640, 500, 32), "Spiel", sf::Style::Close);
...
Spiel.globalFont.loadFromFile("Font/Seagram tfb.ttf");
...
// Textbox works well in main.cpp
tgui::TextBox* textbox = Spiel.add<tgui::TextBox>("textbox");
textbox->load(150, 100, 12, "graphics/Black");
textbox->setPosition(485, 320);
textbox->changeColors(sf::Color(193, 177, 140), sf::Color::Black, sf::Color::Black, sf::Color::Transparent);
textbox->setText("TEXT");
// When i insert my Label here, it works also
...
Spiel.clear();
Spiel.drawGUI();
Spiel.display();
// Interface class
Interface(tgui::Window &Spiel)
{
// Label Ebene doesn't work in class, but works in main.cpp
// sf::Text doesn't work anymore in a class
tgui::Label* Ebene = Spiel.add<tgui::Label>("label");
Ebene->setText("Ebene 0");
Ebene->setPosition(360, 25);
Ebene->setTextColor(sf::Color::White);
Ebene->setTextSize(12);
}
-
The following code works fine for me:
#include <TGUI/TGUI.hpp>
class Interface
{
public:
Interface(tgui::Window& window)
{
tgui::Label* Ebene = window.add<tgui::Label>("label");
Ebene->setText("Ebene 0");
Ebene->setPosition(360, 25);
Ebene->setTextColor(sf::Color::White);
Ebene->setTextSize(12);
}
};
int main()
{
tgui::Window window(sf::VideoMode(800, 600), "TGUI window");
window.globalFont.loadFromFile("TGUI/Fonts/DejaVuSans.ttf");
Interface i(window);
while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
window.handleEvent(event);
}
window.clear();
window.drawGUI();
window.display();
}
return 0;
}
Does the above code works for you?
Either you will have to add some code to this until it no longer works or start removing code from your own project until it works again. You will have to narrow the problem down because I can't help much if I can't reproduce the problem.
-
Doesn't work for me.
Testing around now, when i found on anything, i'll tell you.
-
If you answer these questions then I'll try to test it in the same environment as you (I currently only tested on linux).
What OS are you using?
Which compiler?
Do you use dynamic or static linking?
Here are a few things that you could still try:
- Don't use a class, but use a simple function (does it fails because it is in a class or because it isn't in main?)
- If you are using precompiled libraries, could you try rebuilding them yourself?
- I am not sure if this will have any influence, but do you have the latest drivers intalled?
- Try running the above code with v0.5. If that still doesn't work then at least I am sure that it isn't a bug in recent changes.
-
I need to display a lot of texts which will be visible only for a few second then disappear forever. I could do it manually but tgui labels are more handfull. But my question is, how can I delete (not just hide) the label?
-
window.remove(myLabel) should do the trick.
-
Thank you.
-
I need an editbox which will only accept numbers. Is there any way for it? Ie it doesn't register other keys than numbers.
-
I still have to write that feature.
You will have to do it manually for now:
- Catch the textChanged callback
- Check the callback.text for non-numeric symbols
- If a letter was found then erase it and use editBox->setText to set the new text
-
Okay. I think I will make new class numEditBox and put that feature there, so it will be nicer to use. And I will just add the files to my project as I do with clickable object to keep tgui sources unmodified.
-
Did you decide something about storing widgets? I hope that tgui will still store them as it's very handful. I think all you need is just simply having containers for every type of widget and you can do that painlessy without wiriting manual containers using the code I showed you (that would also make possible storing user created widgets, as it would just create new function with static container for that type).
-
I have ended up with using smart pointers. And the window will still store them.
Adding and retreiving items has been simplified without much loss of features.
The only broken thing that I found so far is that you won't be able to copy an object directly with it's name. You will first have to retreive the pointer that corresponds to that name and copy that pointer. I can live with that.
I am still testing everything though. This was a big change and at this point I can't guarantee that I didn't broke other features. So it might take a while before I put the changes online.
The big advantage of having this instable version is that I will have to write a lot of tests to make sure everything still works. This means that there will probably be more example codes available for v0.6.
-
No problem with no direct copying. You can always wrap it into one function. But, how smart pointers fixed the problem? Could you explain it and show me the code for adding and getting?
-
It is implemented that the pointers are automatically up- and downcasted. So even though you would receive a pointer to the base class, you can just store it in a pointer to e.g. an editbox and start using the functions from editbox.
The code to add an object to the window will become:
tgui::Picture::Ptr picture(window, "myPic");
The code to get it back from the window:
tgui::Picture::Ptr pic = window.get("myPic");
You will still need explicit casting when not storing the object but try to call a function on it immediately.
But doing so could be considered bad practice in the first place because the get function can return a null pointer.
static_cast<tgui::EditBox::Ptr>(window.get("edit"))->getText();
-
If I understand correctly, 0.6 will have something like signals and slots system? Something like qt.
-
It doesn't work exactly like that, but it is a signal like system.
With the bindCallback function you can bind any function to any of the callback trigger of the object (e.g. LeftMouseClicked).
If no function is passed to bindCallback then the signal will be send to the parent object. If it reaches the window then it can be polled from it just like in v0.5.
To group objects (e.g. Panel, ChildWindow) you can also use bindGlobalCallback.
If the objects inside the panel send a callback to their parent, then instead of passing the callback to the window,
the panel will send it to this global callback function.
You can bind multiple functions to the same callback trigger, all of the functions will be called.
-
Okay. But you can't create a signal which contains some argument? Like you can for example in boost::signals2, where your signal may cointain data which are given as argument to the slot.
-
There are two functions that can be bound by default.
The first one doesn't has a parameter and the other one has a "const tgui::Callback&" parameter.
But one of the bindCallback functions accepts a boost::function, which means you should be able to bind anything.
The following will give you a function that takes a pointer to an integer when the function is called.
You will have to use pointer because the variable itself cannot be changed after it is bound.
Note that you don't have to include boost. The function and bind parts are included with tgui. (std::bind also works)
void func(int *i)
{
std::cout << *i << std::endl; // Will print '3' when the picture is clicked
}
int *i = new int(5);
tgui::Picture::Ptr picture(window);
picture->load("Linux.jpg");
picture->bindCallback(boost::bind(func, i), tgui::Picture::LeftMouseClicked);
*i = 3;
-
It's gonna be amazing, I can't wait for 0.6 stable. Great job.
-
You will have to use pointer because the variable itself cannot be changed after it is bound.
You should be able to avoid that with std/boost::ref (which wraps a reference to a variable -- so even if the std::ref instance itself is copied, it's still the original wrapped variable which is passed to the function).
void func(int i)
{
std::cout << i << std::endl; // Will print '3' when the picture is clicked
}
int i = 5;
tgui::Picture::Ptr picture(window);
picture->load("Linux.jpg");
picture->bindCallback(boost::bind(func, boost::ref(i)), tgui::Picture::LeftMouseClicked);
i = 3;
Just be careful about the scope of the referenced variable.
-
Thanks, thats nice to know.
-
I've been using this for the past few days, I rather like it. Nicely done texus.
Is there any possibility of adding an outline around text?
-
Is there a canvas object so for example I could have multiple canvases with their own relative positions, mouse events relative inside the canvas and have it clip drawing in the canvas?
I'm working on a game and I think a GUI library would be very beneficial.
-
Imagine a situaton.
class a
{
void foo()
{}
}
a obj;
tguiObj widget->bind(&obj.foo()) //the syntax is wrong but you get the point, I bind the obj function to callback
//obj gets deleted here
//here is the callback function called, undefined behaviour (segfault mostly and/or memory corruption)
Qt signals check if the slots exist. How will tgui deal with it?
-
Is there any possibility of adding an outline around text?
Label is just a simple wrapper around sf::Text. Except for a background color it doesn't add anything.
Is there a canvas object so for example I could have multiple canvases with their own relative positions, mouse events relative inside the canvas and have it clip drawing in the canvas?
Yes, the Panel object.
How will tgui deal with it?
It doesn't :).
Definately undefined behaviour.
I never though about this kind of situation before, so I'll see what I can come up with.
-
I'm really diggin' TGUI 0.5. I got it compiled and am playing with the example code.
But one caveat I've noticed is that when window.close() is called, the program crashes with an object memory error.
-
I never had any crashes with that version.
What code are u using exactly to make it crash?
Does the crash really occur on the window.close call, or somewhere later?
Could you try the following for me?
- Create less objects (maybe the crash only occured when creating one specific kind of object)
- Try putting the event loop at the end of the main loop, so that the draw function isn't called after closing the window.
-
This is the exact code that crashes on exit:
http://tgui.weebly.com/tgui-v05.html
I can post the exact error log when I get on my computer.
-
1) What says your debugger call stack?
2) Do you use latest SFML 2 snapshot?
3) By any chance, maybe you use precompiled tgui/sfml for another version of mingw/g++/vc++? Try recompiling.
4) Are you sure that there is no additional code in your project? Or maybe you dynamically link other library which causes this problem? Some libs just doesn't like dynamic linking for various reasons. Try linking only sfml + tgui, both static. (however for sure SFML2 doesn't have any problem with dynamic linking. I don't know with tgui though)
-
(1)
Test(8292,0xac56fa28) malloc: *** error for object 0x2ae988: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
(2) I believe it is.
(3) Compiled it myself for C++11 and 10.7+.
(4) No additional code.
Everything works fine. Just when I try to close the window, it gets mad.
-
It hasn't been tested on mac for a long time, but I see no reason why it would crash on a mac while it works on linux and windows. I'll try to test it on a mac somewhere this month though.
Compiled it myself for C++11 and 10.7+.
You probably did, but make sure that sfml and tgui are compiled in exactly the same way, with the same build flags.
But could you still try to move the event loop to the end of the main loop and to create less objects?
This might be stupid, but does it make a difference when using the BabyBlue style instead of the Black style?
-
I just finished with a new object: ChatBox.
(http://i1119.photobucket.com/albums/k625/texuz/TGUI/TGUIChatBox_zps2c33a12d.png)
It will be included with the next v0.6 preview.
But if you are using v0.5 then you can already start using it immediately if you want to. You can download the extention here (https://www.dropbox.com/s/awatq2gw39zvll4/tgui%20v0.5.1%20%2B%20ChatBox%20upgrade.zip).
-
Great ! i use your lib when the doc & example of 0.6 was done ;)
-
How do I draw to a panel?
Like, I'm making an app that has 3 views in the same window. Each view has it's own controller, I just made those controllers have a panel as the view and now I'm wondering...
How do you draw to the background of the panel?
panel->draw(myPolygon); doesn't work.
Edit:
panel = window->add<tgui::Panel>("DesignerGrid"); Throws a bad exec access error.
Perhaps I'm doing it wrong...
-
You can't draw directly to a panel. Because every object has to be drawable (including Panel), they all have a draw function. If I remember correctly then adding another draw function to draw on top of the panel would give ambigious calls in some situations. I'll look at it again, but if what I remeber is correct then I can't add the possibility easily.
Creating the panel shouldn't be a problem.
The following code works fine for me.
tgui::Window window(sf::VideoMode(800, 600), "TGUI window");
tgui::Panel* panel = window.add<tgui::Panel>();
-
Oh.
Is there a way to set the background texture of a panel? And just draw to the background texture?
It sure would be nice to not have to draw directly to the window.
-
I didn't have much time this morning so I forgot to add that to my reply.
There is a setBackgroundImage function in Panel which takes a filename as parameter.
-
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?
-
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.
-
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.
-
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.
-
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 ;)
-
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.
-
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.
-
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!
void Panel::setBackgroundTexture(sf::RenderTexture* t)
-
Take a const sf::Texture&, not a sf::RenderTexture*.
-
Right now to draw it I have it make a sprite with the texture then draw the sprite. On every draw.
Is that slow?
-
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.
-
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.
-
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.
-
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.
-
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.
-
These errors mean that you have to link to opengl (by adding "-lGL" to your linker options.
I guess I should update the tutorial. Last time I tested the libraries I didn't have any problems, but it might have been before I started using opengl code.
-
You can't draw directly to a panel. Because every object has to be drawable (including Panel), they all have a draw function. If I remember correctly then adding another draw function to draw on top of the panel would give ambigious calls in some situations. I'll look at it again, but if what I remeber is correct then I can't add the possibility easily.
Creating the panel shouldn't be a problem.
The following code works fine for me.
tgui::Window window(sf::VideoMode(800, 600), "TGUI window");
tgui::Panel* panel = window.add<tgui::Panel>();
I can't create a panel in 1.5. Your 1.5 example works but adding panel creation causes a crash. (I tested with a clean version of your library)
Edit:
1.6 doesn't crash, but no panel shows on screen. This code:
tgui::Panel* panel = window.add<tgui::Panel>();
panel->setPosition(100, 100);
panel->setSize(100, 100);
panel->setBackgroundColor(sf::Color::Red);
Edit 2:
Got the panel to show with this code:
tgui::Panel* panel = window.add<tgui::Panel>();
panel->load(500, 500);
panel->setPosition(100, 100);
panel->setBackgroundColor(sf::Color::Red);
Edit 3:
I just skewered the 1.6 code. Tossed the background code and added the setBackgroundTexture function. Also ruined the ChildWindow cause apparently that uses a lot of the panel code. Good thing I won't need that yet...
Edit 4:
Strangest thing, I can create a panel using the altered 1.6 code in an example program. But it crashes when I do the same code in my other application. Hmmmm. Crash line:
m_EventManager.m_Objects.push_back(newObject);
With and exc_bad_access. Maybe I deleted something that shouldn't have been deleted.
Edit 5:
It may not be my changes that are making it crash. I decided to add a label instead of a panel, this code causes it to crash:
tgui::Label* labelUsername = window->add<tgui::Label>();
labelUsername->setText("Username:");
labelUsername->setPosition(200, 100);
Edit 6:
;D Nevermind. I was using the window object before I set it.
-
How do I use 1.6 callbacks?
I noticed this code:
panel->bindCallback(<#boost::function<void ()> func#>, <#unsigned int trigger#>);But where are the triggers defined?
-
I'm glad that the panel problems are solved then.
The triggers are defined inside the objects, so they are spread over multiple places.
Every layer has it's own triggers. An example:
- Object has Focused, Unfocused, MouseLeft, MouseEntered triggers.
- ClickableObject has LeftMouseDown, LeftMousePressed and LeftMouseClicked.
- Button adds SpaceKeyPressed and EnterKeyPressed.
So when using a button, you can use all of the above callback triggers. You don't need to know where they are exactly to use them. Just use tgui::Button::LeftMouseClicked to access the trigger.
Be aware that the triggers I gave above are not correct. The triggers are named slightly different in the current downloadable version so you will have to take a look in the header files for now.
Hopefully this will get easier once I finish the documentation.
And it's version 0.6 by the way, not 1.6 :)
-
Sweet, got the callback working.
Though how do I get the mouseX and mouseY in the panel?
panel->bindCallback(boost::bind(&DesignerGrid::mouseDown, this), tgui::Panel::MouseLeft);
...
void DesignerGrid::mouseDown() {
//int x, int y ?
}
Edit:
Actually even though it is binded, mouseDown isn't being called.
Edit 2:
I might not have the latest 0.6, I'll download it
Edit 3:
Had the feb 3rd version, downloading the Feb 8 version now.
Edit 4:
Is the TGUI master branch 0.6?
I can't seem to find any of the callback functions in the Panel header file.
-
Currently the downloads are a bit of a mess.
The master branch is still v0.5, the v0.6 is not on github yet.
So the version from 3 february on my site was the latest version.
For your problem: MouseLeft is not LeftMouseClick. Your callback function is going to be called when the mouse leaves the panel, not when you click it. In fact there isn't any way to check if the panel was clicked yet, you'll have to make the objects inside of the panel tell you that they were clicked.
I am going to try to get everything online this weekend, including the fixes to your problems.
I'll make Panel and ChildWindow work with background textures and add a callback to the panel when it is clicked.
If you have a callback and you want to find out the mouse position then you'll need to add a parameter to your callback function.
void mouseDown(const Callback& callback) {
// Only do the following when the callback has something to do with the mouse (check callback.trigger).
// On e.g. a key press, these values will contain nonsense.
int x = callback.mouse.x;
int y = callback.mouse.y;
}
-
;D So excited.
I'll route click and mouse events from the window for now, until you release the next version of awesomeness.
-
What are changes between 0.5 and 0.5.1?
-
- Added support for changing the title alignment in ChildWindow.
- Fixed a minor bug with unfocusing objects.
- Fixed a small bug in the CMake script.
-
The next development version of v0.6 has arrived (with the smart pointers and other improvements).
This will be the last time I'll announce a new snapshot as from now on you can find the latest version (https://github.com/texus/TGUI/archive/master.zip) on github.
So the master branch is now v0.6 (and v0.5 has been moved to it's own branch).
I haven't had enough time to really test all those changes, but it compiles and the simple example codes work so there shouldn't be too much problems. If you do find bugs then let me know and I'll try to fix them asap.
There still aren't many tutorials for this version, but I have already finished the installation and introduction tutorials.
For the rest you can look at the documentation (http://tgui.eu/dcmtn/v0.6/) and changelog (http://tgui.weebly.com/changelog.html).
The download also includes a few example codes to get the basics working.
-
if i want use the tgui source directly in my code , i must add definition in cmake for no error :
add_definitions(-DSFML_STATIC)
but, is not true. i use sfml with dynamic link.
-
What error are you talking about exactly?
Just a wild guess, but try to add -Dtgui_EXPORTS instead.
-
C:\Users\JEROME\Desktop\Paint\src\TGUI\AnimatedButton.cpp:38:5: attention : 'tgu
i::AnimatedButton::AnimatedButton()' redeclared without dllimport attribute: pre
vious dllimport ignored [-Wattributes]
C:\Users\JEROME\Desktop\Paint\src\TGUI\AnimatedButton.cpp:52:5: attention : 'tgu
i::AnimatedButton::AnimatedButton(const tgui::AnimatedButton&)' redeclared witho
ut dllimport attribute: previous dllimport ignored [-Wattributes]
C:\Users\JEROME\Desktop\Paint\src\TGUI\AnimatedButton.cpp:101:5: attention : 'vi
rtual tgui::AnimatedButton::~AnimatedButton()' redeclared without dllimport attr
ibute: previous dllimport ignored [-Wattributes]
C:\Users\JEROME\Desktop\Paint\src\TGUI\AnimatedButton.cpp:132:21: attention : 't
gui::AnimatedButton& tgui::AnimatedButton::operator=(const tgui::AnimatedButton&
)' redeclared without dllimport attribute: previous dllimport ignored [-Wattribu
tes]
C:\Users\JEROME\Desktop\Paint\src\TGUI\AnimatedButton.cpp:164:21: attention : 'v
irtual tgui::AnimatedButton* tgui::AnimatedButton::clone()' redeclared without d
llimport attribute: previous dllimport ignored [-Wattributes]
C:\Users\JEROME\Desktop\Paint\src\TGUI\AnimatedButton.cpp:171:10: attention : 'v
irtual bool tgui::AnimatedButton::load(const string&)' redeclared without dllimp
ort attribute: previous dllimport ignored [-Wattributes]
C:\Users\JEROME\Desktop\Paint\src\TGUI\AnimatedButton.cpp:518:10: attention : 'v
irtual void tgui::AnimatedButton::setSize(float, float)' redeclared without dlli
mport attribute: previous dllimport ignored [-Wattributes]
C:\Users\JEROME\Desktop\Paint\src\TGUI\AnimatedButton.cpp:535:17: attention : 'v
irtual std::string tgui::AnimatedButton::getLoadedPathname() const' redeclared w
ithout dllimport attribute: previous dllimport ignored [-Wattributes]
C:\Users\JEROME\Desktop\Paint\src\TGUI\AnimatedButton.cpp:542:10: attention : 'v
irtual void tgui::AnimatedButton::setText(const sf::String&)' redeclared without
dllimport attribute after being referenced with dll linkage [enabled by default
]
Work fine with -Dtgui_EXPORTS
Very great job ! i waiting for single bitmap for customize the gui :P
-
there is a mistake on the doxygen for childWindow :
virtual bool load (float width, float height, const sf::Color &backgroundColor, const std::string &pathname)
The std::string is the first parameter , not the last.
-
Those errors are indeed what you get with the combination of windows + dynamic linking + using source code directly.
Change any of those three things (or define tgui_EXPORTS) and you won't have any problems.
If you are waiting for me to add the feature of customizing with a single bitmap then you're going to wait for a long time. It's not planned anywhere soon.
The documentation is indeed wrong, I guess I uploaded a slightly outdated documentation (the parameter changed yesterday). I'll fix that in a few minutes.
-
If you are waiting for me to add the feature of customizing with a single bitmap then you're going to wait for a long time. It's not planned anywhere soon.
Is more easy for artist to make single image.
edit :
how can i change text color of ChildWindow ?
-
Yes I am aware that it would be better if I would support a single bitmap, but I have a lot of other things to do that are also important. So I doubt that it will get supported in v0.6. But maybe it will get into v0.7 one day.
Apparently you can't change the title color. I'll add the possibility in the next few days (I first have to make a small internal change in ChildWindow).
-
ok, i've created a child window with slider inside ( v0.6 ) , when i want to use (move) the slider , the child window move at the same time. it's big problem , the move of child window must be activated when the mouse is inside the titlebar , no ?
sry for my english. correct me if i make mistake ;)
Edit:
I find bug with child window and close button:
- Open Child Window
- place mouse over close button ( hover button appear )
- click on the button ( don't release mouse button )
- go outside close button
- release mouse button ( ChildWindow still open )
- go over close button with the cursor
- the image is Down.png not Hover.png !
-
The close button is just a minor bug, but the one with the slider is indeed a serious issue.
I'll look into this. Hopefully I can find the cause and fix this quickly.
-
Both bugs are fixed now.
-
adding two methods for change and get title color :
ChildWindow.cpp
http://pastebin.com/nwfesFHB
ChildWindow.hpp
http://pastebin.com/auzbf1D2
i see for adding icon on the title bar now.
-
Well don't waste too much of your time to get that done.
It would be nice if you could write it, but I know my own code better so I can get it written against tomorrow (or even in a few hours).
EDIT: Done
-
Do you plan on improving sprite sheet and picture performance in 0.6? As I encountered bad performance with many pictures in 0.5 and had to fallback to use sfml for rendering + clickable object.
Also, did you think about scrolling ability and tabs for panels and childwindows?
-
Do you plan on improving sprite sheet and picture performance in 0.6?
The problem is that there isn't much more to improve.
If you look at the draw function in Picture then you'll see it hardly contains any code. Of course I can cache some values but I'm not sure if it will make a huge difference.
However if I stop deriving objects from sf::Drawable then I might be able to get the draw function down to a single line.
So I'll think about this.
Also, did you think about scrolling ability and tabs for panels and childwindows?
This is basically combining two existing objects. Create a panel, add a scrollbar to it on the correct location and move your other objects when the scrollbar sends a callback (you can easily do this by using getObjects and then check if the pointer differs from callback.object before calling setPosition on it).
And using the Tab object with a panel shouldn't be too hard either.
I am not going to spend much time in it at this point. It might be interesting for the future, but I don't think it should get high priority right now.
-
I am new to a lot of things regarding this, not the least open source projects and their forums, make files and even c++ to some degree but i'm having some trouble and i hope i'm not embarrasing myself too much by posting my request for help here! :)
I wanted to create a music player, and so i found SFML and it worked well! thus i became in need of gui elements and i found TGUI! The installation instructions were clear and after some trouble of my own cause i finally got to the point at which i am now. I have used the newest version of SFML and TGUI 0.6 release candidates ( i also tried TGUI 0.5.2 but with same problem).
I used Cmake to create the visual studio project as specified, i opened the visual studio project and attempted to build it but i get 55 errors. Some of which i'll write here, the last numbers of each error is the line number:
IntelliSense: expression must have pointer type b:\TGUI v0.6\src\TGUI\TextBox.cpp 2309
error C2440: 'return' : cannot convert from 'const sf::Font' to 'const sf::Font *' B:\TGUI v0.6\src\TGUI\Label.cpp 109
error C2232: '->sf::Font::getKerning' : left operand has 'class' type, use '.' B:\TGUI v0.6\src\TGUI\EditBox.cpp 1654
error C2065: 'Unknown' : undeclared identifier B:\TGUI v0.6\src\TGUI\EventManager.cpp 170
error C2039: 'BackSpace' : is not a member of 'sf::Keyboard' B:\TGUI v0.6\src\TGUI\EditBox.cpp 1099
I am certain that the errors upon me are of my own doing, but if anyone could offer some guidance of what could be to blame and how to solve my problems it would be awesome!!
Thanks
Jacob Jensen
-
It seems like you are using an older version of sfml.
All the errors are about things that were changed in sfml over the last few months.
You will have to download and compile the latest sfml snapshot in order to tgui.
EDIT: Maybe even better: download the nighly build (http://en.sfml-dev.org/forums/index.php?topic=9513.0)
-
I was already using the 2.0 release candidate but getting the nightly build worked :)
EDIT: I'm getting two new error now tho!
error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj) B:\TGUI v0.6\build\src\TGUI\FormBuilder\msvcrtd.lib(ti_inst.obj)
error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMTD.lib(typinfo.obj) B:\TGUI v0.6\build\src\TGUI\FormBuilder\msvcrtd.lib(ti_inst.obj)
So these are linker errors to what looks to me to some standard library for visual c++ by microsoft, when i went looking for the library file it wasn't in the folder listed in the error. I'm not profficient with linker errors yet and it's probably some silly mistake by me, but what could be causing this? i am using latest snapshop for both tgui and sfml.
EDIT2: I realized that the snapshots might not be debug versions so i tried compiling it as release, but i got two almost identical errors but with linker errors from LIBCMT.lib instead of msvcrtd.lib
-
Are u using the sfml libraries in the static-std folder from the nightly build?
Did you compile tgui with the TGUI_USE_STATIC_STD_LIBS option checked?
All I can think of is that you are using the wrong combination of libraries.
Try not using the libs from the static-std folder and uncheck the option from tgui.
I just realized that the static std libs won't work if you follow the tgui compilation tutorial line by line (at least not when you didn't compile sfml yourself).
-
Unchecking static fixed it! naturally explains the linker errors! Thank you :)
-
How stable is 0.6 now? I'd like to start porting my game to 0.6 and I can live with few api changes in the future, altough if it can still change rapidly then I'd stay with 0.5.
-
I think it is stable enough now.
There won't be many changes soon anyway because I don't have time for it.
There are still some serious changes that I have to make in v0.6, but these will come when I have more time (somewhere end June perhaps). But the most visible changes (callback and object creation) have already been finished.
-
Do you plan on writing some tutorial on the new callback system?
If not, could you write me very short guide of the new features?
The 0.6 tutorial only says about old callback id method and I'd like to bind functions, but I'm not quite sure how to do it as you once wrote many different ways of using it and it seemed quite complex.
-
I'm going to write the tutorials when I have more time. Currently all tasks are postponed to July.
There are different bind functions because you should be able to bind any kind of function.
If you just want a function to be called when something happens then it isn't hard.
void function() {}
button->bindCallback(function, tgui::Button::LeftMouseClicked); // Triggers can be combined with '|'
But if you want a function that is called for different objects (e.g. one callback function for every state in the game) then you'll need some information in the function to figure out who send the callback.
void function(const tgui::Callback& callback) { /* callback.callbackId == 3 */ }
button->setCallbackId(3);
button->bindCallbackEx(function, tgui::Button::LeftMousePressed);
But this only works for normal functions and not for member functions in classes.
I've already written in an older post (http://en.sfml-dev.org/forums/index.php?topic=7023.msg69969#msg69969) how to bind these functions.
The bigger problem is to find the available triggers as they are not yet documented.
You'll have to go through the include files (can be found in the documentation (http://tgui.eu/dcmtn/v0.6/files.html)).
But they are not listed in one place. For Button, look at ButtonCallbacks in Button.hpp, ClickableObjectCallbacks in ClickableObject.hpp and ObjectCallbacks in Object.hpp.
But don't despair, most objects follow the same inheritance and if you look at e.g. the ButtonCallbacks then you'll immediately see that it isn't hard to figure out where else to look.
-
Okay thanks. If in bindCallback I combine some triggers, it acts as AND (ie callback is send only if all triggers are true) or like OR (so only one of the triggers has to happen)?
Also:
void function(const tgui::Callback& callback) { /* callback.callbackId == 3 */ }
button->setCallbackId(3);
button->bindCallbackEx(function, tgui::Button::LeftMousePressed);
Really there is no way to bind class member function? That would match perfectly as handleEvents() function in my gui class... (I have a few game states and every state has its own gui object, which basically wraps tgui and I only call handleEvents() and draw() basically but right now callbacks are messed up so I need to fix it, ie use BindCallbackEx to class member function).
Thanks!
-
Okay thanks. If in bindCallback I combine some triggers, it acts as AND (ie callback is send only if all triggers are true) or like OR (so only one of the triggers has to happen)?
It acts like an OR.
Really there is no way to bind class member function?
I meant that the above example didn't work for member functions, not that it wasn't possible at all.
In the post I linked to you can find how to bind to a member function.
struct myClass {
void function3() {};
void function4(const tgui::Callback& callback) {};
} myObj;
button->bindCallback(&myClass::function3, &myObj, trigger);
button->bindCallbackEx(&myClass::function4, &myObj, trigger);
-
Thanks for quick reply, finally my gui class is very transparent and easy to develop :)
-
1) I'm slowly switching to 0.6 and I'm not quite sure about ptr naming - once it is tgui::Button::Ptr and the other time it is SharedObjectPtr< Object > so I'm not sure what should I use... Why it's not tgui::Object::Ptr? It's very inconsistent and confusing. It should be consistent I think.
2) Also, as I don't know what should be proper names, how should I change this code to make it work with 0.6?
void correctChildWindow(tgui::SharedObjectPtr<ChildWindow> childWindow); //just a declaration
void checkChildWindows()
{
std::vector<tgui::SharedObjectPtr<Object>> &objects = tgui.getObjects();
for (auto &i : objects)
{
if (tgui::SharedObjectPtr<ChildWindow> childWindow = dynamic_cast<tgui::SharedObjectPtr<ChildWindow>> (i))
correctChildWindow(childWindow);
}
}
3) Another question, is there some tgui built-in way of doing this planned for 0.6 or I still have to use that very slow performing dynamic cast method to make sure child windows are inside the window?
Thanks!
-
I had some problems with objects required each other to be included already. By writing tgui::SharedObjectPtr<Object>, the Object class didn't already have to exist, while with tgui::Object::Ptr the Object class had to be defined already which wasn't possible.
Due to this the documentation might indeed by inconsistent at the moment, but both mean the exact same thing. I'll look at it again and see if I can fix this (when I wrote it I was too happy that it finally compiled, so I didn't bother much about this inconsistency).
Your code could be like this:
void correctChildWindow(tgui::ChildWindow::Ptr childWindow); //just a declaration
void checkChildWindows()
{
std::vector<tgui::Object::Ptr> &objects = tgui.getObjects();
for (auto &i : objects)
{
if (i->getObjectType() == tgui::Type_ChildWindow)
correctChildWindow(childWindow);
}
}
You'll see that tgui::Object::Ptr is converted automatically to tgui::ChildWindow::Ptr, however you'll still have to make sure that it is in fact a child window and there will still be a cast internally.
And I still don't know any way to make this easier.
-
Thank you, very quick response as always!
-
How is global font handled in 0.6? Does it even exist?
If yes, what happens when I try to display some label without setting the font?
If no, what happens when I try to display some label without setting its font? Is it undefined behaviour or it is fail-safe and nothing gets displayed?
-
How is global font handled in 0.6?
The only difference with v0.5 that I remember is that it is no longer accessible directly, you should use the setGlobalFont function (which takes either a font to copy or a filename to load the font).
what happens when I try to display some label without setting the font?
The same as what happens when drawing an sf::Text without setting a font. The text won't be drawn.
-
In 0.5 I could:
window.get<tgui::Panel>("leftPanel")->setSize();
However in 0.6 this obviously doesn't work:
window.get("leftPanel")->setSize();
//error: class tgui::Object has no member named setSize
What should be the preferred solution? Do I have to make tgui::DesiredObj::Ptr variable for such usage or there is some better solution? Coz I don't like unnecesary temporary variables.
-
This should do:
tgui::Panel::Ptr(window.get("leftPanel"))->setSize(...);
-
Thank you. I think I know what you could improve for easier usage.
tgui::Panel::Ptr leftPanel = window.get("leftPanel");
tgui::ClickableObject::Ptr tileButton(*leftPanel, "tileButton"); //it should accept pointer too
Object constructor accepts its parent by reference, which is good for window but with panel you rather work with pointers. It should be overloaded to accept pointers too.
-
The reason why it isn't possible is because it has a different meaning.
tgui::ClickableObject::Ptr object(panel);
already exists and just gives a downcast of a Panel::Ptr to a ClickableObject::Ptr.
It will work when I decide to force you to pass an object name, but I'm not going to make that decision right now.
-
Is there an automatic way to remove all objects of one type or I have to manually loop over all my objects?
-
You have to do it manually.
There will not be a way to do this because then the window would have to distinct between the different objects.
An alternative to looping over all objects would be to store the pointers to the objects yourself and then just call window.remove(...) with those pointers as parameter to that remove function.
But even this would mean looping over several objects.
-
Form has now been merged into Window.
If you were using tgui:Window then nothing should have changed.
If you were using tgui::Form and you decide to update to the newer version then you'll have to change 2 things:
- "tgui::Form gui(sfmlWindow);" changes into "tgui::Window gui(sfmlWindow);"
- The draw function is now called drawGUI
-
That window change makes it somewhere easier. If you look for example at Irrlicht, they also have gui merged with render.
I think there is some incosistency. Currently it is:
obj->setCallbackId();
callback.callbackID;
First, there is 'd' and 'D' difference. Second, double callback is kinda unnecesarry. It should be:
obj->setCallbackId(); //so it stays as it is
tgui::Callback callback;
callback.Id; //the same case as in set function and it makes much more sense
You dont use vector2u.vector2uX, do you?
-
I had already spotted the D in callbackID, thus it has already been changed in the latest version.
callbackId could indeed become id, but without the capital letter. Functions and variables are in camelCase notation, so if I would make it start with a capital letter I would really have inconsistency.
And I don't use Vector2 because it isn't possible in a union. Although I am already considering to just drop the union as it isn't really needed.
-
Yea callback.id seems fine to me. And as for the vector2 example, I didn't mean it. I just wanted to show that object.objectId is unnecessary.
Btw, objects in panel use relative positions to the panel yes? Because I think I have something messed up in my code.
-
Btw, objects in panel use relative positions to the panel yes?
Yes
-
Newest github version doesnt compile because of form builder using old callbackId. I need to compile new version as for some reason when I updated recently tgui callbacks stopped to work (or maybe poll callback function) so I want to update to see if it helps.
-
I sometimes forget to test the form builder after making changes.
It has been fixed now.
-
Thanks.
Also, I report a bug.
If I'm correct, tgui::Window no longer derives from sfml::RenderWindow. This is a big problem, because now I can't treat tgui window the same as sfml window and it causes unnecesary problems. Now this code doesn't work:
tgui::Window window(...);
sf::Mouse::getPosition(window); //it used to work because tgui::Window derived from sf::RenderWindow
I doubt that it's my fault that my code no longer compiles as I didn't touch that part of my code for some time.
EDIT:
I know what you wanted to achieve with one object which can be either window or just form, however this broke some things up. tgui::Window must derive from sf::RenderWindow as there are functions which take RenderWindow argument.
Please, revert it. It completely broke my engine and there are good reasons to make tgui::Window the same as sf::RenderWindow as it used to be.
-
I didn't saw that one coming when removing the inheritance.
I'm not going to revert the change, so you'll have to split tgui::Window and sf::RenderWindow. Check the tutorial (http://tgui.eu/tutorials/v06/intro1/) in the "Alternative usage" section.
You can either split them completely or just keep doing everything with the tgui window, but in the sf::Mouse::getPosition you will have to use the sfml window.
-
That's a sad news you don't want to revert it. Few days ago when you said that you rather want to get rid of tgui::Form I rewrited many parts of my engine (and like 300 calls in my app) to use single tgui::Window for everything.
Well, seems like I need to rewrite it yet again to separate tgui and sfml.
Don't you think that tgui::Window is now somewhat broken as it can't behave like sf::RenderWindow?
One is forced to use separate sf::RenderWindow unless doing some very basic tasks with sfml. I think mouse input is quite important and widely used.
There should be both form and window, it was much much easier and better designed as we see in the long run. I didn't thought that removing tgui::Form wil remove inheritance.
-
Would it help if I would just add a getMousePosition function to tgui::Window or are there more problems than that function?
Actually the functions in tgui::Window are only provided for simple usage, because in the future you might even be forced to split the windows (although I'll try not to do that as long as possible). A while ago I was told that I shouldn't inherit from sf::RenderWindow and I dissagreed but I added tgui::Form for those people. However now I know that keeping the inheritance will give me some limitations that I rather don't have. That is why I decided that tgui::Window should be more like tgui::Form was.
-
Besides our discussion, do callbacks by id (ie 0.5 way) work for you on the newest snapshot? Because with the newest snapshot they stopped working for me and I doubt I changed something in code... I could accidentaly change something but I'm not sure. I just set callback.id for radiobutton and it never gets called.
EDIT:
Nevermind, I forgot that for id based callbacks I also need to use bind function in 0.6. It's working.
-
@texus
First of all - many thanks for this library, this is the best-looking GUI for the sfml I have found. I'm currently making some tower defence game and it really helped me.
Ok, but that's not why I'm writing this post. I found some issues, and I decided to write them down inhere.
So, your library has problems with the inherited functions, for example in Label, when you use setOrigin method, it does not set the origin, but instead of that it moves the text in label so that the origin you have set is in the top-left corner (I'm assuming it happens in every other GUI element, but I haven't checked that). Maybe a picture will show it in the better way:
(http://i.imgur.com/YusYtCw.png)
Also, in the loading bar, when you use setText method it works well, but when you move loading bar (setPostition method), it does not move the text, but only the loading bar, and the text is not show when it's out of bounds.
I have one question too: when you will release the next version? I'm asking because on your site you have written:
WARNING: I am depreciating the above code because it will no longer work in the future. Read the alternative usage to find out how you should use tgui::Window. If you use the method below then you will only need minor changes when I effectively make the planned design change.
But it doesn't work right now.
Regards :)
PS
Sorry for my English, I hope you understand all.
-
setOrigin does indeed do some harm in objects where clipping is aplied. The inheritance will be removed in the future so that this will be solved. But this means that you can't use the setOrigin function for now.
TGUI v0.6 is far from being ready so it might still take a while before it gets released. But the latest development version is already available you can make use of the changes that I already made.
But it doesn't work right now.
Did you download the latest development snapshot from my site? The code can only be compiled if your version is less than 5 days old.
Also, in the loading bar, when you use setText method it works well, but when you move loading bar (setPostition method), it does not move the text, but only the loading bar, and the text is not show when it's out of bounds.
The following code works fine for me (with both v0.5 and v0.6)
loadingBar->load("TGUI/objects/LoadingBar/Black");
loadingBar->setText("Hello");
loadingBar->setPosition(100, 100);
-
Thanks for fast reply. Ok, I don't need setOrigin that much, because there is a simple workaround for this method.
You're right, my version is about 1month old, I'll download the latest one. ;-)
Hm, that's weird, it works fine for me too... Then I don't know how I provoked this issue. And since I already fix that by changing the code I can't take it back. :-\
I'll try to find what was the problem and if I found it, I'll notice you.
I have another question. How to make loading like this work?
loadingBar->load("TGUI/objects/LoadingBar/Black");
I mean the path, because right now it gives me an error:
TGUI error: Failed to open TGUI/objects/LoadingBar/Black/info.txt
and I have to give the direct path to the folder with object. I work with VS2012 on Win7.
-
I'm not sure where the working directory is in visual studio (I haven't been on windows for some time). I think it is the folder that contains your project file, so if you put the TGUI folder there then it should work. Otherwise just experiment a little, place the folder next to your executable and see if it works then.
-
Project settings -> Debugging -> Working directory -> set "$(TargetDir)" if you want the working directory to be the one containing the executable (like when you launch it from the file explorer).
-
Thank you for your answers. I thought VS somehow includes the main TGUI dir, when I do everything like in the tutorial. Yet, the example code didn't work, because of the wrong paths, and I had to manually change them to direct paths. Thanks! :)
(maybe you (texus) should add this information in tutorial, for future newbies like me ? ; )
I'm not sure where the working directory is in visual studio (I haven't been on windows for some time). I think it is the folder that contains your project file
Yes it is by default (..\Visual Studio 2012\Projects\[project name]\[project name]), when you run your app via Debugger, but when you run via explorer, it's the executable dir.
-
Sorry for the second reply, but I have another problem. I need a button with background image/texture.
AFAIK there is nothing like this in tgui, but maybe there is a workaround for it? Or maybe it is a good idea to make my own ImageButton class? I assume inheritance from tgui::Button/tgui::Button::Ptr is a bad idea (?).
-
I'm not sure what you are asking for.
tgui::Button IS an image button, it draws a backround image with text in front of it.
inheritance from tgui::Button/tgui::Button::Ptr is a bad idea (?).
If you ever decide to inherit something, don't inherit from the Ptr (it won't even compile).
But in the future there will be a turorial about writing custom objects in v0.6 and there it will be explained.
-
I want to add the button, with the icon, something like this:
(http://i.imgur.com/OoS2K6T.png)
Then the button should have method like setImage/setIcon. Maybe it could be done by pushing callback from image downward to the button?
If you ever decide to inherit something, don't inherit from the Ptr (it won't even compile).
That's strange, because I'm using this in my TD. :)
I made my own class Statusbar, which inherits from tgui::Panel::Ptr. Inside id has its own objects, it seems to work pretty well. I had a problem when I set inheritance from tgui::Panel, because I didn't know know do add it (Suatusbar) later to the tgui window. I can show you my code to make it more clear. ;)
But in the future there will be a turorial about writing custom objects in v0.6 and there it will be explained.
Ok, great, I'm looking forward to it. :)
-
I want to add the button, with the icon, something like this
If it is just a static picture (no different image when it is held down) then you can use tgui::Picture. It is capable of sending callbacks when you click on it. Otherwise just change the images inside the path that you pass to the button in the load function.
That's strange, because I'm using this in my TD.
Your right, it does compile.
However the correct way to do the inheritance it this:
struct myObj : public tgui::Object
{
typedef SharedObjectPtr<myObj> Ptr;
};
I expect that there will be only a minor difference with inheriting from tgui::Object::Ptr directly, namely the use of the dot or the arrow operator.
-
Thank you for your reply, I'll try to cope with simple pictures.
However the correct way to do the inheritance it this:
struct myObj : public tgui::Object
{
typedef SharedObjectPtr<myObj> Ptr;
};
I expect that there will be only a minor difference with inheriting from tgui::Object::Ptr directly, namely the use of the dot or the arrow operator.
You are right, but with inheritance from tgui::Object::Ptr I can simply make an object in this way:
MyObj nameofobject(tguiWindow);
(I have to call init method inside constructor to do it)
I'm sure your version is "more correct", but I have some problems with setting text into the label inside my statusbar, so I'll leave it as it is right now (inherited from Ptr).
-
This topic has more than 500 posts now, so I think it's time to open my own forum to keep the questions organized.
You can find it here (http://forum.tgui.eu).
-
Good idea ;)
I lock this topic to "force" people to switch to your forum, let me know if you prefer to keep it open instead.