Messages

I see two solutions for the scrollbar.
- You have the scrollbar directly in the gui. When loginScreen or mainScreen is visible, you call scrollbar->hide() and when Group1 becomes visible again you call scrollbar->show().
- You make a different scrollbar inside every groups that need it. This will allow every scrollbar to have its own callback function and to do different things in every group.

The reason why your Group2 doesn't react on the scrollbar, is that you access Group1 in scrollbarValueChanged.
If you could find a way to access the current group, e.g. holding some string that contains either "Group1" or  "Group2" and then use the string like this:

Code Select Expand

tgui::Panel::Ptr panel = callback.widget->getParent()->get(theString);
Then you can keep the scrollbar in your gui and it will be able to scroll the widgets in whatever group you want by just adjusting the string.

So

Code Select Expand

tgui::Scrollbar::Ptr scrollbar(*Group1);

Doesnt work, when i change values of scrollbar [with mouse or mouse scroll] program crashes with

Code Select Expand

/usr/local/include/TGUI/SharedWidgetPtr.hpp:271: T* tgui::SharedWidgetPtr<T>::operator->() const [with T = tgui::Panel]: Assertion `m_WidgetPtr != __null' failed.

You are doing something with a null pointer. At first I was a bit surprised because I though this crash came from inside tgui, but I think the problem lies in your scrollbarValueChanged function.
Do you have code like "gui->get("Scrollbar")" there or something like that?

Because what I notice is that when you pass 'gui' to it you also give the widget a name, but when you pass '*Group1' to it you don't give it a name.
So if it is the problem that I suspect than you just need "tgui::Scrollbar::Ptr scrollbar(*Group1, "Scrollbar");".

Although I don't see why the scrollbar should be inside the panel instead of just in the gui.

except i see scrollbar in panel where i dont need scrollbar

What exactly do you mean with this?

Need to figure out how to access each editBoxes to read it values, and to modify them.

You can get them back later with the get function on your Group1.

But make sure all widgets have unique names.
If you are still creating the pictures as before then you are going to get name conflicts.
You are calling your pictures "1", "2", "3", "4", ...
But you are also calling your edit boxes "1", "2", "3", "4", ...

So maybe you should write

Code (cpp) Select Expand

tgui::EditBox::Ptr Name(*Group1, "EditBox" + tgui::to_string(i));
Like this, your edit boxes will be named "EditBox1", "EditBox2", "EditBox3", ...
And you can get them from Group1 later with this name.

If you would have two widgets with the same name then getting them from Group1 will only give you the first occurence (first added widget with that name), and it will be impossible to access the other widget.

That's because I don't think Slider2d should be a widget that belongs to the Black theme.
My original idea for Slider2d was to create something like a color scheme.

I kept it seperately because I don't think people will need to use a slider2d with these image very much.

There just are no images that fit with the BabyBlue style (just like for Tab, although this is going to be added later).

Too bad that I don't drink beer

You missed something in my previous message.

Then at the end of your scrollbarValueChanged function, you set it to "callback.value".

Adding "scrollbarValue = callback.value;" at the end of scrollbarValueChanged makes it work.

You should just fix your setPosition formula. You set all widgets to x=20, so obviously the buttons will change their original position.

The trick is to keep all objects on their starting position minus the scrollbar value.

For this you will also need the old scrollbar value, so you'll have to store that.
In the example code, you could make a global variable scrollbarValue (int) and set its value to 0.
Then at the end of your scrollbarValueChanged function, you set it to "callback.value".

The setPosition line would then have to become:

Code (cpp) Select Expand

widgets[i]->move(0, scrollbarValue - callback.value);

That should solve all problems.

Also, the scrollbar isn't part of the panel I guess, so you no longer have to check the widget name against "Scrollbar" as that will never match.

Clipping was removed earlier because the fix wasn't in sfml yet. I agree that now the fix is already in the github version and because most people do use windows it isn't a problem to add it again.

The changes have just been pushed.

Your scrolling the whole gui, including the panel. You can easily see this when you give the panel a background color. You should only be scrolling the contents of the panel.

Code (cpp) Select Expand

void scrollbarValueChanged(const tgui::Callback& callback)
{
    tgui::Panel::Ptr panel = callback.widget->getParent()->get("Group1");

    // Reposition the object
    std::vector<tgui::Widget::Ptr> widgets = panel->getWidgets();
    std::vector<sf::String> widgetNames = panel->getWidgetNames();

Also if you don't want the buttons to move then you should just add them to the gui (pass 'gui' as parameter instead of '*Group1' when creating them).

Thanks for testing these builds.

But I think it is not really necessary to test the gcc builds on linux. You use the same compiler than I am and I am getting smarter recently, I'm starting to actually compile the builds myself before pushing to github. I do forget it from time to time, but usually I am aware of warnings.

For single line labels your clipping solution will indeed be better, but I'm more worried about when you have multiple lines. I would have to find out how many lines need to be visible and that is an even slower process. Of course it will probably still be faster than clipping every frame, but I guess I'm just lazy and I know that implementing clipping when drawing is much easier to write.

Anyway, I'll implement clipping in the draw function again. Optimizations can come later.

So label should become like it was in v0.5 again. Read the documentation about setSize, setText and autoSize. Is this the design you need?

I'd still prefer normal clipping over that. This is just a different form of clipping (faster at draw time but slower when calling setSize).

But whatever method I use (probably just clip like it was before), I need to make a decision about what should happen when changing the text after setting a size. When not setting a specific size then the size should be changed automatically to fit the text, while if you have set a size then the size should stay the same. So I'll add an autoSize method again.

I'm pushing for it because I want to have TGUI automatic resizing up and running as soon as possible as I'm getting closer to pre-alpha release of my game and gui layout is basically the only big thing left.

I'll do my best to help with what you need, but I doubt I could get a very good layout system in v0.6.

By the way, how is clipping label going to help with what you need?

If the line is to long it will be split over multiple lines. No clipping needed there.

Just create the picture, buttons, etc. widgets and place them like they should be when the scrollbar is at the top.

In my example code above you should then change the scrollbarValueChanged function to this:

Code (cpp) Select Expand

void scrollbarValueChanged(const tgui::Callback& callback)
{
    tgui::Container* gui = callback.widget->getParent();

    // Reposition the object
    std::vector<tgui::Widget::Ptr> widgets = gui->getWidgets();
    std::vector<sf::String> widgetNames = gui->getWidgetNames();
    for (unsigned int i = 0; i < widgets.size(); ++i)
    {
        // Don't move the scrollbar
        if (widgetNames[i] != "Scrollbar")
            widgets[i]->setPosition(0, i * 150.0f - callback.value);
    }
}

That will move any object except for the scrollbar.

If there are other widgets that don't need to move then you will need a slightly different approach. You should place all widgets that have to move in a Panel and then just move all widgets of the panel (instead of all widgets of the whole gui).

PS: You should have better made another post instead of editing the previous one. I got no notification about it nor does the forum marks the topic as unread. You're lucky that I noticed your new question.

setSize is now accessible in Widget.
The functions for Label, Tab and Grid are still empty though. MenuBar now has a setSize function instead of just its setHeight.

The new documentation will be uploaded in a few minutes.

The other reason why I don't want to implement clipping again (except for the fact that it slightly is slower, even with the changes in SFML 2.1), is that I am not sure if clipping is the correct way.

You could also make the label fit inside the given size.
So it is either cut of the parts that fall outside the box, or make the label fit inside the box.

I haven't really decided on that either, although clipping is probably the best option.

I was actually working on solution 2 when the fix was made in sfml. But I'm not going to continue it (or better said restart, because I didn't keep the code).

SFML 2.1 should be released relatively fast though, its only a bug fix release.
I just checked and there are only 4 more open bugs marked for 2.1. A lot of bugs were closed in the last few weeks, so I'm going to stay optimistic.

Edit:
3) There isn't really an alternative.
I'm waiting for issue #1 to be closed so that I don't have to use opengl myself to clip. But that is something that might indeed not happen before 2015.

This actually was the way label behaved earlier.
In SFML 2.0 (not the github version), getting the size of the window was slow on linux. My current clipping algorithm needs the size of the window (because glScissors starts from the left bottom corner of the screen which makes the calculations a bit harder). It was so bad that ChatBox (which made use of labels) couldn't have more than a few lines before getting serious performance issues. Because of this, setting the size and clipping in label were removed.

So I would prefer to wait until SFML 2.1 is released before reïmplementing this in label.

And for widgets like button, I think you are responsible for setting a text size that fits inside it (or set text size to 0 to auto-scale).

It depends on how doxygen is configured. Currently it is the second situation.

What I can do is to make the function pure virtual and add empty functions to the derived classes with a documentation saying that the function does nothing.

The widgets that don't implement a setSize function are: Label, Grid, MenuBar and Tab.
And label actually already has a not-working setSize function.

Maybe I'll find some alternative uage for the function (e.g. for tabs set the height and maximum tab width for a single tab instead of width and height for the whole widget).

I wouldn't mind having a setSize in Widget, I even already wanted to do this before.

But what bothered me whas that Label and Grid (and possibly others) don't have a setSize function.
I could do what you say and just not implement them, but someone might see that label has a setSize function and might try to use it. And then unexpectedly, the function call wouldn't had any effect.

Basically I didn't move the function to Widget because it wasn't needed. And I didn't see a reason to create confusion for nothing. But if it helps then I will do it. It would also allow having a setScale function for every object.

So I'll make the change and you'll hear from my again tomorrow (or in a few hours if everything goes very well).

No, I don't think that will work.
Maybe in the future when loading from memory gets written.

But if you don't use any other windows specific code then you might not want to use such resources to keep the code cross-platform.

If you want to write a tutorial, be my guest.
It takes too much time to do everything myself.

Here is the example code:

Code (cpp) Select Expand

#include <TGUI/TGUI.hpp>

void scrollbarValueChanged(const tgui::Callback& callback)
{
    tgui::Container* gui = callback.widget->getParent();

    // Reposition the pictures
    for (int i = 0; i < 10; ++i)
    {
        tgui::Picture::Ptr pic = gui->get(tgui::to_string(i));
        pic->setPosition(0, (i - callback.value) * 150);
    }
}

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

    // Create 10 images displayed below each other
    for (unsigned int i = 0; i < 10; ++i)
    {
        tgui::Picture::Ptr pic(gui, tgui::to_string(i));
        pic->load("image" + tgui::to_string(i) + ".png");
        pic->setSize(200, 150);
        pic->setPosition(0, i * 150);
    }

    // Create the scrollbar
    tgui::Scrollbar::Ptr scrollbar(gui, "Scrollbar");
    scrollbar->load("TGUI/widgets/Black.conf");
    scrollbar->setLowValue(4); // 4 images fit inside the window
    scrollbar->setMaximum(10); // 10 images in total
    scrollbar->setSize(20, 600);
    scrollbar->setPosition(200, 0);
    scrollbar->bindCallbackEx(scrollbarValueChanged, tgui::Scrollbar::ValueChanged);

    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();
    }
}

If you want smooth scrolling however, instead of seeing the images jump, then you have to make a few changes to that code.
- LowValue should become 600 (instead of 4), because you are now counting the pixels instead of the images.
- Maximum should become 1500 (instead of 10), because that is the amount of pixels that all images take together in this example.
- The pictures should be set to an y value of "i * 150 - callback.value", instead of "(i - callback.value) * 150".

If you have space inbetween the images or images from other sizes then these values will obviously change. Just keep in mind that LowValue are the visible pixels and Maximum the total number of pixels that you will be able to see.

Although this will look a lot better, there is a limitation in tgui. Because the arrows of the scrollbar always change the value by 1, they will only move the images one pixel and are thus useless.

And I just noticed a bug that when scrolling the mouse wheel on top of the scrollbar, no callback is being send. I'll fix that later today.

AnimatedPicture was actually made for animations of small images. Although you can use it for what you are doing, it might not be the best solution.

As you noticed the ram memory can get pretty high when loading all those big frames. Usually in situations like this you don't load everything on startup but you kinda stream from your disk. Only load a few images and after every frame, load the next one and forget about the previous one.
Or you can use a project like sfeMovie that plays the video directly instead of splitting it into images.

What is the size of all those images btw? How much mb are they on your disk?

The second code gives your minimum ram usage, you can't go below that.
If you make your images smaller then there is of course less to be placed in memory so that way you could still lower your memory usage a bit though.

The first code is like it is done in tgui and as you saw it uses a lot more memory.

My problem is now that I have to choose wheter or not I change my texture manager to use less memory and use something like the second code instead of like the first code. But if I do this it will no longer be possible to acess the pixel data and thus check for transparent pixels (could be nice when you have a picture of a portrait frame and you want the mouse clicks to work when you click through the transparent part in the middle on the objects behind it).
So it's either use more ram memory, or use less memory without the possibility to acess the pixel data.

Does it actually matter to you that it uses more ram, or can you live with it?

I never had such problem before so all I can do is just guess.
You said that sfml itself works, so that rules out driver issues...

But just to be absolutely sure, does the example code really shows a black screen?
And don't change anything about it. Just compile the exact code as it is found in the 'example code' folder. Place the executable there and run it from that folder, not from codeblocks.
Only then I can be 100% sure that it can't be a problem in the code.

Also another thing to make sure, the sfml libs are the ones from the sfml site right? Not some newer version compiled from github.

Then you could try recompiling tgui yourself, but I'm not sure if that is going to change anything.
And if that doesn't work then I'm out of ideas.

Thats because the libraries aren't linked in the right order.
The correct linking order is tgui, sfml-graphics, sfml-window, sfml-system.
So you should put tgui on top of that list instead of at the bottom.