Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - texus

#1251
Help requests / Re: Grid and sf::Text
13 February 2015, 19:53:11
I think what you are doing can be done with tgui::Grid if you use tgui::Label instead of sf::Text. But that is of course not possible if you need to do something with the text that the Label class doesn't support. Using a grid will make positioning easier (you just have to say in which row and column, not an exact position), but you will have to play around a bit with the borders that you set around widgets so that the texts don't glue to each other.

For the problem with the checkboxes, my guess is that you don't take the text.getLocalBounds().top into account. If you draw text with sfml then there are always a few empty pixels above the character. This could explain why the checkboxes are placed too high.

So you should try with
Code (cpp) Select
initPos.setPos(colsOfText[0].getPosition().x + colsOfText[0].getLocalBounds().top, colsOfText[0].getPosition().y);

Edit: I was hoping that Grid still supported a way to set the row height, but looking at the documentation it seems like it was removed. So you should probably forget about using a Grid if you want each row to have the exact same height.
#1252
Help requests / Re: Grid and sf::Text
13 February 2015, 17:43:38
QuoteSo is there a way for me to insert sf::Text as well as widget elements into a grid?
No, only tgui widgets can be added to the grid.

Quotehowever they always seem a little out of alignment
I'm not sure if this is what you mean, but in checkboxes there is a space of 1/10th of the checkbox size between the checkbox image and the text that it displays next to it.
If that is not what you meant then could you explain a bit better what you mean with this? (screenshot or piece of code perhaps)
#1253
Help requests / Re: Bug in MessageBox
12 February 2015, 13:40:33
QuoteI pulled the latest dev version and it's working now. I see that you had other modification of fonts in MsgBox code. That was probably the problem.
That was actually a fix for a completely different bug :) (the text was visible but the window did not resize correctly)
Good to see that it fixed this problem as well.
#1254
Help requests / Re: Bug in MessageBox
12 February 2015, 12:34:10
You should show a minimal and complete example code (something that I can just copy-paste and run).

I tried these few lines from your first post yesterday and it worked fine for me. So it might be a problem somewhere else in the code.
#1255
Help requests / Re: Bug in MessageBox
11 February 2015, 22:58:22
Quotewhen a button is clicked you send a "ButtonClicked" signal. However in the constructor (and according to the API documentation) you look for the "ButtonPressed" signal.
Thanks for reporting. It has been fixed.

QuoteWhen the messagebox appears I can't see any text neither in the window nor on the buttons, just the blank placeholders
This could be caused by two reasons:
- Did you set a global font?
- Is the Gui/Black.conf correctly loaded? Do you get any errors in the terminal?
#1256
Help requests / Re: Adding scollbar to a panel?
11 February 2015, 10:01:15
You can use the scrollbar anywhere, you actually have to handle everything it does yourself.

Here is an example of a panel containing 5 pictures and a scrollbar to scroll through them. The comments in the code explain what each part does. I'll probably add this to the example code on my website later today.
Storing previousScrolbarValue is needed to figure out how much to move all widgets. But knowing the original location of one of the widgets and calculating the distant position based on that will work just as well.
Code (cpp) Select
#include <TGUI/TGUI.hpp>

int previousScrolbarValue = 0;

// Function that will be called when scrolling
void scrollPanel(tgui::Panel::Ptr panel, const tgui::Callback& callback)
{
    int distanceToMove = previousScrolbarValue - callback.value;

    // Move all widgets that are inside the panel
    for (auto& widget : panel->getWidgets())
        widget->setPosition(widget->getPosition().x, widget->getPosition().y + distanceToMove);

    previousScrolbarValue = callback.value;
}

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "TGUI window");
    tgui::Gui gui(window);

    if (gui.setGlobalFont("TGUI/fonts/DejaVuSans.ttf") == false)
        return 1;

    // Create the panel
    tgui::Panel::Ptr panel(gui);
    panel->setPosition(50, 50);
    panel->setSize(240, 360);
    panel->setBackgroundColor(sf::Color(200, 200, 200));

    // Add some widgets to it (image1.png to image5.png)
    for (unsigned int i = 1; i <= 5; ++i)
    {
        tgui::Picture::Ptr pic(*panel);
        pic->load("image" + std::to_string(i) + ".png");
        pic->setSize(240, 180);
        pic->setPosition(0, (i-1) * 180);
    }

    // Add a scrollbar
    // Note that we add it to the gui and not to the panel.
    // Doing so allows us to easily move everything inside the panel when scrolling
    tgui::Scrollbar::Ptr scrollbar(gui);
    scrollbar->load("TGUI/widgets/Black.conf");
    scrollbar->setSize(20, 360);
    scrollbar->setPosition(panel->getPosition() + sf::Vector2f(panel->getSize().x, 0));
    scrollbar->setArrowScrollAmount(30);
    scrollbar->setLowValue(360); // Viewable area (height of the panel)
    scrollbar->setMaximum(5 * 180); // Total area (height of the 5 images)

    // Call the scrollPanel function that we defined above when scrolling
    scrollbar->bindCallbackEx(std::bind(scrollPanel, panel, std::placeholders::_1), tgui::Scrollbar::ValueChanged);

    // Mainloop
    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 0;
}
#1257
QuoteOne of the two will be used. Which one is undefined.
I recognise the error. I've seen it quite a lot last week while improving the mac support. It happens when the TGUI library was build against different SFML libraries than you use in your project.

Do you happen to have have sfml dylibs installed on your system (assuming that you are using sfml frameworks in your project)?

In cmake, you should check the "Advanced" checkbox and have a look at the entries like SFML_GRAPHICS_LIBRARY_RELEASE (so also the window and system ones). I suspect that the value of these entries are going to be different than the sfml libraries that you use in your project.
#1258
Help requests / Re: ScrollBar Issue
08 February 2015, 01:51:04
The function itself is documented, but what you wanted to do is not. There is no relation with the scrollbar being moved, so it couldn't really be found.

I will add the following to the documentation of the function. That way someone might be able to find it in the future if they look for the word "scrollbar" in the documentation of the text box.
QuoteIf the selection point is outside the visible area, the text box will scroll to show the part where the selection point is located. So calling setSelectionPointPosition(0) will always make the scrollbar go completely to the top.
#1259
Help requests / Re: ScrollBar Issue
08 February 2015, 00:04:10
There is no way to control the scrollbar directly.

But it can be done indirectly in this case. After you set the text in the textbox, call the following:
Code (cpp) Select
textbox->setSelectionPointPosition(0);
#1260
What you need to solve your real problem is to check the return value of the gui.handleEvent function. You can then determine to pass the event to your map editor or not.
#1261
The MouseEntered signals where indeed broken in MenuBar and they will now be send correctly in the new version.

Why do you need a MousePressed signal?
#1262
Feature requests / Re: [v0.6] setTextStyle
02 February 2015, 18:24:31
I don't think that is worth the effort. I doubt that many people will need that.
#1263
General Discussion / Re: [vs12] 0.7 warnings
02 February 2015, 14:02:08
The strcpy_s function only exists in Visual Studio, so this code won't compile in MinGW.

It would also be easier if you would send diff files instead of entire files. That will allow me to more easily integrate the changes. If you would be able to use git and send me a file created like "git diff > changes.diff" then all I have to do is run "git apply" to make the changes here.

This is less important for small changes like this, but if you start make bigger changes then I guess I should make the commits in your name. So what name and email address do you want me to commit these with?
#1264
It seems like the functions in Signal.cpp are not marked for being exported. Which is why it works on everywhere except on windows when using dlls.

It should be fixed in the latest version, but you can of course just keep using the workaround for now (as long as you delete that code when you ever update to a newer version).
#1265
Quotevoid Picture::loadFromTexture(sf::Texture& _texture)
The biggest change that v0.7 still needs is a completely new theme system. This includes a new way of loading themes (probably first create a Theme object and then pass this to the create function of the widgets so that the theme can be shared). There should be a way to to easily make a change in the theme so that all widgets receive this change. The themes must be loadable through custom loaders. The texture manager will be placed into the default loader which will be in tgui. If you use your own loader then you have to manager resources yourself.

The reason I am explaining this is because this change can only easily be made when picture (and especially the texture in it) no longer depends on the internal texture manager.

I always use "sf::" in front of all sfml classes. I know it is confusing, but there is a tgui::Texture class as well. So it is not as simple as "m_texture = texture" ;)

QuoteCan you please add option with only sf::Font&
I always though that the user would be forced to create a shared_ptr himself. I never though of letting the user create the sf::Font object and then using the copy constructor to get a shared_ptr from it. However adding such a function would mean that a copy gets made internally and when the user changes his font the widgets won't change with it. So I'm ok with adding such a function, but it should contain the warning that the font gets copied, not directly used.

To avoid duplicate code, the function would thus just call the other variant:
Code (cpp) Select
void setTextFont(const sf::Font& font)
{
    setTextFont(std::make_shared<sf::Font>(font));
}


Feel free to add this setTextFont function to all widgets that need one. I do have time but I am working on other stuff.

I was thinking of giving all widgets a setTextFont function. What do you think about that? It would mean that widgets like Picture get a useless function, but it would also mean that setGlobalFont can change existing widgets (after adding extra bool parameter indicating if change is for future or all widgets). This would mean that with a single function call the font of all widgets could be changed.
#1266
You get the same error when you use this instead of your line?
Code (cpp) Select
button->connect("MousePressed", [](sf::Vector2f position){});

What about this one? (it would give an error on runtime, but it is just to check if it compiles)
Code (cpp) Select
button->connect("MousePressed", [](int i){});

And what if you put this somewhere in your code?
Code (cpp) Select
template <> std::string convertTypeToString<sf::Vector2f>() { return "sf::Vector2f"; };
#1267
General Discussion / Re: [vs12] 0.7 warnings
02 February 2015, 12:34:17
I really don't care about these conversion warnings. Once in a while I boot up my windows to fix them (because only VS gives these warnings). But you can expect more of these when I push new code.

The "decorated name length exceeded, name was truncated" warning comes from the layouts. This part has to be rewritten anyway. It's possible that the warning will remain after the rewrite though, so feel free to look at what is causing it and if it can be easily fixed.

And then there is the strcpy warning which has bothered me quite a lot since in some cases VS turns that into an error instead of a warning. But the secure version is only available in visual studio. What do you think is best here, leave it like it is, or put an ifdef around it and use strcpy on all compilers and just use strcpy_s in VS?

Feel free to fix these warnings if you want to, I don't find them important enough to boot my windows.
#1268
Help requests / Re: conflict with OpenGL
01 February 2015, 15:49:17
Then you should probably create a minimal code that reproduces the error that doesn't use tgui and go ask on the sfml forum. I can't help you with this.
#1269
Help requests / Re: conflict with OpenGL
01 February 2015, 15:37:17
TGUI just uses the graphics module from SFML for everything it draws, there should be nothing that TGUI influences that SFML doesn't do already (except perhaps clipping, but the way I implemented it should not give problems).

So could it be that you are not saving and restoring OpenGL states around the draw calls?
https://www.sfml-dev.org/tutorials/2.2/window-opengl.php#using-opengl-together-with-the-graphics-module

If you are doing that already then you should test if you get the same crash or not when loading and drawing an sf::Texture and sf::Sprite.

Edit: If it is the creating of the widgets then the problem is more serious. But does it work when just creating a sf::Texture instead of loading a widget?
#1270
TGUI now has experimental Android support!

The tutorial for it can be found here: https://tgui.eu/tutorials/v07/android/
#1271
Focussing is indeed broken. I haven't really decided yet how the focussing system should work correctly.
So focussing will only work correctly with simple widgets like buttons, checkboxes and edit boxes. Although even the Black style does not load the focus images by default so it basically only works with edit and text boxes out of the box.
#1272
In a simple piece of code that I used, the following works fine:
Code (cpp) Select
button->connect("MousePressed", [](sf::Vector2f position){});

What compiler are u using?
#1273
Since the release of v0.7 is still far away and v0.6 is still going to be the preferred version for quite some time, I decided to patch this issue anyway. I can't fix every problem with ordering of setting font and calling other functions, but at least calling the add function after the widget is already set up should no longer give problems. The changes where made on the master branch on github.

Nevertheless, I still want to figure out why changing the order of the add is not working for you.
#1274
I just realized that word-wrap was only added in v0.7-dev, so there is actually nothing that stops me from adding such style in v0.6 right away.

The latest version on the master branch now has setTextStyle and getTextStyle functions.
#1275
Quoteif this is your definition of a few pixels hehe
That screenshot is exactly what I got too with your code, but changing the order of the add solved it.

Did you set a global font before creating the widget?

Could you write some simple code that starts with setting the global font, then calls the constructor of the button to initialize it and then loads the button, which still displays the wrong text position? That way I can test with the same code.

QuoteAye, I did. It's just a simple file.
The text displays correctly here. Something is probably going wrong with setting the font and this thus most likely has the same cause as the issue with the uncentered text. So lets focus on that issue and then afterwards you can check if this is solved too or not.