Messages

I'm going to have a look if I can reproduce it.

In the meantime you can change your settings to also work in debug, and revert the order of the libraries (first system, then window, ..., finally tgui). And then rebuild the project. Just to be sure that neither of these things influence the crash.

The library paths in release mode seem right, but the ones in debug mode are wrong.

Code Select Expand

C:\SFML 2.1 -32\SFML-2.1\lib
Should be

Code Select Expand

C:\TGUI-0.6\lib\SFML

Oh, and the include directory doesn't need "C:\TGUI-0.6\include\SFML". But that doesn't really matter.

Edit: I now see that the include directory in debug mode is also set to the wrong sfml version.

So unless you were experiencing the crash in release mode, it should be solved after changing library and include paths.

Also how can we write in italics or bold in comboboxes, listboxes, etc?

That is something that you can't do. It could be added in the future but it will take some planning about how it would be implemented.

I was also wondering how many different events tgui knows, beyond tgui::button::LeftMouseClicked.

Normally this is found in the documentation of that widget and its base classes. But since the documentation isn't really complete yet, here is the full list. Button inherits from ClickableWidget which inherits from Widget, so it also has the events from its base classes.
(The documentation of v0.6 should contain the ones from the other widgets, I think only PositionChanged and SizeChanged are new in v0.7)

Widget:
  PositionChanged       ///< Position of the widget has changed
  SizeChanged           ///< Size of the widget has changed
  Focused               ///< Widget gained focus.
  Unfocused             ///< Widget lost focus.
  MouseEntered         ///< Mouse cursor entered in the Widget area.
  MouseLeft            ///< Mouse cursor left the Widget area.

ClickableWidget:
  LeftMousePressed     ///< The left mouse button was pressed
  LeftMouseReleased     ///< The left mouse button was released
  LeftMouseClicked     ///< The left mouse button was clicked

Button:
  SpaceKeyPressed     ///< Space key was pressed
  ReturnKeyPressed     ///< Return key was pressed

what is the appropriate event when the user clicks outside of the widget he was using

That will hopefully generate an Unfocused event

Focusing widgets is something very tricky in my code and even I can't always predict the exact behavior. The event should be fired when clicking outside the edit box that you were typing. But I don't think it will work with e.g. a slider.

The SpaceKeyPressed and ReturnKeyPressed callbacks only work when the button is focused, but the black style has no focused image by default. So it may not be possible to focus a button and then press space to trigger a callback while using the black theme.

Edit: I just verified it. Clicking outside the edit box will correctly generate the unfocused callback. Button will generate this callback immediately after the focused callback, since it cannot be focused without a focus image. Edit box is the exception since it has to be focused to type text in it, which is the reason that it can be focused even when there is no focus image.

I just need the vcxproj file. If your code is just a single file then you can send that as well.

Those files should even be small enough to be added as an attachment to your post.

Just to be sure, you have v0.6.5, right?

I'm not sure if I hit a bug in gcc, or just some special case in the c++ standard.
I'm going to assume its a bug since it compiled with gcc 4.9.

The braces on lines 274 and 284 in src/TGUI/Layout.cpp should be replaced by brackets.
So "m_first{...}" should be "m_first(...)".
It should compile after that change.

I also found 2 other places that didn't compile, but you since you already passed the first one, and I assume that gcc 4.8 will have an emplace function, they just have to be fixed to make it work on gcc 4.7.

Left, Middle and Right.

The Left and Right parts would keep their ratio, while the Middle part gets stretched.
E.g. the EditBox image in the black theme is only 120 pixels width, but it still looks good when giving it a width of 1000 pixels.

But this has been replaced in v0.7 where you can even use 9-slice scaling. You would specify the entire button image there, and then set the middle rect to (50, 0, 100, 50) to split the image (with a width of 200 and a height of 50) into 3 parts (these rects are always left,top,width,height).

I think we may have a serious problem here, this may not be easy to fix.
But before I can try to fix it I have to reproduce it. I have 4.9.1 installed on all my linuxes so I'm going to check on windows with 4.7.1.

In worst case I will have to completely rewrite the layout system (which I'm planning to do someday anyway since it has become a mess), but then it will take another week before you can use this version.

Yes, but I was just mentioning it in case you also develop on another computer.

What compiler version do you have? (type "g++ --version" in the terminal)

And you are 100% sure that you are linking tgui in the same way as sfml? (both dynamic or both static, both release in release mode and both debug in debug mode).

If so then could you send me your project file(s)?

You can download it here: https://www.dropbox.com/s/ay4trebp4j1ehqr/texus-tgui-devel-af81ec0bcefb.zip?dl=1
Installation is the same as v0.6. You do need to have the latest sfml version for it though, it won't work with sfml 2.1.

Have a look at the examples/login_screen folder. That example will probably teach you most things.

I noticed that there is still a small bug with how slider stretches. I'll fix that tomorrow.
In order to solve it, the Slider section in Black.conf should look like this:

Code Select Expand

Slider:
    TrackNormalImage = "Black.png" Part(203, 150, 20, 45) Middle(0, 15, 20, 15)
    TrackHoverImage  = "Black.png" Part(223, 150, 20, 45) Middle(0, 15, 20, 15)
    ThumbNormalImage = "Black.png" Part(243, 150, 30, 30)

I even just realized that in v0.6 it always stretched that bad. So its not even a bug fix, changing this code is a feature .

There will still be quite some changes in the next month to the v0.7 code though.
But the big rewrite to all the widgets is almost over (just MessageBox has been temporarily disabled and TextBox still has to be rewritten). Most of these changes will be improvements to specific widgets so they shouldn't bring too much incompatibilities.

There aren't tutorials yet, but the post in the last month on the facebook page show most of the new features.
The example code that is included with the download will be the best place to learn though.

I'm just recreating the Black theme. After that I'll send you the v0.7 code.
Do you have a bitbucket account by any chance?

I have added something similar in v0.7, with the difference that it isn't italic and only disappears when you start typing. Making it italic is not such a bad idea, I guess I'm going to change my code to do that too.

Without changing the code in edit box, you could write some functions that make changes to the edit box at the right time, but you can't make the text italic.
With the code that I'm going to have for v0.7 (and which can possibly be ported back to v0.6 if you want), it won't disappear when just clicking on the edit box. Although you could intercept the focus callback to remove the default text, and the unfocused callback to add it again.

As for the cards, they are all sf::Sprite.

In that case the automatic relative positioning won't help much.

Well unless it will take you several months to finish your latest version, I think I can wait a bit.

I can't predict how long it will take, but I don't expect it to be finished this year. I'll have a little over one month left to work on it every day and then I will have a lot less time. So its hard to predict how far I can get by next month. Hopefully there will be an alpha version by then which will bring some stability.

I'd rather wait and use a stable version than take the current one as it is and experience problems.

I guess you can still make a decision in a month or so, to see what the status is at that point. There will be tons of new features in v0.7, but I don't think I will get the same stability as in v0.6 soon.
If v0.6 already has what you need then that should probably be the version to go with.

If you do need hover and down images then you will have to use buttons instead of normal pictures.

Unlike the Black theme, your images probably will never get stretched in one direction and you thus don't need to split them in 3 parts.
So you can use NormalImage, HoverImage and DownImage properties (instead of all combinations with _L, _M and _R).
The value is the filename of the image in quotes, optionally followed by which part of the image to load (defined as (left, top, width, height)). It the part rectangle is not specified, the entire file will be loaded.

As said, you will need one theme file per button. So they will look like:

Code Select Expand

Button:
NormalImage = "..."
HoverImage = "..."
DownImage = "..."
SeparateHoverImage = true


Some of the work you have to do could be easier in v0.7.
Two examples:
- You can have multiple buttons in a single config file (I very recently added this feature)
- You can specify a relative position. You can make the buttons relative to the card (if this is a tgui::Picture widget and not a sf::Sprite) and then the buttons will automatically move when the position of the card changes.

However, since v0.7 is still under serious changes (the big rewrite is almost finished though), the new parts are not very well tested and the api will not remain stable. But if you want to try this version (most features can be found by looking at the post on the blog), then just let me know.

The project indeed sounds like a lot of work. I would love to see it when it finished.

It sure is possible, but not with the default Black theme. One of the limitations of v0.6 is that you can't use a size for which the image was intended for (e.g. the black button isn't intended to be square).

But do you really need a button? The theme files are still limited to one button per file, so you would be needing a theme file for every button image. This limitation even still exists on my private v0.7-dev branch, although I plan to fix that next week or so.

So it would be easier if a simple image was enough (if not then I'll happily explain how to write the theme files). If you don't need a different hover or down image, then you can just use the Picture class. It is also capable of sending click callbacks.

My goal is to create a listbox where each line contains
- a text
- next to the text, a dozen buttons with no text on them, instead they each have their own image so that the user can easily guess what each button actually does.

Out of my head (i.e. untested code), it would look like this: (it assumes that each column has the same button images)

Code Select Expand

void addLine(tgui::Grid::Ptr grid, const std::string& text)
{
    // There is no function that returns the amount of columns or rows it seems
    // I guess I'll have to fix that, but for now rows = amountOfWidgets / widgetsPerRow
    unsigned int rows = grid->getWidgets().size() / 3;  // 3 because we add a label and two pictures
   
    tgui::Label::Ptr label(*grid);
    // change stuff like label color and text size
    label->setText(text);
   
    tgui::Picture::Ptr first(*grid);
    first->load("FirstButton.png");
   
    tgui::Picture::Ptr second(*grid);
    second->load("SecondButton.png");
   
    grid->addWidget(label, rows, 0);
    first->addWidget(label, rows, 1);
    second->addWidget(label, rows, 2);
}

int main()
{
    // Obviously some other code is in this function as well
   
    tgui::Grid::Ptr grid(gui);
   
    // Whenever you need a new line you just call addLine(grid, "Text")
}

How you handle the callback is up to you, but just for the sake of giving an example, here the callback function will be called with the row and column number of the grid (since label is in column 0, the first button has column number 1, the next 2, and so on)

Code Select Expand

void func(unsigned int row, unsigned int col);
first->bindCallback(std::bind(func, rows, 1), tgui::Picture::LeftMouseClicked);
second->bindCallback(std::bind(func, rows, 2), tgui::Picture::LeftMouseClicked);

Sorry to be such a pain

Its ok to ask questions, especially about complex stuff like this. Plus it prevents me from feeling like nobody is using my library .

Ok, I have also added the line to the tutorial.

It feels a bit weird for me to write the line though, since I have been working on v0.7 for some time already and creating a widget is completely different there. I even had to look up myself whether grid had a load function or not .

All widgets are created in the same way.

In order to create the grid, just do:

Code Select Expand

tgui::Grid::Ptr grid(gui);

That will add the grid widget to the gui and after that you can start adding stuff to the grid.

It may have been a bit unclear in the tutorial, since I don't specify what the grid variable is.

(if this is not your problem, the you should post the error message so that I don't have to guess)

Where can I download Black.conf ?

It is provided inside the TGUI download, inside the "widgets" folder.

Also, I was wondering if that was possible to make a chatbox or listbox with buttons in every line?

You should have a look at the Grid widget:
https://tgui.eu/tutorials/v06/grid/
https://tgui.eu/documentation/v0.6/classtgui_1_1Grid.html

Same thing: "Could not find UDev library".
Typical format in ubuntu is libXXX-dev, so again it is just "sudo apt-get install libudev-dev".

Edit: You might get errors for the other dependencies too:
    pthread
    opengl
    xlib
    xrandr
    freetype
    glew
    jpeg
    sndfile
    openal

You can look up the package name by searching for them on https://packages.ubuntu.com/, but like I said it is mostly called libXXX-dev.

I wonder, did you test sfml before you tried to install tgui?
XRandr has always been a dependency of sfml, and sfml shouldn't be able to function without it.

If you installed sfml by just copying the files to the lib folder manually then removing them can also be done by removing them manually. But if you used apt-get to install it then you must also use apt-get to remove it.

This should install xrandr:

Code Select Expand

sudo apt-get install libxrandr-dev

how do I uninstall SFML safely?

By doing the opposite of how you installed it. I have no idea how you installed it. Perhaps you used apt-get and then you uninstall it with "apt-get remove sfml" or "apt-get remove sfml-dev" or something similar.

So how do I do?

The latest version of sfml depends on the xrandr library which is missing from your system (I guess sfml 2.1 didn't use xrandr yet).
I think you install it with "sudo apt-get install xrandr" but it has been a while since I have used ubuntu.

You said you have the latest sfml version installed, but I don't think you have.

SFML 2.1 has no destructor in the Image class, this was added later.
So it seems like TGUI has been linked to a later version of sfml, while the library you are looking at is from SFML 2.1.
Do you perhaps have multiple versions on your pc?

I would uninstall everything from sfml that you have and then really install the latest version (install git if you don't have it yet).

Code Select Expand

git clone https://github.com/LaurentGomila/SFML
mkdir SFML/build
cd SFML/build
cmake ..
make -j4
sudo make install

Then try installing tgui again.

Code Select Expand

git clone https://github.com/texus/TGUI
mkdir TGUI/build
cd TGUI/build
cmake ..
make -j4
sudo make install

Wait before you ask on the sfml forum, I just figured something out.

Then your libsfml-graphics.so is indeed missing a destructor for the Image class. I would think you are also going to have problems with just using sfml without tgui, since sf::Image::~Image just isn't there. The lines with the C instead of the D are the constructors of the class.

If you don't get any further problems then you can continue like this, but now we know that the problem lies with sfml. I'm not sure how you installed it, but if you get further trouble then you should try to re-install it or install it in another way.

Apparently you need to use "nm --dynamic" instead of just "nm", although I didn't need it on my system (but I'm using arch and not debian/ubuntu like you). (based on https://lists.debian.org/debian-user/1997/11/msg00428.html)

I'm not even sure if there is anything interesting to find in these so files or not. I'm just guessing random stuff because I don't understand why it can complain about just one missing symbol.

Edit: running "nm --dynamic /usr/local/lib/libsfml-graphics.so -C | grep sf::Image::~Image" might be more clear and should return 2 lines.