Messages

Sorry to have prevented you to sleep

You can also find a usage to setSize: it could resize the window, but it can be a bit dangerous... An other possibility is to add an option bool setSizeResizeWindow which is false by default. (But it is only to find an interesting behaviour for setSize, I don't need this personally).

But why you don't store a Window* in GuiContainer? There is no sense to set an other size that the window size, so I think you should not store directly the size but a Window*. That will avoid this problem.

Hello,

You recently merged Container and ContainerWidget and updated Gui (creating ContainerGui). However, there are some bugs with the size of a ContainerGui when you (re)create the window subsequently.
For example:

Code Select Expand


sf::Window window;
window.create(sf::VideoMode(800, 600), "title");
tgui::Gui gui(window);
window.create(sf::VideoMode(1024, 768), "title");
gui->getSize(); // == (800, 600) !!!



PS: [Off-topic] Nice work on the ComboBox widget, I tested and it works great.

Ok, that's right, thanks for your answer.

Ok, thanks, now I see. (You should put your example in a small tutorial. It may help some users.)

The Tab widget on itself only displayes those tabs, you will also need panels for what you want.

Is it something that you wanted, or have you any plan to change that in the future?

Hello,

I don't understand how Tabs are working. How can I add sub-widgets to each tab? Do you have an example please?
Fullexample only use empty Tab...

Thanks

In the new callback system tutorial, you should also replace boost::bind.

netrick: I have personally no problem if I need to install a patch, but texus is right: a lib should avoid depend of such things.
to_string and sto* functions are not very importants (and custom functions can easily do the same).
texus: ok. Thanks for your answer.

Hello,

I just tried to build the last version of TGUI, but...

Code Select Expand


C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp: In function 'sf::Color tgui::extractColor(std::string)':
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:60:27: error: 'stoi' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:68:33: error: 'stoi' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:76:36: error: 'stoi' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:80:37: error: 'stoi' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:85:36: error: 'stoi' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp: In function 'std::string tgui::convertColorToString(const sf::Color&)':
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:108:26: error: 'to_string' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:109:26: error: 'to_string' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:110:26: error: 'to_string' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:111:26: error: 'to_string' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:114:26: error: 'to_string' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:115:26: error: 'to_string' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:116:26: error: 'to_string' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp: In function 'bool tgui::extractVector2f(std::string, tgui::Vector2f&)':
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:139:32: error: 'stof' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:143:32: error: 'stof' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp: In function 'bool tgui::extractVector2u(std::string, tgui::Vector2u&)':
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:173:58: error: 'stoi' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:177:58: error: 'stoi' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp: In function 'bool tgui::extractVector4u(std::string, tgui::Vector4u&)':
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:207:33: error: 'stoi' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:215:37: error: 'stoi' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:223:41: error: 'stoi' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:227:41: error: 'stoi' is not a member of 'std'
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp: In function 'std::string tgui::convertColorToString(const sf::Color&)':
C:\Users\gupas\Desktop\TGUI\src\TGUI\TGUI.cpp:118:5: warning: control reaches end of non-void function [-Wreturn-type]


But I don't know what is wrong...
(I used CodeBlocks/Mingw)
Should I use SFML compiled with c++11 now? It is strange, but until your last commit it worked great with "only" the -std=c++0x option enabled.

Now, it's done! 
But yes, it was a bit long...

I'm agree with wizzard to say that it is a more common way to return true when the event was handled and false when it was not consumed.

I will have a look on the setSize function in the next days.

I'm now going to take a look at Grid, that will be a bit more challenging.

So good luck

Also, I just have done a pull request on github, fixing a documentation issue. You can have a look.

Happy to see that it was already planned.

I know that it is a new Widget and I think that some proposal should help to improve it.

Hello,

It would be great if menus of the MenuBar were opened/closed with a mouse clic (not only with pointing on them).

That's all.

All borders will be made the same size while before you could have some widgets without borders and other widgets with big borders.

It was not the idea. If a widget have a margin of 0 and another a size of 30, if the size of the grid is changed (increased by 30 for example), they should have margin like 15 and 45 and not like 30 and 30.

So I basically see those methods as equivalent and this is thus just a design issue. Some would prefer writing the brackets, others might prefer using the function. But I spend too many words on this already, and actually I don't even care which of the two methods is used.

Right, finally both methods seem to be equivalent.

I am not sure you should move widgets when they are placed. You can want to have a widget at (0,1) and an other at (1,0). If you move the first at (0,0), you will not have the expected layout.

The assumption in my example was that the grid was empty. Obviously when there are widgets in the first column (lets say with a max width of 50 and no borders), widgets added to the second column will have a left of 50.

If you speak at a final (graphical) level you are right, but if you speak at the code (algorithm) level (that I assumed), you are wrong. If you add a widget to the second column (even if grid is empty), you should leave it at the second column (and the first column will have a width of 0 if there is no widget). Now if you add a widget to the first column, you can leave the widget of the second column untouched (in term of position in the grid), only the (x, y) pixels position will be changed.

I really should take a look at other gui's like qt and gtk, because so far I have never looked there for inspiration. I just did it my own way so far, or in a way suggested by users.

It is a really impressive work to have done tgui without having already used any other GUI lib. Wow!

Grid::setSize() (and probably Grid in general) should be heavily inspired of Qt QGridLayout. This can lead to a very powerful widget in TGUI.

The current idea is to implement decent layouts in v0.7.
The only two big changes that should still be done in v0.6 are TextBox and the new form builder. Other than this there are just some small changes and then v0.6 will be finished. After that I will start working on layouts.

So I am waiting v0.7 More seriously, for v0.6, Grid with a better way for adding widgets and a setSize function would be really great (and enough for this 0.6 version, IMHO).

Moreover, currently, if the (auto-sized) grid need a size greater than its parent size to be correctly displayed, how this work?

Nothing special happens, it is just drawn as usually. It doesn't matter if a part is drawn outside of the screen. And child windows use clipping to avoid that widgets draw outsize of them.

That is what I wanted to point out:

What would happen if setSize was called on a Grid? Should it be cropped and all widgets outide this area be invisible? Or should the widgets inside the grid be resized so that together the widgets fill the size?

Finally, in this case, it is cropped even if you don't have a setSize() function. So, I think, keep setSize() without implementation is useless because of this, and provide an implementation (following the behaviour I suggested in my last post for example) can be very interesting.
And if you really don't want a such function, you should at least provide a way to be able to choose for each grid if you want it to fit the whole parent or to be as the current grid.

You probably have considered many possibilities but, to be sure I understand, when you will do "grid[2][3] = ..." you will need to already have grid of a minimal size of (3, 4)?

My idea was actually to automatically resize the grid if it wasn't big enough.

The problem of automatically resize the grid using "grid[2][3] = ..." is that if you try (only) to access to widget at (2,3), and if it doesn't exist you will create it (similar to the std::map [] operator). Or am I wrong?
That is why I proposed a function like grid->addWidget(myWidget, 2, 3, ...); So you can have a better control of this.

I wanted you to be able to set grid[1][0] even before you set grid[0][0] so that you just don't have to care about how many rows or columns there are: grid will take care of it. If you had a picture in [ 0 ][ 1 ] then it would be placed on position (0, 0) until you put a widget in [ 0 ][ 0 ] and then the picture will just move. It just requires some extra code in the brackets operator.

I am not sure you should move widgets when they are placed. You can want to have a widget at (0,1) and an other at (1,0). If you move the first at (0,0), you will not have the expected layout.

For cmake, I really don't know. I can help you, sorry.

For setSize(), I thought of a function which:
-resize to a minimal width or height if the specified width or height is too small. So all widgets will fit.
-when the size is bigger than the "minimal required size", internal margins of all cells are recalculated to fit the whole space of the Grid in the best way. This is very interesting and powerful.
I hope you understand what I want to say. To resume, IMHO, Grid::setSize() (and probably Grid in general) should be heavily inspired of Qt QGridLayout. This can lead to a very powerful widget in TGUI.

Moreover, currently, if the (auto-sized) grid need a size greater than its parent size to be correctly displayed, how this work?

Its actually quite a big change, its not just adding a brackets operator. The "grid[2][3] = button" was just a simplified version. In reality I was thinking more of "grid[2][3] = tgui::Grid::Cell(button, tgui::Borders(...), tgui::Layout::Centered)" and a lot of internal changes. So if you would make the changes that you need and contribute them then thats very kind, but I will probably make a lot of changes to it afterwards anyway.

You probably have considered many possibilities but, to be sure I understand, when you will do "grid[2][3] = ..." you will need to already have grid of a minimal size of (3, 4)?
Why not something like grid->addWidget(myWidget, 2, 3, tgui::Borders(...), tgui::Layout::Centered) (always inspired by Qt)? With this, you can automatically resize the grid to the number of cells needed. No?
But, yes, nonetheless, I understand that there are a lot of changes to do.

And with my current definition of "not soon", it still means that I could be working on this next week.

That's why, if I start this, I want to inform you. But I don't think I will do anything related to this until (at least) the end of the next week. So if you start something, I won't do nothing of course.

You could add a "void initialize(tgui::Container *const container)" function to your class. It will be called when the widget is added to the container, which is right after your contructor finishes in this case.

Ok. I think I will try with this function.

Or you could override the "void setSize(float width, float height)" function. By the time you would call that function, the parent will already be initialized.

By the way, I see (in documentation) that Grid::setSize() "currently does nothing". Normal?

I'm not sure if you are going to add more code, but in your current code the 'parentSize' doesn't do much. The parameter in addRow was actually added for creating empty rows. Once you add a widget to the row, the height of the row will become the height of that widget.

Yes, some more code using parentSize should come. For logo, I wanted having it at the middle of the top third of the screen. So, finally, I should modify borders in addToRow() function instead of height in addRow().

Grid should be rewritten in the future too (so that you can just write something like "grid[2][3] = button"), but I already have so much to do that this won't come soon.

Depending on how I will have free time to work on my project, it is possible that I need this and start some work on it. I will inform you when (and if) I start. If I do this, I will make a Pull Request on github.

For the reason you only see your logo...
You are creating buttons instead of labels. Buttons require a background image and you thus need to use the load function before they will show up. If you only need text then you should use tgui::Label instead.

Edit: That's not really the issue here. There is no parent yet, so there is no font yet. Without a font, the labels can't draw anything.
You should move the creation of the labels to the initialize function.
Another option is to create the labels like now, but set the font in the initialize method

Oh yes, the font... (For Buttons, that was a try I made (but did not work) and I forget to replace by Label again).

Edit2:
You should also ask yourself if you really need an interface that inherits from Grid.
If you don't need this design then it could be better to place the tgui::Grid::Ptr as a member of Interface instead of using inheritance. That way you have your own constructor that can have any parameter (and thus has anything it needs) and can add the widgets to the grid without problems.

My first reason was that I don't need to create "accessors" functions to (un)focus, hide, show, (...) child Widgets. But yes, I will think about it.

Thanks

Hello,

I defined an Interface class like this:

Code Select Expand

class Interface
    : public tgui::Grid
{
public:
    typedef tgui::SharedWidgetPtr<Interface> Ptr;

private:
    tgui::Picture::Ptr m_logo;
    std::vector<tgui::Label::Ptr> m_menuItems;

public:
    Interface();
    ~Interface();
};

I can create one instance of this using: Interface::Ptr interface(gui); in main().
I need to get the parent of the interface in its constructor. However, when the constructor runs, parent is not yet initialized...
So it is not possible to make Widgets constructor taking Parent in first parameter?

Code Select Expand

Interface::Interface()
    : tgui::Grid()
    , m_logo(*this)
{
    // Get parent size (normally)
    sf::Vector2f parentSize;
    tgui::Gui* guiParent = dynamic_cast<tgui::Gui*>(getParent());
    if (guiParent)
        parentSize = sf::Vector2f(guiParent->getWindow()->getSize());
    else if (getParent())
        parentSize = static_cast<tgui::ContainerWidget*>(getParent())->getSize();

    // Init logo
    m_logo->load("data/images/logo.png");

    // Init items
    tgui::Button::Ptr label(*this);
    label->setTextSize(30);
    label->setTextColor(sf::Color(255, 255, 255));

    tgui::Button::Ptr label2;

    label2 = label.clone();
    label2->setText("Introduction");
    add(label2);
    m_menuItems.push_back(label2);
    label2 = label.clone();
    label2->setText("Nouvelle partie");
    m_menuItems.push_back(label2);
    label2 = label.clone();
    label2->setText("Options");
    m_menuItems.push_back(label2);
    label2 = label.clone();
    label2->setText("Aide");
    m_menuItems.push_back(label2);
    label2 = label.clone();
    label2->setText("Crédits");
    m_menuItems.push_back(label2);
    label2 = label.clone();
    label2->setText("Quitter");
    m_menuItems.push_back(label2);

    // Add widget to the grid.
    addRow(200/*parentSize.y/3*/);
    addToRow(m_logo/*, tgui::Vector4u(0,0,0,0), Layout::Center*/);

    for (auto it = m_menuItems.begin(); it != m_menuItems.end(); ++it) {
        addRow(30);
        addToRow(*it);
    }
    updateWidgets(); // Not sure if it is needed but I tried with it and without it.
}


This should display a menu with a logo and below, a list of menu items. However, I have not any Label (menu item) displayed. Only the logo is shown, but it is not at the center of its tile. Do you have any idea of why?

Thanks for your answer.

What's wrong with Slider2d?
There was a problem with MenuBar because of a recent changed but thats fixed now.
It is a development version, but usually eveything works. From time to time I just forget to update the example code or the form builder.

I was not sure if Slider2d was an old version (for compatibility) of Slider or not (that's why I said it is a dev version). So for Slider2d in FullExample, the compiler said:

Code Select Expand

obj\Debug\FullExample.o: In function `main':
FullExample.cpp:131: undefined reference to `tgui::Slider2d::load(std::string const&)'
obj\Debug\FullExample.o: In function `ZN4tgui15SharedWidgetPtrINS_8Slider2dEEC1ERNS_9ContainerERKN2sf6StringE':
TGUI\examples\FullExample/../../build/include/TGUI/SharedWidgetPtr.hpp:69: undefined reference to `tgui::Slider2d::Slider2d()'
collect2.exe: error: ld returned 1 exit status


[EDIT]And for MenuBar I used menu->setTextSize(18);[/EDIT]

EDIT: Now I also remember that I had some problems with the font file: "Failed to add a new character to the font: the maximum texture size has been reached".
I tried to replace the font by an other version of DejaVuSans that I use in one project and it worked... Personally I don't understand why... I uploaded the working font if you are interested. The file is too big... Can you increase the max size, please? (compressed size is around 300KB)

I can't allow bigger files to be uploaded. I could, but I only have very limited disk space on my host. And I wouldn't even know where I would have to change the upload limit. Although a few extra KBs won't hurt, I prefer to have as much data as possible on external servers. You could perhaps temporary put it on dropbox or something similar.

Is the issue really with tgui anyway? Try loading it with an sf::Font and sf::Text and see if you get the same error. If you do then its just the font file that's corrupted.

I didn't think to upload it to another place... So here: https://ubuntuone.com/55Y0cf9MR4rbf5xu2S851F The file have some Bytes of differences with your version.
The error message comes from SFML. I tried to reproduce the bug, but now it works. It's a bit strange. Perhaps, it was related to the C++11...

I only used boost to support older compilers as long as possible, so once I start using c++11 in my own code this issue will go away.

For now you'll just have to do with manually putting that option into cmake.

Ok, I already done this. But until you start using C++11, you may notice this in the installation tutorials?

[However I still have a question:]

Hello,

I tried TGUI and it is an awesome lib (really great work texus).

I compiled it from the latest git version and it worked great with examples (excepted Slider2d on FullExample but it is a dev version, no?).
Then I made some test on one of my project and when I closed the window, I had a segmentation fault.
These is call stack if you want (main.cpp:103 is the end of the main: return 0;):

Code Select Expand

#0 00454DC8 std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >::_M_data(this=0xbaadf025) (c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/include/c++/bits/basic_string.h:290)
#1 00454DB7 std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >::_M_rep(this=0xbaadf025) (c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/include/c++/bits/basic_string.h:298)
#2 004783D2 std::basic_string<unsigned int, std::char_traits<unsigned int>, std::allocator<unsigned int> >::~basic_string(this=0xbaadf025, __in_chrg=<optimized out>) (c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/include/c++/bits/basic_string.h:536)
#3 0044D26B sf::String::~String(this=0xbaadf025, __in_chrg=<optimized out>) (../external/include/SFML/System/String.hpp:43)
#4 0044DDC6 tgui::Callback::~Callback(this=0xbaadf00d, __in_chrg=<optimized out>) (../external/include/TGUI/Callback.hpp:46)
#5 004C4962 std::_Destroy<tgui::Callback>(__pointer=0xbaadf00d) (c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/include/c++/bits/stl_construct.h:95)
#6 00487F43 std::_Destroy_aux<false>::__destroy<tgui::Callback*>(__first=0xbaadf00d, __last=0xbaadf20d) (c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/include/c++/bits/stl_construct.h:105)
#7 004C4B04 std::_Destroy<tgui::Callback*>(__first=0xbaadf00d, __last=0xbaadf20d) (c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/include/c++/bits/stl_construct.h:128)
#8 004C4B20 std::_Destroy<tgui::Callback*, tgui::Callback>(__first=0xbaadf00d, __last=0xbaadf20d) (c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/include/c++/bits/stl_construct.h:155)
#9 004B02A2 std::deque<tgui::Callback, std::allocator<tgui::Callback> >::_M_destroy_data_aux(this=0x28fa6c, __first=..., __last=...) (c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/include/c++/bits/deque.tcc:804)
#10 004B0228 std::deque<tgui::Callback, std::allocator<tgui::Callback> >::_M_destroy_data(this=0x28fa6c, __first=..., __last=...) (c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/include/c++/bits/stl_deque.h:1825)
#11 004B0407 std::deque<tgui::Callback, std::allocator<tgui::Callback> >::~deque(this=0x28fa6c, __in_chrg=<optimized out>) (c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/include/c++/bits/stl_deque.h:907)
#12 004B0437 std::queue<tgui::Callback, std::deque<tgui::Callback, std::allocator<tgui::Callback> > >::~queue(this=0x28fa6c, __in_chrg=<optimized out>) (c:/program files (x86)/codeblocks/mingw/bin/../lib/gcc/mingw32/4.7.1/include/c++/bits/stl_queue.h:92)
#13 0044DD88 tgui::Gui::~Gui(this=0x28fa08, __in_chrg=<optimized out>) (../external/include/TGUI/Gui.hpp:37)
#14 0040BAC8 main(argc=1, argv=0xcc34a8) (C:\Users\...\PROJECT\src\main.cpp:103)

I probably spent a couple of hours to find that it was because my project is a c++11 one while I built TGUI "normally".
I also spend some times to find how I can build TGUI using c++11. (If it can help someone, in cmake (using cmake gui), check "Advanced" and add "-std=c++11" (or any other option) to CMAKE_CXX_FLAGS).

However I still have a question:
SFML 2.0 packages are not built using c++11 (normally) but I use them without any problem in my c++11 project. So why, for TGUI, I need to build using c++11?


EDIT: Now I also remember that I had some problems with the font file: "Failed to add a new character to the font: the maximum texture size has been reached".
I tried to replace the font by an other version of DejaVuSans that I use in one project and it worked... Personally I don't understand why... I uploaded the working font if you are interested. The file is too big... Can you increase the max size, please? (compressed size is around 300KB)