Messages

Is it possible to set a different color to specific items?

This is currently not possible.

I want to add item with grey color, which will mean that the item is not available.

Would you still want the user to be able to select the item? If not then it would be better not to include the item.

how can I hide selected item from items list?

In order to hide items from a list, just clear the list and fill it again with the items you want to show.

is there any function like tgui::EditBox::setDefaultText?

What should the function do exactly? Place some text in the ComboBox when none of its items are selected yet?

It seems like ignoreMouseEvents doesn't do anything at all for Label, the property was added in both Label and Picture but is only used in Picture. I'll fix this soon.
Although handleEvent should return false after I fix it (unless there is another widget behind the label), what you need is the setEnabled function.

ignoreMouseEvents was added to allow a mouse event to reach the widget behind the label or picture, but to make a widget (any widget) completely ignore events, you should disable it:

Code (cpp) Select Expand

label->setEnabled(false);

TGUI requires C++14.
The tutorial for macOS don't seem to mention it, but you have to enable it in your project. Somewhere in your project (I don't know where as I don't have macOS to check right now) you have to add the "-std=c++14" flag (I'm sure you will find some information online on how to add that compiler flag).

No, because the valid string depends on the widget type while the connect function is part of the base class. A virtual function call is used to find the signal that matches the name, so it can't be done at compile time.

Using enums is practically the same as "child->connect(tgui::ChildWindow::Closed, []{})", but with tgui::ChildWindow::Closed being an integer instead of string.
The function signature would still have to be checked at runtime. It would be slightly faster than using a string (but the difference isn't enough for me to care about it).

The addClickListener code gives another possibility. Instead of child->onClose.connect([]{}), we could have something like child->addCloseListener([]{}). It however has the big disadvantage that for every add function there would also have to be a remove function (and possible even some variants other than add and remove).

I see very little advantages of this compared to just defining tgui::ChildWindow::Closed as a string.
String to enum conversion is very nice and can be interesting for other parts in TGUI, but if we already use a string then we don't really need it.
Inheritance of the enum is interesting as well, but I don't think it offers anything extra in this situation.

Can you show an example of how it would look like for the user to connect a callback?
Wouldn't it be very similar to "childWindow->connect(tgui::ChildWindow::Closed, []{});"? At least as far as I can tell it has the same advantages and disadvantages as this method.

The only disadvantage is that strings in txt file should be case sensitive.

I can live with that.

I'm starting a poll at https://forum.tgui.eu/general-discussion/new-signal-system/

I'm currently thinking about changing the signal system.
Depending on how the new system would look like, it will only be added in TGUI 0.9 or it will already be added in 0.8 (but if it is added in 0.8 then the current system will be kept as well for backwards compatibility).

Currently I have been pushing a signal system that looks like this:

Code (cpp) Select Expand

child->connect("closed", []{});

This is very flexible as the string could be read from a text file. The downside is that typos aren't caught at compile time.
Another issue is that the supported parameters of the function are only known at runtime (as they depend on the signal name), so the function signature can't be checked at compile-time either.

An improvement could be made by defining contant strings so that you would be able to write the following:

Code (cpp) Select Expand

child->connect(tgui::ChildWindow::Closed, []{});

Because tgui::ChildWindow::Closed is a string, it is backwards compatible with the old system and using a string read from a text file is still possible. It also prevents typos.
The function signature is however still can't be checked at compile time and it adds extra code: the line is longer and the type of the widget has to be repeated on every connect call.

Currently a different method already exists, but it has been marked deprecated because I was pushing the signal systems with strings. Maybe I should stop deprecating it and start recommending something like this:

Code (cpp) Select Expand

child->onClose.connect([]{});

It is shorter and has less repetition than having to use tgui::ChildWindow::Closed. It also allows the function signature to be checked on compile time.

It no longer allows passing a string read from a text file, but something could be done for that. If a system like this would be chosen then I will still keep some connect function that takes a string as parameter. The difference with the current implementation would be that the function signature would be limited: you would be able to pass a function without argument or taking a pointer to the widget and/or the name of the signal. The use unbound parameters (e.g. getting the text of a button as parameter) would only be possible via button->onPressed.connect(...), but not via button->connect("pressed", ...). This should however not be an issue, when loading these strings from a text file you are likely to bind a general callback function that doesn't take different parameters for different widgets (because if you know the widget type and signal upfront then you could just use the onXyz object).

TGUI currently has no public objects in its interface (other than these signals) so there is no naming convention for these signals yet. Maybe it would look slightly better if onClose would become Closed:

Code (cpp) Select Expand

child->Closed.connect([]{});

Someone also suggested the following, although that might be more difficult to implement with inheritance:

Code (cpp) Select Expand

child->connect.Closed([]{});

Which of these options would you like the use mostly in your code?

If you have comments or other ideas then feel free to post them in this topic.

The above declaration isn't easy to be found if you looking for the signals.

i agree with this, but the current signal names aren't any easier to find. The constants might also be hard to find.

These are much more clarified for me but i don't know if it can be implemented in your current code.

It might be very hard to do because of the inheritance between the widgets.

I would prefer constants or enums for the general purpose since signals should be loaded from txt file.

I also prefer something flexible like this (which is why I started using strings in the first place), but I'm not sure if I can continue to justify this design as it has some severe downsides. One connect function that takes the type as argument (as string or as enum) can't know which function signatures are valid so it somehow has to delay checking the function type to runtime.
I got it working like this so I can continue using it for 0.8, but I doubt I will continue the current signal system in 0.9. Just have a look at the comment above the TGUI_UNSAFE_TYPE_INFO_COMPARISON define in Config.hpp to get an idea of what kind of issues the design brings. Almost the entire SignalImpl.hpp file could also be removed if I wouldn't have to delay things until runtime.

So if I stick with the current design in 0.8 (as opposed to starting a new one and deprecating the current one) then I will just add constants so that you can do the following. But I will still be looking for a better way for TGUI 0.9.

Code (cpp) Select Expand

childWindow->connect(tgui::ChildWindow::Closed, []{});

Maybe I should just throw away the signal system like it is now.

The biggest issue that I have with constants was that they make the connect calls longer and add duplication (widget type has to be repeated):

Code (cpp) Select Expand

childWindow->connect("closed", []{});
vs

Code (cpp) Select Expand

childWindow->connect(tgui::ChildWindow::Closed, []{});

If I go the route of defining things in the widget itself, I might as well just remove the string altogether:

Code (cpp) Select Expand

childWindow->onClose.connect([]{});

Currently that code actually already works, there exists an onClose object (and one for every other signal). But because there are currently 2 ways to connect signals (via the "closed" string or with the onClose object) I had deprecated the onClose variant and only documented the string version.

There are 2 reasons why I don't like the onClose version:
- It is less flexible, you can't load the signal names from a text file.
- It just doesn't fit with the rest of the library. Widgets only have public functions, not public objects.

But maybe I shouldn't worry so much about these issues. When loading signals from a text file you would use a general callback function so I wouldn't need to support unbound parameters. So I could keep a simplified version of the current connect function for this case and suggest using the onXyz variant (which would support all features) in all other cases.
Instead of onClose, I could maybe rename it to Closed. I think childWindow->Closed.connect([]{}); looks slightly better than using onClose.

Do you perhaps have an opinion on what you think would be good or bad about the signal system?

In the future I want to add a list of all signals for all widgets somewhere on the website and there was a suggestion a while back to define constants containing the string (so that you do e.g. connect(tgui::EditBox::ReturnKeyPressed) instead of connect("returnkeypressed")), but I haven't made any decisions yet about how I'm actually going to do it.

The TextBox class has no "ReturnKeyPressed" signal, only EditBox has it.
If you would catch the exception and print it then it would print: "No signal exists with name 'returnkeypressed'".

I always find it weird that tools don't show the exception message by default, gcc on linux just shows the message in the terminal when the program exits due to an exception.

How is pressedFunc declared?

Looks good. Seems like setSelectedText is indeed enough to implement searching and basic highlighting in your own code.

I fixed the issue with right click (which was actually just undefined behavior when removing an item while the mouse hovered over the last item in the list).

The following things have been added:
- RightClicked signal in ListView
- addMultipleItems, changeItem and changeSubItem functions in ListView
- setSelectedText function in TextBox

Edit: The unit tests are hanging somewhere on the right click event on windows (while the tests don't hang there on linux), so right click might not work yet. I'll try to figure that out tomorrow.

Maybe a highlighted text is identical with selected text. And there is selected text in text box.

Still easier said than done, the TextBox hardcodes that there is only one part selected. Implementing something like highlighting in TextBox might not be that hard but currently has very low priority.

A "setSelectedText(size_t indexBegin, size_t sizeLetters)" function for textbox widget would be useful in many cases.

I can't immediately think of a use case for it, the TextBox is meant to write text in, not for visualizing data.

Also can not found setHorizontalAlignment and setVerticalAlignment for textbox. Have you miss them for any particular reason?

Alignment in a TextBox is an extremely niche use case imho, I don't think I've ever encountered it in any application. I can understand that it could be useful so I'll add it to the todo list, but it will be harder to add than in Label where there is no text interaction.

Highlighting is something that won't happen soon, a RichTextBox class would first have to exist. The TextBox text is currently split in up to 5 parts to draw it, highlighting would require it to be split in an unlimited amount of parts (as it depends on how many matches there were).
An editor with highlighting and searching though it is not something that is likely to ever exist in TGUI. You would have to write it yourself with a couple of buttons (e.g. goto previous and next match), an edit box (to type the searched word) and a RichTextLabel or RichTextBox that allows setting colors of any part of the text. The RichText widget is still missing in TGUI and may be included in the future, although there are currently no plans for it as it would be a lot of work.

The ListView case should probably just be implemented in your own code, that gives a lot more flexibility (e.g. to search only at the beginning of the word or only search in first column, etc).

Could you give an example of how such a search box would look visually? Because I'm not sure what you mean and how you expect it to be used. And how do you expect searched text to show up in Label or TextBox?

The test I did was just to get a quick idea of the performance, it wasn't very realistic: all items were identical and there was only one column.
With 10000 items and 10 columns (still identical items of only 6 characters) it takes about 0.32 seconds in release mode. Using addMultipleItems only decreases it to 0.2 - 0.26 seconds (depending on whether you include constructing the vector in the measurements). So the difference itsn't that spectacular (difference is smaller in release than it was in debug) as the biggest performance cost is actually creating the items. The performance scales pretty linearly, 10000 items is about 10 times slower than 1000 items. For columns the same goes: the performance of 10000 items in a single column should be comparable to 1000 items with 10 columns.

Edit: I might even be able to reduce the time by another 10-15% if I don't unnecessary create a sprite for the icon, but I think the current performance is already great.

There isn't a right click event yet, but I could add a "ItemRightClicked" signal.

I did some performance tests and for 5000 items the addMultipleItems can reduce the time from 0.168 to 0.045 seconds.
I'll add it, but most people won't need it. Inserting 1000 items with addItem takes only 0.04 seconds, which will hardly be noticeable when doing it only once during the loading phase.
Edit: That was in debug mode, inserting 5000 items with addItem only takes 0.06 seconds in release mode.

It's a bug. I did some tests and I guess you are setting a default theme (as it seems to work fine when calling setRenderer after the widget was created).
It seems like the constructor of the ChildWindow class sets its default height of the title bar after it loads the renderer of the default theme, instead of before.

I have fixed it in the version on github (http://github.com/texus/TGUI), but you will have to compile it yourself to use it.

Using "window->getRenderer()->setTitleBarHeight(...);" changes the title bar height for me. Can you share some example code where the title bar isn't being changed (as it probably has to do with the order in which functions are being called)?

Although I don't want the API to be the same as the corresponding Windows component, I was trying to keep it somewhat similar. So I'm a bit hesitant to make some of these changes.

1. I see an item as an entire row, so an addItem function that takes a column argument doesn't fit with my vision of the ListView. I consider the "addItem(const sf::String& text)" to only exist for convenience in case someone just uses the widget for a single column or in case I add an addSubItem function in the future. The "addItem(const std::vector<sf::String>& item)" is what I consider the "real" addItem function.

2. I could rename it to addRow or addItemRow though, but the reason would be to have the naming more consistent with getItemRow (which only uses the term "row" because I couldn't find a better word and the "getItem" function already existed).

3. Similarly, removeItem removes an entire row because the row is the item.

4-5. I'm not sure how to best deal with selecting a single cell, the ListView doesn't need to support something like that imho. If you have some use case for it then maybe I can still add an option to select a cell instead of a row though, but it wouldn't be the default behavior.

A way to update an item is still lacking, so I can definately add something like "bool updateItem(std::size_t index, std::vector<sf::String>)". Maybe I'll add something like "updateSubItem(std::size_t rowIndex, std::size_t columnIndex, sf::String)" too, but the updateItem is the most important one as there is currently no way at all to change an item.

A "void addMultipleItems(const std::vector<std::vector<sf::String>> & item)" could be added, but only for performance reasons. In terms of usability, you can just call addItem in a loop, so there isn't much need for such a function. But if you are working with over 100 items then it could still be useful because it would insert the items slightly faster. Although I wonder if the difference would be big enough to notice, that is something that I should test first.

The following changes were just made to the ListView widget:

- Added horizontal grid lines to ListView
- Added option to ListView to expand the last column to fill the remaining space
- Allow a separator between the header and contents in a ListView
- Split separator in ListView into separator and vertical grid line