Buttons 0.9

What should be optional exactly?

maybe i misunderstand something here. I thought that you using setKeyRepeatEnabled with true parameter inside TGUI but that's is not happening. Correct?

setPressRepeat(sf::Time duration)

that is how i imagined that. Great.

So I think it might be better to add a function that prevents the button from gaining focus, instead of adding a function that disables space and return.

I don't mind at all. Having a disableFocusEvent function is also good enough for me.

Every text can have its own vertical and horizontal alignment on a given position inside the button. YES to position inside and YES to both alignments.

First you can add alignment. Right now you have both center in button as default. You can add setHorizontalAlignment and setVerticalAlignment like label and half of the problem goes away. If additionally there is a fuction "setRelativeTextPosition(Layout x, Layout y)"  then you do not calculate the cente pos of button but you use this one obeying the alignements and letting this on user.

maybe i misunderstand something here. I thought that you using setKeyRepeatEnabled with true parameter inside TGUI but that's is not happening. Correct?

TGUI doesn't call the function. I meant that the TGUI behavior would change if you called that function in your code and the button only works like described when key repeating is set to true (default).

You can add setHorizontalAlignment and setVerticalAlignment like label and half of the problem goes away.

I feel like for buttons these functions belong in the ButtonRenderer class because they are about how a button will be rendered (unlike in Label where they are about how to align the label with other widgets), but I'll probably have to put them in the Button class. Functions like these really make me question if I wouldn't be able to find a better design to split widgets and their renderers.

I'm also not sure what do with the distance from the side yet. This is an issue that affects many widgets. If you put the text on the left side, do you expect it to start at pixel 0? This is how it looked in 0.7 and it looked terrible (because the black text touched the black border on the left). In 0.8 I added a small fixed margin between the side and the text to improve it. In 0.9-dev I was planning on making the margin even larger because I'm still not happy on how it looks with small texts. If you were to set setRelativeTextPosition(0,0) there would still be some space next to the text. This might be good because you probably don't really want the text against the side, but it might be unexpected as you are specifying (0,0). In this case adding a padding would solve the issue (although a default padding that isn't 0 is weird too), but in other widgets like ListView the distance is needed to keep the texts away from the column separators and a padding property isn't appropriate there (since there already is a padding but it goes around the entire list).
This is of course a whole different discussion, but depending on what you want when setting setRelativeTextPosition(0,0), the current implementation that placed a small space next to every text might be an issue.

A. Now you center the text both vertical and horizontal in center of button, correct? So a "setMargin(value), getMargin()" make thing simpler.

B. Image show the proper use of setRelativePos, SetHorzontalAlign, SetVerticalAlign.

If you were to set setRelativeTextPosition(0,0) there would still be some space next to the text

I can't see why you bother about the space next to text or even in front of it or up or down if someone sets new relative position?

I can't see why you bother about the space next to text or even in front of it or up or down if someone sets new relative position?

Because the space could potentially be implemented in the Text class itself instead of having to add the margin in practically every widget. But 0.9 probably won't even have a Text class anymore, so we'll see how it turns out.

I've decided to not implement the text positioning now and first work on rewriting the core of the gui before further looking into it. One of the goals in 0.9 is to figure out how to make it easier for the user to implement custom customizations on top of what TGUI provides and I feel like I should try to get that in a working state before looking at which extra customizations can be provided out of the box.
Figuring out how to best allow the user position the text makes me think about other changes as well. I have similar "issues" with e.g. the Tab widget: how do I allow users to control where they put the text. If there was an icon in the tab then the text could be next to it, or below it or above it. There should be a distance to the sides of the tab and another distance between the text and icon. Both the icons and text should be sizeable as well. There is a huge amount of minor tweaks that the user might want to make and it is a lot of work to provide them. Just thinking about all the different customizations that I would have to provide makes me want to stop working on it .

Take a look at http://en.fairygui.com/

http://en.fairygui.com/examples/ examples running on browser.

What exactly do you want to me to look at with that gui?
FairyGUI looks great, and they focus completely on games, 2 things you can't say about TGUI

I'm currently unsure how TGUI should continue in 0.9. There are just too many customizations to implement to really have a tunable gui (and I don't have the time to implement them). So I want to provide some way that the user can write their own code to extend the widgets. That way they can still do complex things (as I can't provide code for every scenario) while it would also be possible for me to sometimes merge the code back into TGUI to provide the functionality for everyone.

I'm completely stuck on a design for this though. The current design doesn't make it easy to extend the widgets at all, you would have to inherit both the widget and the renderer and override multiple functions. I was thinking about moving the draw function to the renderer so that most of the time you only need to inherit from the renderer. The issues with splitting the code in 2 part still remain though: mouse event functions and draw functions need to be equivalent, mouse press needs to know about borders, padding and spaces between items, which would all depend on the custom draw function.

Merging the widget and renderer into a single class again would simplify things and probably make it easier to extend it, but it probably makes it more difficult to implement skins. I tried looking into the code of some other guis but they usually have a complex structure. That is probably good for the extendability but I want to keep TGUI easy to use as well. It don't want to e.g. make it more difficult to have a simple list box with some strings just because someone may want to create a list box with subwidgets.

So instead of thinking about all that, I'm currently just spending my spare time playing borderlands 2, which is why I haven't responded for a few days

What exactly do you want to me to look at with that gui?

Nothing really. Just to take a look. I haven't used fairygui yet but i was looking for an alternative among other libraries if some project of mine wanted advance features for gui. In my programming years i have use wxWidgets, QT and dotnet. However the last years since i abandoned "MARMALADE" (in fact they abandoned us in first place) i am using sfml and tgui which tgui is great since i never had any problems.
 
Take a breath.
Batch rendering is great but after the performance boost in latest versions is not completely necessary.
Instead of rewriting the whole project why don't you add the missing widgets.
Yesterday is saw default argument in "ignoreMouseEvents" (picture). Ok, why setEnabled or setVisible on the other hand don't have.
There are a lot of tiny improvements that can be done. Like having all those "signalNames" for all widgets in one place!
I know the worm of perfection since i have one but life is also fun..

Yesterday is saw default argument in "ignoreMouseEvents" (picture). Ok, why setEnabled or setVisible on the other hand don't have.

Because setEnabled and setVisible are equally likely to be called with true or false while you would only call ignoreMouseEvents with true (as false is the default and you typically don't toggle that property). That being said, I know that some function have default arguments while others don't where I can't make such a clear distinction. The problem is that I don't really like the default arguments as I feel like people might incorrectly see them as an indication of what the default is when the function isn't called and the default parameter value is usually the exact opposite of the default value used by the widget. So in more recent additions I didn't add a default argument at all.

Instead of rewriting the whole project why don't you add the missing widgets.

Because widgets and extra functions can always be contributed by others, nobody other than me is going to change the architecture of the entire gui.
I also tend to work in 2 phases, during development of a new version I can change the API so I try to change as much as possible at once while after the API gets more stable again I can focus on adding functionality that doesn't break the API (such as adding new widgets). By spending too much time in the unstable phase I always end up dividing the community in 2 versions (those using the older stable version and those using the newest unstable version), so I don't want this phase to last longer than 1-2 years. So things that can be done after tha API gets stable tend to get delayed during early development of a new version.

There are a lot of tiny improvements that can be done. Like having all those "signalNames" for all widgets in one place!

This is hard to do with the inheritance. I'm also planning on a system like using the onSignal objects directly instead of using the signal names so it might get even more difficult to get things in one place.