Messages

My basic auto resizing is up and running. When the window resizes, widget can change it's position and size.

Code (cpp) Select Expand


class ResizeBehaviour
{
public:
bool changeX = false;
bool changeY = false;
bool changeWidth = false;
bool changeHeight = false;
};


In my main Gui class (which controlls callbacks etc) I have:

Code (cpp) Select Expand


std::vector<std::pair<tgui::Widget::Ptr, ResizeBehaviour>> m_widgets;

ResizeBehaviour & addWidget(tgui::Widget::Ptr wptr);


I use it like this inside gui class:

Code (cpp) Select Expand


tgui::Wiget::Ptr widget(tgui);
auto rb = addWiget(widget);
rb.changeWidth = true;
rb.changeHeight = true;


And then when resizing, the widget keeps its position but changes its size according to resize delta.
There is simple code which does this:

Code (cpp) Select Expand


if (m_app.input.isResized())
{
auto delta = m_app.input.getResizeDelta(); //it's vector2i

for (auto &i : m_widgets)
{
auto position = i.first->getPosition();
auto size = i.first->getSize();

if (i.second.changeX)
{
i.first->setPosition(position.x + delta.x, position.y);
position = i.first->getPosition();
}
if (i.second.changeY) i.first->setPosition(position.x, position.y + delta.y);

if (i.second.changeWidth)
{
i.first->setSize(size.x + delta.x, size.y);
size = i.first->getSize();
}
if (i.second.changeHeight) i.first->setSize(size.x, size.y + delta.y);
}
       }


It works very well. It's nothing like fancy layouting but it does its job and doesn't force you to write hundreds of onResize functions (I used to do that, meh!). Actually with little effort I have now a nice resizable layout in my gui!

Now my question is if you'd like to see it in TGUI (for example until you write layouting which as you said won't be complete in 0.6). We could discuss how I can change it to integrate it into TGUI in clean way.
Of course I understand that it isn't commonly used way to handle resizing - I created it for my very specific needs. So tell me what you think, if it's worth to implement something like that inside TGUI.

I think it's a bug:

- in widgets/Slider2D there is black.conf file (there should be just one global I think)
- in widgets/Slider2D there is no BabyBlue folder
- in global BabyBlue.conf and Black.conf there is no mention of slider 2D

Check it out yourself.

Thanks a lot

Yes, 0.5 labels are exactly what I need. Thank you that you will implement it

I think clipping optimization will come automatically with SFML 2.1 release (and we must agree that 90% of TGUI users/users of our games use Windows so no problem there on 2.0).

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).

Keep in mind that you draw 60 times a second and you setSize basically only when initializing app or resizing it. Also operating on sf::Text isn't that slow.

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.

I know that layout system is so hard to design that you won't make it quickly. I mean the semi automatic pseudo-layouting on which I'm working right now. That's what's enough for me. The change in tgui::Transformable was enough to make it happen. Now only text clipping issue is left.

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

For example when resizing using my method the labels' size is reduced, I don't want the text to be messed up (eg outside of the layout) but I want the text size to be actually reduced. The same applies to button of course.

If you don't want to implement any of the 2 forms of clipping at this stage, then auto font size with option to set maximum size could work as a workaround for a few months.

I think I have a solution for label without clipping!
Basically inside label there are 2 strings - full text and displayed text. If full text doesn't fit inside the label, then the displayed text string is cut and converted to sf::Text. Of course it's not the fastest operation but it only happens when you setSize to label (so only when you resize/create the window).

What do you think? The same should be applied to button.

I think it's great and clean solution.

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.

How are you now making sure that text in chat box fits inside it?

Thank you.

I understand. 0.6 is a development release so I think that you can safely reimplement label clipping (anyone wanting production quality should use stable version anyway). SFML 2.1 may be released in few months and it will probably happen before tgui 0.6 goes stable.

However, you can do it when you want. I will just wait.

SFML 2.1 may as well be released in 2015. I see 2 solutions here:

1) Encourage people to use github version (okay, this may be hard when someone want to redistribute game with stable SFML package) so it's bad for most ppl unless someone like me provides his own libs with game on linux and uses rpath.

2) Cache window size during resize event in tgui. It requires a bit of work though.

EDIT:

3) Use other algorithm that works only on text's texture and ignores window size ^^

I think that editbox does it (and probably chatbox as well).

Label should allow to set its size and if the text doesn't fit inside it then the text will be cut (very important step to implement resizing). The same should apply to text on buttons etc.

What do you think?

Gui libs like QT etc implement this.

Pure virtual seems like a good choice.

Edit:

Look at my new topic in feature requests - it adds another usage for setSize that currently does nothing.

Thanks

On the unexpected usage when it's empty - I don't know how doxygen works, but if you set description in widget::set/getSize() that it does nothing and don't implement it in children class, will the description from base class appear or no description at all? If it's the first case then problem is solved.

Edit:

Important thing is that virtual getSize() must be implemented as well. I think it should return empty vector by default, so it's shows 0x0 dimensions ie no size at all.

I'm currently working on something I really need and I call it "semi-automatic resize handling". The idea is very simple:

Code (cpp) Select Expand


classs GuiManager
{
   std::map<tgui::Widget::Ptr, ResizeBehaviour> widgets; //I store pointers to widget in this class
};

struct ResizeBehaviour
{
  bool changeX = false;
  bool changeY = false;
  bool changeWidth = false;
  bool changeHeight = false;
};

Then we have function:

GuiManger::handleResize(int deltaX, int deltaY) //called when resize SFML event happens
{
   //when a widget has for example changeX set to true
   //then widget->x += deltaX etc.
}


This allows for very basic layouting (altough I use similar method and it works very well for handling resizing in gui!).
My problem is that tgui::Widget doesn't have virtual set/get Size function. Thus I can't make it as simple as in the above code.

What is the reason why there can't be even empty virtual setSize function in widget? Basically every widget has its size (unless it's container widget and then we can happily don't implement the virtual function body).

It's very simple way of handling basically the biggest TGUI problem (at least for me) and after some tuning (this code isn't really integrated into TGUI) I could write a patch.

However I really need that size in tgui::Widget class. Is it possible to place empty virtual function in the class? I think it won't hurt.

If it's not possible, do you have any other idea how I can workaround it?

I agree that if someone doesn't have experience with scrollbar, they are a bit hard to understand at first. I think some example code would be good and should be written.