Questions

[texus]

I'm not sure if I hit a bug in gcc, or just some special case in the c++ standard.
I'm going to assume its a bug since it compiled with gcc 4.9.

The braces on lines 274 and 284 in src/TGUI/Layout.cpp should be replaced by brackets.
So "m_first{...}" should be "m_first(...)".
It should compile after that change.

I also found 2 other places that didn't compile, but you since you already passed the first one, and I assume that gcc 4.8 will have an emplace function, they just have to be fixed to make it work on gcc 4.7.

[Law]

Okay thanks!

I was also wondering how many different events tgui knows, beyond tgui::button::LeftMouseClicked. For example, what is the appropriate event when the user clicks outside of the widget he was using ?

Also how can we write in italics or bold in comboboxes, listboxes, etc?

[texus]

Also how can we write in italics or bold in comboboxes, listboxes, etc?

That is something that you can't do. It could be added in the future but it will take some planning about how it would be implemented.

I was also wondering how many different events tgui knows, beyond tgui::button::LeftMouseClicked.

Normally this is found in the documentation of that widget and its base classes. But since the documentation isn't really complete yet, here is the full list. Button inherits from ClickableWidget which inherits from Widget, so it also has the events from its base classes.
(The documentation of v0.6 should contain the ones from the other widgets, I think only PositionChanged and SizeChanged are new in v0.7)

Widget:
  PositionChanged       ///< Position of the widget has changed
  SizeChanged           ///< Size of the widget has changed
  Focused               ///< Widget gained focus.
  Unfocused             ///< Widget lost focus.
  MouseEntered         ///< Mouse cursor entered in the Widget area.
  MouseLeft            ///< Mouse cursor left the Widget area.

ClickableWidget:
  LeftMousePressed     ///< The left mouse button was pressed
  LeftMouseReleased     ///< The left mouse button was released
  LeftMouseClicked     ///< The left mouse button was clicked

Button:
  SpaceKeyPressed     ///< Space key was pressed
  ReturnKeyPressed     ///< Return key was pressed

what is the appropriate event when the user clicks outside of the widget he was using

That will hopefully generate an Unfocused event

Focusing widgets is something very tricky in my code and even I can't always predict the exact behavior. The event should be fired when clicking outside the edit box that you were typing. But I don't think it will work with e.g. a slider.

The SpaceKeyPressed and ReturnKeyPressed callbacks only work when the button is focused, but the black style has no focused image by default. So it may not be possible to focus a button and then press space to trigger a callback while using the black theme.

Edit: I just verified it. Clicking outside the edit box will correctly generate the unfocused callback. Button will generate this callback immediately after the focused callback, since it cannot be focused without a focus image. Edit box is the exception since it has to be focused to type text in it, which is the reason that it can be focused even when there is no focus image.

[Law]

Okay thanks again.

I'm currently trying callbacks and it is my understanding that you only use the duo bindCallback + setCallbackId when you only have 1 callback to put on the widget. You can't put two different callbacks (like, LeftMouseReleased and )LeftMousePressed) this way, correct ? (Because that doesn't work for me)

Also, just for your future versions, you might want the comboboxes' content to disappear on LeftMouseReleased rather than LeftMousePressed. Also it could be nice to highlight the item you are currently hovering.

[texus]

You can't put two different callbacks (like, LeftMouseReleased and )LeftMousePressed) this way, correct

All callbacks will have the same callbackId, you cannot use more than one id.
The id is just needed to differentiate between the widgets, you also have callback.trigger which contains whether it was a LeftMouseReleased or LeftMousePressed. But in most cases you don't even need the id since you just call a specific function when something happens to that widget. And the function isn't called from anywhere else.

Also, just for your future versions, you might want the comboboxes' content to disappear on LeftMouseReleased rather than LeftMousePressed. Also it could be nice to highlight the item you are currently hovering.

Thanks for the feedback.
Altough this might be harder than it looks. The list is actually a ListBox that gets created. Highlighting items should thus just be implemented in ListBox and it will automatically work with the combo box. So that is doable.
But the list box is closed when the combo box gets a ItemSelected callback from the list box. This brings 2 problems: the list doesn't close when clicking on the already selected item, and it always happens on mouse press. Using the click callback instead of the ItemSelect won't work because you may click on the scrollbar. So I'm still looking for a way to get around this limitation.

[Law]

All callbacks will have the same callbackId, you cannot use more than one id.
The id is just needed to differentiate between the widgets, you also have callback.trigger which contains whether it was a LeftMouseReleased or LeftMousePressed. But in most cases you don't even need the id since you just call a specific function when something happens to that widget. And the function isn't called from anywhere else.

Unfocused doesn't seem to work well with Combobox. I have two comboboxes, the items of one depending of the selected item of the other. I coded that when Combobox #1 is unfocused, the items of Combobox #2 change according to the selected item of Combobox #1. But unfortunately, I have to select the same item of Combobox #1 twice to get Combobox #2 to display its appropriate items. Would you have a workaround to suggest?

[texus]

What about changing combo box #2 when you receive a ItemSelected callback from combo box #1?

[Law]

It worked thanks!

No questions here, just something I noticed. If you've already been told, just ignore the following.

When you set the size of your checkbox, editbox, etc, it usually never gives them the exact size you provided. It's always one or two pixels close, though. I think it would be great if you could some day fix all the classes that share this bug with setSize, because some people (like meee) like very much designing things pixel-wise. Like, 5 pixels between two checkboxes and nothing more, nothing less. (I think I remember that the SFML has this exactness, which really delighted me when I first tried it, compared to other libraries)

Of course once you fix that, the thing I made will be a mess and I will have to change things again But I think that's for the best.

Also, when you have a combobox depending on another one, and you change the selected item of the first one so that there is no items available for the second one, though the second one doesn't display any items indeed, the length of the "panel" sometimes keeps the length it had with the previous items, instead of going back to minimal length.

I might have noticed another few things, but I forgot. Thanks

[texus]

When you set the size of your checkbox, editbox, etc, it usually never gives them the exact size you provided.

It is somewhat deliberately. The rule is very simple: borders are drawn outside the widget. The size you pass to setSize is the size without the borders. The reason I made this decision was because otherwise when giving ListBox a height of 200 and the item height is 20, there wouldn't fit 10 items in the list box because the borders were subtracted from the size. Now the borders are outside the widget and the list box can fit exactly 10 items as expected.

But it is something that bothers me too. Neither solutions are really correct.

And right now if a widget has a left position of 50 and the left border has width 2, then the first visible pixel is on left position 48. But that is still something that I plan to change, so that the whole widget including the border starts from the given position.

So this is a subject that I wouldn't mind discussing to find the best possible way to implement it.

I can only give one advice now: don't use borders . If you use images for all widgets then you usually don't need to have borders around it.

Also, when you have a combobox depending on another one, and you change the selected item of the first one so that there is no items available for the second one, though the second one doesn't display any items indeed, the length of the "panel" sometimes keeps the length it had with the previous items, instead of going back to minimal length.

I'll have a look at it.

Talking about combo boxes, I have been making the changes that you suggested. The list now disappears when the mouse is released again, and the item below the mouse is highlighted (if it is not already selected).

[Law]

Talking about combo boxes, I have been making the changes that you suggested. The list now disappears when the mouse is released again, and the item below the mouse is highlighted (if it is not already selected).

So I reinstalled TGUI like you made me do last time, and this is what I get when I compile now:

Code Select Expand

error while loading shared libraries: libtgui.so.0.6.5: cannot open shared object file: No such file or directory

[texus]

I wasn't talking about v0.6, sorry if I wasn't clear. Its a feature for v0.7.
So it will be available either when I make the v0.7-dev branch public (by the end of next week perhaps), or if you really want it I can send you another zip file of the currently latest v0.7-dev version.

The error is caused by switching between library versions (you had 0.7 installed but now installed 0.6).
You have to run "sudo ldconfig" because the old version is still cached.

[Law]

Okay then I switched back to the original. Good to hear about the combobox

[texus]

the length of the "panel" sometimes keeps the length it had with the previous items, instead of going back to minimal length.

It seems like removing an item from the combo box doesn't shrink the list at all. It should be easy to fix.

But do you have a suggestion on what should happen when there are no items left in the combo box?
- Just ignore any clicks on the combo box
- Still flip the arrow but don't show a list
- Show an empty list with the size of a single item

I would tend to choose the third behaviour, do you have an opinion on this?

[Law]

- Just ignore any clicks on the combo box
- Still flip the arrow but don't show a list
- Show an empty list with the size of a single item

I'm honestly fine with all three of them. I had #3 in mind earlier but #1 and #2 are nice as well.

[Law]

Maybe I still like #3 a bit more.

So I've started to play with Grids! Here is a code inspired from what you wrote the other day:

Code Select Expand

tgui::Grid::Ptr database(gui);
database->setSize(390, 600);
database->setPosition(405, 25);

tgui::Label::Ptr label(*database);
label->setText("aaaaaaaaaaaaaaa");
   
tgui::Picture::Ptr first(*database);
first->load("1.png");
   
tgui::Picture::Ptr second(*database);
second->load("2.png");

tgui::Picture::Ptr third(*database);
third->load("3.png");
   
database->addWidget(label, 0, 0);
database->addWidget(first, 0, 1);
database->addWidget(second, 0, 2);
database->addWidget(third, 0, 3);
database->updateWidgets();

And I see how to add things to the Grid now. But

- How do you do to make column #2 (or the other ones) start at X pixel and end at Y pixel ?
- How do you do to make the grid actually look like a grid, that is: draw a few lines (maybe not the horizontal ones but the vertical ones can be considered) and make a scrollbar appear, should the list get too long ?

[texus]

Ok, I've used the 3th way.
In case you are interested in using the updated combo box, you can download it here: https://www.dropbox.com/s/a23r9b8qnt50f5t/texus-tgui-devel-791673a73568.zip.

Grid is still a bit limited in usage. It was added in the first place to just put widgets below or next to each other in a simple way.
I'm planning to give it a big update later in v0.7 development, but I'm not sure yet how it will eventually look. I am planning on adding a maximum size so that if you go bigger a scrollbar would get added. Drawing lines is a nice idea, I'll add it on the todo list too.

The second column just starts where the first one ends, you can't set an exact position.
However you can put some space around widgets by using the fourth parameter of addWidget (https://tgui.eu/documentation/v0.6/classtgui_1_1Grid.html#aaf0e06ecc9f7dad5b54e6e5d7d38d469).
So take leftBorder = rightBorder = (50 - widgetInFirstColumn.getSize().x) / 2, then the second column will start at position 50.

[Law]

Well I think columns should have fixed sizes. If not, whenever a new row has a text longer than the other rows, the column will suddenly become longer, causing all the buttons to suddenly move. I think it could be better if there was a way to set the sizes of columns for good.

[texus]

Originally grid was fixed sized, the first implementation allowed you to set the row and column size. I got rid of it for some reason, but I can't remember why. But a lot has changed since then, so I don't expect too much problems with allowing to set an exact row and column size.

So I will have a look at it when rewriting the Grid (but my todo list is already getting very long ).

[Law]

Hi, new questions coming ^^

1. I couldn't manage to change the size of text in a ListBox. So I tried to change the Global Font Size, but I couldn't find that either. Is there a simple way to do it ?

2. Also, is it not possible to give each item of a ListBox a specific color ? Like, Item0 is orange, Item1 is green, etc.

3. The Double Left Click event is not yet implemented, correct ?

[texus]

1. I couldn't manage to change the size of text in a ListBox. So I tried to change the Global Font Size, but I couldn't find that either. Is there a simple way to do it ?

The text size can't be changed directly in ListBox. You have to set the height of the items with setItemHeight. (The text size is internally set to 0.8 * itemHeight)
I did this so that you can easily predict the amount of visible items. If the height is 200 and you set the item height to 20 then there are 10 visible items. If you would be setting the text height then you have no idea how many items fit (since there has to be a small space between the lines).

2. Also, is it not possible to give each item of a ListBox a specific color ? Like, Item0 is orange, Item1 is green, etc.

That can't be done. It would be pretty hard to pass all the colors anyway since you would need to set the background colors too and the colors for when they are selected. I think it would become a mess to know which color to use where.

3. The Double Left Click event is not yet implemented, correct ?

Correct. In which situation do you need a double click callback?

[Law]

1. I see thanks.
2. Okay never mind.
3. Well I was planning to make 4 ListBoxes (A, B, C and D), and given other options, double clicking an Item of ListBox A would add that Item to ListBox B, C or D. Also, I was thinking of deleting the Item if you double click it in ListBox B, C and D.

[texus]

Double click callback in ListBox sounds reasonable. I'll see if I can add it.

[Law]

Something I just encountered, I don't know if that is easy for you to fix, but the text wrapper of TextBoxes cuts words in half.

Also, that just crossed my mind: ListBox B, C and D I mentionned earlier will actually be Grids. Each line will countain the name of the Item I double clicked, but also the number of times I double clicked it, on its left. For example

2 Item_2345
1 Item_697
3 Item_5409

etc. I don't know if you could do that with Grids too.

[texus]

TextBox isn't supposed to work yet. The first preview of v0.7 that I send had the class entirely commented out. But when I send the fix with these combo boxes I was too lazy to do that again. The code in TextBox is being entirely rewritten.
TextBox is kindof useless until I'm finished with it. I think it already exists since v0.4 but the performance is too bad to actually use it. I hope to have it rewritten and fully usable by the end of next week.

The double click will only work in list boxes. But since ListBox A is still a list box this is no problem.
You can use grids for the others, just put Label widgets in them to contain the text.

[Law]

I look forward to v0.7 then.

The double click will only work in list boxes. But since ListBox A is still a list box this is no problem.
You can use grids for the others, just put Label widgets in them to contain the text.

I'll just have to find another way to delete Items in Grid B, C and D then Q_Q