Messages

I have though about XML, but I kindof see JSON as its successor.
XML requires you to open and close tags which means you have to write things twice.

I would choose the second or third opposed to the first one. The third one looks best here, but these key-value pairs like now are too limited.

Code Select Expand

<TextSize>5</TextSize>
"TextSize" : 5
TextSize = 5

While 2nd and 3rd are more human-readable, the question is if you would write them manually in the first place. If I wouldn't use the GUI builder, I'd do it programmatically in my .cpp files.
Hm. And file size shouldn't be a concern. If I were not to use xml I'd probably go for JSON  instead of the 3rd option, simply because libconfig uses ascii for strings which is undesirable if you do ButtonText = "MinButtøn".

Hello Bruno,

Have you given thought to using XML format?
I am extensively using custom XML config files myself and read and write them with tinyxml https://www.grinninglizard.com/tinyxml2/. It's fast and header-only.
However, tinyxml does not understand DTDs for validation. If you go for XML, check this helpful image:
https://i.stack.imgur.com/hUjpw.png

[spoiler]I still owe you that 0.7 tutorial, I'm a huge slacker

Just in case you didn't know this yet: in v0.7 you don't need a separate file for every button. You can have multiple sections for buttons (or other widgets), just give them a name other than the default "Button" and pass the name as second parameter of the Button::create function.

I didn't. That's pretty handy.

I read this on your blog

Thinking about a new design...

// Load one theme that is shared between widgets
tgui::Theme theme{"Black.conf"};

// Create widgets based on that theme
auto button = tgui::Button::create(theme);

// Change the theme for all connected widgets on the fly
theme->changeProperty("Button", "TextColorNormal", "(200, 200, 200)");

Wow, this sounds good. What would happen if I create an element with a theme object and later I want to change a property on this element only? Reminds me a little of the setGlobalTextSize() issues.

A short user story how I use tgui:
I have several game states (startup, main menu, game lobby, game room, ..). No two states can be active at the same time. I share a global tgui::gui between all states. When a new state is transitioned into, all widgets get removed from the global tgui::gui and the specific state widgets get reloaded.
Each state has it's own gui elements and it's own theme.conf. On state creation I load everything with element::create("myState.conf") and hide() and show() and connect() accordingly. Then on some elements, I change properties via getRenderer() because I didn't want an extra theme.conf for a single Button. Sometimes gui elements need to be created dynamically. That is, when game objects offer to be configured. These objects have a tgui::Widget::Ptr getConfigWidget() interface and the state loops over the objects to get the widgets and add them to the tgui::gui.

It would be great if there were tutorials written by the tgui users .

Sounds like something I could do.
The bug is really minor, I just thought I report it before I forget about it.

BTW, I found a little bug. When a listbox is populated with items and you "drag an entry downward" over the last entry in the list. Like, you click on an entry and do not release the mouse button and then move the mouse cursor downward until you pass the last entry in the list. The Listbox must have set it's size large enough that there is some space displayed below the last entry. Then tgui crashes with some subscript out of range error.
If you have some spare time you may try to reproduce it. No signal needs to be connected for this.

There is no single list containing all signals.

Yes, I found it in ListBox.cpp, thats why I meant you should maybe compile a list for new users.

Where can I find one? I'm especially looking for something like "selected" in listbox.

Edit: I found where they are defined. Maybe you want to compile a list for your tutorial.

But by the time you add a widget to its parent you could have already set a size manually and there is currently no way to detect that.

Well, you could do setGlobalDefaultTextSize(int size) which would simply set a default but not change anything and setGlobalTextSize(int size) which overwrites everything. But I do not want to mess your API up further.

I can write such a getGuiTextSize function for you, but then you still have to apply it for every widget .

Thanks, but I have such a function, the suggestion is for other users. You could put something like this internally into the widget creation code.

Myself, I will stick to mine anyway since I really do set this everytime in my code as I create a widget. Actually the function is static unsigned int Settings::getGuiTextSize(Globals::TXTSIZE size) // sizes are TXTSIZE::HEADING and so on. This is an artifact, it should rather be named LARGE, NORMAL SMALL. getGuiTextSize(Globals::TXTSIZE size = Globals::TXTSIZE::NORMAL), now that I think of it.
Be careful not to accidentally write an html renderer 

Oftentimes my code looks like


widget = create();
widget->setTextSize(Globals::getGuiTextSize());

I understand why one would not to. Myself, I have a static class called settings where I store some global variables like fontSize, paths, videomode, audiovolume, etc

It should be defined whether it adjusts widgets that are already created and/or widgets that are created later

A change should propagate to all widgets. Like so.

setGlobalFontSize(12);
widget a;  // (is size 12);
setGlobalFontSize(14);
widget b;  // (is size 14);

getSize(a) //14
getSize(b) //14

  While I'm at it; Currently text is centered inside a button by computing the center of it's axis-aligned bounding box.  Which is good. However, this bounding box depends on what glyphs you used, for example 'A's center is higher than 'j's center. The consequence is, that the base line of text does not align if you have words containing an Ascender(https://en.wikipedia.org/wiki/Ascender_%28typography%29)  and one that does not. Same for descenders. Image probably says more than words:

Note how "Hangar" has a glyph with a descender (the 'g') and "Join" has not. Vertically this looks correct most of the time (unless your word is long and contains a single Descender, then it looks as if it was too high in it's button)  because the text seems to be correctly centered. Horizontally it looks jumbled. Depending on the Font size this can be more or less noticeable. A solution would be to compute the center by using it's baseline glyphs only. I agree this is not an urgent issue.

Oftentimes my code looks like


widget = create();
widget->setTextSize(Globals::getGuiTextSize());


Having it as a parameter in .conf files would also be an option. Well, this is for people who want the same font size in all their widgets anyway.

Also: Currently it is imho impossible to change the text size of entries in tgui::combobox. Even when I get the renderer for the widget. Also the sf::text is never exposed, so getting the text somehow and setting it there doesn't work either.

What do you think?

Alright, it compiles and works.
Some small bug I noticed in 0.6 already that still persists. Probably it's from sfml.

Not at all, I'm always glad to see that someone uses tgui.It's probably more annoying for you to constantly hit on a bug than it is for me to fix them or answer questions.

They get fixed in a matter of hours. I still maintain the notion that tgui fits my needs almost perfectly. Maybe there will be a day when you can boast about being the creator of tgui (boastings will be totally unrelated ro my little hobby project I'm using it for .

You have no idea how much work it cost me to be able to copy these signals .
This is indeed something that should be looked at. But I think I'm going to wait for more feedback and review this later.

Sure, my personal rationale is that when I copy an element, I copy it's appearance and set new semantics for it. The other approach would be copying a buttons semantics but give it a new look.

It's should be fixed now.

Thank you. You're the best.

BTW: I hope you do not feel annoyed at my many requests.
Small suggestion: Currently, when you tgui::Button::copy(aButton), the tgui::Button::connect(func) also gets copied. I think this is seldom what the user wants if he copies a button.

As soon as I try to call setNormalImage() manually, I get a single unresolved external for it.

error LNK2019: unresolved external symbol "public: void __thiscall tgui::ButtonRenderer::setNormalImage(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,class sf::Rect<int> const &,class sf::Rect<int> const &,bool)" (?setNormalImage@ButtonRenderer@tgui@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ABV?$Rect@H@sf@@1_N@Z) referenced in function "private: void __thiscall EditorGUI::rebuildWorkbenchPanel(void)" (?rebuildWorkbenchPanel@EditorGUI@@AAEXXZ)

You can do this in v0.7 by accessing the renderer. It has functions for changing any property that was loaded from the theme file.

Silly me, didn't notice the getRenderer().

I'd like it. What do you think? Probably in every Widget. For changing the Button texture dynamically.

It think it would really come in handy to have a method that specifies how child widgets should be positioned (e.g. center horizontally, center vertically, default=none). In my use case, I have a Panel and a Grid inside this Panel, now I want to have the Grid centered inside the panel.
Also: Grid has a method for changing the alignment of a widget inside one cell, for convenience, a method to change every cell would be nice.  However, I may be overseeing some possibilities tgui provides.

Are there pitfalls on having multiple GUI objects? Or is it recommended to have one and only one GUI object (and access it via Singleton or something).

Leave it be for a refactoring of Grid in the future, then, I'll just call add() meanwhile.
Now for something completely different, do you have any suggestions?
I am using my own little State manager that works like this:


virtual class State { virtual State* run();};
class SomeState: public State { State* run(){return new SomeOtherState();} };
main(){
State* state = new SomeState();
while(state != SomeQuitState)
{ state = state->run();}
}


The run() method of a State was usually one of these SFML while(window.isOpen()) loops that also did a tgui::pollcallback() to see if e.g. a closebutton has been pressed and then returned a new state (e.g. Quit). Now, with the new function callbacks in 0.7 this is no longer possible, because I cannot call return inside the run() method anymore. As a workaround, I could set flags in State and then switchCase those flags to see if I should return a state. Do you have any brilliant design idea to get around this?

I had a quick glance over your code. I see Container maintains a list of widgets and Grid inherits this list but never uses it, instead using it's own grid_widget list for everything, including drawing. The hook is, widgetPtr->initialize(this); is only called in Container::add().

Sorry, I edited my post while you were answering. It does indeed work without your workaround (in fact I was adding the grid before I added widgets to the grid ever since). The problem was that I only grid->addWidget() them, but not also grid->add() them. Turns out one needs to do both.