Messages

I just remembered that since v0.8.4 you can also just use the "Changed" signal instead of connecting to both checked and unchecked.

The functionality wasn't removed, just changed. There is a connect function that takes an initializer_list as parameter, so you now have to write the following:

Code (cpp) Select Expand

my_checkbox->connect({"checked", "unchecked"}, [](bool status){ std::cout << status << '\n'; });

Feel free to copy the code.

This does look like a bug in the compiler itself. It isn't the first time the signal code has given issues with different compilers (I had compile issues with GCC, clang an VC++), but these were all solved before the new signal code was released. So it seems like they changed something in VS2019 which causes it to fail to parse the code properly. Technically this is not an issue with my code (unless it turns out I would be using code that isn't compliant with the c++ standard which shouldn't be the case here) and it should be fixed by the compiler developers.
The only thing that can be done from my side is rewrite the code a little bit in the hope that the compiler suddenly supports it (the other compiler issues were also solved that way, by simplifying the code, such as turning one long line into two lines).

TGUI_USE_CPP17 is not something you need to define. I couldn't use c++17 code in TGUI for compatibility reasons but I still wanted to play around with c++17 so I added some code behind the undocumented TGUI_USE_CPP17 define. If the error you got would have been inside part of the code where a c++17 alternative was available then it could have just been solved by defining it, but that isn't the case here.

Line 148 in SignalImpl.hpp is on a opening brace, so it is hard to say if it fails on the line above or below, but I would guess it is on the line above. Could you try changing "decltype(auto)" on line 147 to "std::function<void()>" (and maybe also on line 155) and maybe also change the "{}" to "()" after index_sequence_for on line 149 to see if it compiles with these changes?
If it still doesn't compile after these changes then there isn't much I can do, I don't see any other ways to simplify that code more. It compiles fine with all other compilers, so it would be something that VS2019 needs to solve.

Is it possible that your font just renders that way? Because the only thing the ChatBox should be doing is adding newline characters at the end of the line, I don't think it positions those lines manually.

Are texts overlapping for you? The lines should just be positioned below each other. It still works with some simple code here.

In gui.txt just add "OpacityDisabled = 0.3" in ChildWindow section and the code will hung  in "mGuiTheme.load("resources/gui.txt");"

I can't reproduce hanging, but last time you said "gave me an exception" so I'm assuming that is still what you mean. The reason is probably because you forgot a semi-colon behind the line (if you catch the tgui::Exception that gets thrown it will likely tell you that parsing failed on that line, maybe even mentioning which character it read). You forgot this for all widgets, but the parser is more forgiving when it is the very last line in the section.

However there is a problem with menubar and opacity of texts color when they get enabled.

It definitely looks like that with the White theme, but if the issue you were seeing is the one that I just fixed then the problem was actually just the text color, not the opacity.

Also a setopacitydisable value in gui.txt for messagebox gave me an exception.

Did you make a typo when making the forum post or are you actually using "setopacitydisable"? Because it should be "opacitydisabled" (without "set" in front and with a "d" at the end).

Now we have something, i think.

Yep, you did a great job.
Now we just need to get it integrated with TGUI.

Do you think there should be a downloadable exe for the example on the website? If so, maybe you could build the executable statically (including linking statically to standard library) so that it can run on any computer. It would require rebuilding SFML with SFML_USE_STATIC_STD_LIBS and TGUI with TGUI_USE_STATIC_STD_LIBS.

Something should still be done about gnu-freefont_freeserif.zip. The KitchenSink folder is 6.2MB of which 4.3MB is an unused zip file. Whether you keep all the files or except for the font files or whether you do what I suggested earlier ("Maybe the font should be moved to a new subfolder which would contain the README, FreeSerifBold.otf, CREDITS, COPYING and AUTHORS files.") is up to you. When the example gets included with TGUI, every download is going to increase by the size of that KitchenSink folder. For this reason it might also be better to not ship the gui.psd file with the project either, it almost takes up half of the size if you remove the zip. If there is going to be a page on the website about the example I can still put the psd file there.
(I know my tests folder is a few MB too where it could also be argued that it shouldn't be in the project either if I want to keep things small, but that isn't an excuse to add even more bloat than there already is).

The issue with the knob not responding has been fixed, but you also need to add "ImageRotation = 90;" to the theme to make it point in the right direction.

Maybe you could make a base class with virtual functions for all these tabs? Then you could get rid of the switch cases in processEvents, update and on top of loadTab in cKitchenSink.
Are the cases in cVirtualKeyboard::handleEvent needed? Can't you just check if "index != -1"?

I'm happy with how it looks. The code style and naming of variables isn't exactly the same as used internally in TGUI, but that is fine for example code, everyone is going to have their own convention anyway.
I've only briefly looked at the code. Some code improvements could be made such as replacing raw arrays with std::array and using more modern c++ for randoms, but those aren't important changes, I'm fine with the code being like it is now. The code can always be improved in the future.

I added "gnu-freefont_freeserif.zip" because it contains credit file for author and maybe it should added in resources.

I agree that the credits should be included, but that zip contains several different fonts of which only one is needed, so it is wasted space. Maybe the font should be moved to a new subfolder which would contain the README, FreeSerifBold.otf, CREDITS, COPYING and AUTHORS files. I don't think we need to keep the INSTALL, CHANGELOG and other font files. I would keep the README just because it contains the exception that allows the font to be used without requiring the program to be licensed under GPL.

I really can not figure out why the label with scroll bar do not show the beginning of the text.

I can't reproduce this. If I don't call setScrollbarPolicy then it only shows the start of the text as expected, but I don't know in what situation it would only show the end of the text.
Edit: I didn't look at the program yet, so I didn't see you already included the label. I'll have a look at the code later to figure out why it is happening.
Edit2: The issue is with setVerticalAlignment(Center), but you probably shouldn't be using that anyway when you have a vertical scrollbar.
Edit3: Fixed.

Also, i can't set min max form size on a message box.

Message box wasn't supposed to be resized and it's size would depend on the contents. A maximum size would be useful as it would allow word-wrapping on the text. For the label the behavior is simple, but I'm not sure what to do if the buttons exceed the size. The whole widget probably needs an overhaul, maybe also making the sizes of the buttons and the spaces between them configurable. So this probably isn't something that I would implement on short-term.

- SFML_libs.hpp is specific to Visual Studio and should indeed be removed once this gets integrated with the TGUI examples which compile and link with cmake.
- defines.hpp should be removed. Not because the file is so small, but because I actually don't want to see SAFE_DELETE being used. TGUI tries to be a modern c++ library, it already requires c++14 as a minimum, so it would be best if the examples didn't use new and delete. Based on a quick glance at the code I think it could be replaced with std::unique_ptr.
- Why was defineImprovedEnum.h used? Are there places where it is used where a normal enum was be too limited?

Some minor comments:
- gnu-freefont_freeserif.zip and flags/Thumb.db in the resources folder can be removed I guess.
- Text colors of radio buttons in "Buttons" tab aren't the same (only the first one is really readable)
- The themed knob doesn't move correctly. ImageRotation in gui.txt should be 90, the current value seems to be a copy-paste error.
- I don't really like the horizontal scrollbar for ScrollablePanel as there is no contents to the right. Calling panel->setHorizontalScrollbarPolicy(Scrollbar::Policy::Never) would probably be better in this case (or changing the content width to not include the vertical scrollbar).
- A label with scrollbar would really look great on the first tab

I'll put a link to this forum topic on discord tomorrow so that your work gets a few more views.

The above code kills the selected tab. When a tab bar goes disabled must not lose his selected index.

Fixed.

The above code (setting new font) sets all text data in scrollpanel to lowercase.

I can't reproduce it. I also don't see how the font could affect the string data. If the font you are setting has capital letters then you should create a minimal program and post it together with the font.

In the future I should probably find a better solution so that I can add it to all widgets with a scrollbar without lots of code duplication, but for now I just added setVerticalScrollAmount and setHorizontalScrollAmount functions to the ScrollablePanel class. You can download the latest version from github.

I have some hard times with "ScrollablePanel"

Theme files just don't work like that, you can't reference to another section (it would be nice if it was possible though, then you wouldn't have to repeat the information). It should look like this:

Code (ini) Select Expand

ScrollablePanel {
    BackgroundColor = rgba(100, 100, 100, 255);
    BorderColor     = rgba(0, 0, 0 , 255);
    Borders         = (1, 1, 1, 1);
    OpacityDisabled = 0.3;
}

I think knobs need some improvements.

Yeah, that widget didn't get much attention, it only has minimal functionality.

I haven't worked with knobs a lot, so it is possible that I'm disagreeing with some of these things due to lack of experience, but I don't agree that the improvements you suggest should be how the knob works. Maybe such behavior should be optional and even if I decide not to make them the default I could still add an option to make them work that way.

I can think of some situations where you would want such behavior, so maybe there are just 2 different types of knobs: those that simulate real-world knobs and those that just exist to select a value.
The kind of knob I tend to think about falls in the second category (examples, other example). They react immediately on mouse down and the value follows the mouse position, even if it crosses from 100% to 0% or passes through the center of the knob from 25% to 75%.

When i pressed down left mouse the indicator must no be moved to the direction of mouse point but only if i start moving the mouse while it still down.

I guess this also means that you want the knob to move based on how much you move the mouse as opposed to jumping straight to the mouse position?

Also when i double click on them they should reset.

Is this some kind of standard behavior somewhere? This could be done in user code if a DoubleClick event existed.

Also they must stop on min or max and not moving around.

That doesn't sound so easy to implement. It means the thumb must not jump to your mouse position but follow the movements you make. In such scenario I'm not sure how the thumb should respond if you move the mouse through the center of the knob to the other side.

Almost finished.

Looking even better.
I with I could run it in a browser and put it on the webpage. Maybe with TGUI 0.9, or maybe SFML adds support for emscripten, who knows.
Part of me still can't believe that that ListView was rendered with TGUI

Some more nitpicking:
- When you close the keyboard, the "Buttons" tab is no longer selected.
- In Misc2, shouldn't it say "Grid" instead of "Group"?

I can't think of a reason. It seems to be missing in scrollbar too.
Usually the state is called "down" instead of "pressed", but that might be unclear here.

Now that you mention it, it does sound like that. Maybe I should rename it to setTimeBeforeDisplay or setTimeBeforeShowing?

If you added it to the widget with setTooltip then it should show up on the bottom right of your mouse cursor (4 pixels to the right and 8 pixels down in this case) if put the mouse on top of the widget and don't move it for more than a second. You shouldn't have to call pLabelToolTip->setPosition at all, unless you want to add an extra offset to the tooltip which other widgets don't have.

Is there nothing in front of the clickable widget?

Are you calling something like "gui.add(pLabelToolTip)" somewhere by any chance?
pLabelToolTip->setPosition shouldn't be called like that. The position will be relative to the mouse.

I've added a TextureBackground property to the label renderer.

I really like how it looks, but I got some minor feedbacks on some parts.
- On the "Labels" tab it also says "Canvas", is that something you are still going to add there or am I missing something?
- Labels can do more than demonstrated. Maybe at the bottom you can have a label with a lot of text in it, so that it gets a vertical scrollbar. There is also the possibility for a Label to have word-wrap by setting a width without setting a maximum height (via setMaximumTextWidth), although showing the version with a scrollbar is probably more important to showcase.
- Maybe "Double click me" would be better than "Click me double"?
- The arrow buttons in the Buttons tab don't seem to have a separate hover and down states. They might look better if the entire rectangle become a little more white when hovered and only gets the black arrow when in down state.
- Maybe pressing the Button0 again should switch it back to the original state? After you clicked on them you can see what they did but it is too late to actually pay attention to it. It is arguable that it serves mostly so you can see how to do it in the code, but then you might as well not switch the text at all.
- The "Button theme2", "Button theme3" and "Button theme4" buttons are probably named that way because they are "themed" button number X, but when I saw the names I expected them to have a different theme, just like the labels. If the name was e.g. "Button 2 with theme" then it would be more clear that the number is about the button, not the theme.
- Maybe swap the location of the "Open keyboard" button and the radio buttons? It is probably just because I wasn't paying attention, but I was clicking around and suddenly I got a different keyboard as before and I didn't immediately realize that it was because of the radio buttons next to it.
- To me the "CappsOff" and "CappsOn" seem inverted. It works either way as it depends on how you interpret it: does it show the current state vs the state you are going to. I personally expected it to be the latter instead of the former.

Overall I still love how it looks and what it is becoming. Keep up the good work!

How would a texture of a label be displayed? Do you mean a BackgroundTexture property as alternative to the BackgroundColor?

I think it would definitely be useful.

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.

It seems to work for me. Could you share the code you are using (it may be related to the order things are executed)?

This should be fixed now.

You are right, the value is indeed incorrectly reset. The code actually does reset the value to 255 by immediately finishing the show animation, but this happens just after the hide animation had already looked at the current alpha value.

I'll see if I can fix this tomorrow.