Questions

Started by Law, 10 August 2014, 14:47:07

Law

Quote from: texus on 15 August 2014, 20:22:05
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 :P 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

QuoteWhen 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.

QuoteAlso, 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

Quote from: texus on 16 August 2014, 18:39:10Talking 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:

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

Quotethe 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

Quote from: texus on 16 August 2014, 19:45:48
- 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:

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

Quote1. 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).

Quote2. 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.

Quote3. The Double Left Click event is not yet implemented, correct ?
Correct. In which situation do you need a double click callback?