Re: Table
« Reply #15 on: 12 December 2015, 16:13:23 »
"std::static_pointer_cast" is working. My bad: I called the function before rows were added. Here is a nicer table:

Re: Table
« Reply #16 on: 13 December 2015, 21:07:32 »
Don't worked too much today, but on what I worked I encountered a problem: I need to get the ratio for a widget but I can't find a function like getRatio() in BoxLayout.

*

texus

  • *****
  • 1280
    • View Profile
    • Texus's Blog
Re: Table
« Reply #17 on: 13 December 2015, 21:11:16 »
Either you wait and I will try to add such a function later today, or you can just add it yourself.

*

texus

  • *****
  • 1280
    • View Profile
    • Texus's Blog
Re: Table
« Reply #18 on: 13 December 2015, 22:59:59 »
I have added the getRatio function (and a getFixedSize function) in the latest version.

Re: Table
« Reply #19 on: 14 December 2015, 14:51:48 »
I don't have much time to finish the table so I upload the work: https://bitbucket.org/AlexxanderX/tguitable. Some notes:
  • setTextColor() from Table and setNormalTextColor() from TableRow are not finished, need to think how to set it because it may not contain only labels;
  • With the getCustomHeight() from TableRow I check if the row contains widgets bigger then the label( a button). If is not bigger then in the Table's insert() I check it;
  • I separated the sizing of rows from Table's updateWidgetPositions() in order to make work the custom row sizes;
  • TableItem's mouseOnWidget() doesn't work, I don't really investigated to much how should be in order widgets like button to work
  • TableItem's Align::None is just for internal coding: in order to know if need to use the set align in adds function from TableRow

*

texus

  • *****
  • 1280
    • View Profile
    • Texus's Blog
Re: Table
« Reply #20 on: 14 December 2015, 14:54:08 »
I have a very busy week myself, so I will take a look at it next week.

Re: Table
« Reply #21 on: 14 December 2015, 14:55:35 »
In the time I will still work on it, but yea, pretty busy week here too :D

*

texus

  • *****
  • 1280
    • View Profile
    • Texus's Blog
Re: Table
« Reply #22 on: 23 December 2015, 14:22:10 »
I have some time in the next few days to help with the Table class.

Could you perhaps make the code independent of your xal code? If the headers would not be in a xalTGUI subfolder, you would remove the Global.hpp include and if you would make example.cpp a standalone example code then I can just clone your repository and compile and run here. That would make it a lot easier for me to help with writing the code.

Re: Table
« Reply #23 on: 23 December 2015, 16:56:54 »
Done ;)

*

texus

  • *****
  • 1280
    • View Profile
    • Texus's Blog
Re: Table
« Reply #24 on: 23 December 2015, 18:44:34 »
Here are some remarks on the code. I can fix some of these things, but maybe you want to give your opinion on some of these points first.

There should be some function that recalculates the entire widget. The reason why you have to call setFont manually is because otherwise it only gets the font when gui.add is called. Even if I call updateColumnsDelimitatorsSize and updateWidgetPositions in the setFont function the text still doesn't show on the correct location because the only place where you set the height of a row is in the insert function which is called before the font is set. The setFont function should trigger some recalculation because changing the font might result in different text sizes.

Was there any reason to use BoxLayout instead of VerticalLayout in Table?

Perhaps HorizontalAlign::None can be renamed to HorizontalAlign::Default and then in the documentation of the setItemsHorizontalAlign function we can state that it changes the default alignment. This way it doesn't has to be marked as internal because using that would thus result in a clear documented behavior. The only problem would be when the user tries to pass Default to setItemsHorizontalAlign, but we can interpret that as the default gui behavior and thus set it to Left (or Center).

For setTextColor and setNormalTextColor you can loop over all widgets and check the result of dynamic_pointer_cast<tgui::Label>. If it is nullptr then it wasn't a label and you just ignore it, if it isn't nullptr then it is a label and you can set its color. Alternatively you can hold a boolean in the items but since the color is not changed much the little overhead of dynamic cast definately shouldn't be a problem.

For the mouseOnWidget function instead of passing (x-getPosition().x,y-getPosition().y) you just had to pass (x,y) but it seems like that is not enough to show the hover picure. The problem is also that your TableItem is receiving all events but is not relaying it to the widget (the other functions have to implemented like mouseOnWidget is now). It would be better if I fix this because I know more about this, but I do start to wonder if having a TableItem widget is really needed. Maybe the TableRow should just take widgets directly and be responsible for positioning them (the alignments would be stored in TableRow as a vector).
« Last Edit: 23 December 2015, 18:46:57 by texus »

Re: Table
« Reply #25 on: 23 December 2015, 20:13:15 »
Yes, there should be some calculations when the font or characters size is changed.

I don't really remember why I have chosen BoxLayout instead of VerticalLayout, but I think because I entirely rewrite the updateWidgetPositions(), so it's no more a legit VerticalLayout, but something else.

Well, need to think on this...

Yes, I never thought of the function returning nullptr.

I created the class TableItem for alignment of the widget. If you think would be easier to manage the alignment of every item of row in TableRow then go ahead. I already implemented some basic code for the events but don't work very well so I don't added in the repository.

*

texus

  • *****
  • 1280
    • View Profile
    • Texus's Blog
Re: Table
« Reply #26 on: 23 December 2015, 20:32:10 »
I think it would be best if you wrote the code to recalculate the positions and sizes of everything because I don't know yet what all variables do. Actually there probably shouldn't be a new function, updateWidgetPositions should just be extended to also set the sizes of the rows instead of only the positions. And then setFont should just call updateWidgetPositions at the end and the problem with manually having to call setFont will be gone as well.

It is a good point about it no longer being a VerticalLayout. I didn't know that VerticalLayout only contained an updateWidgetPositions function, I though it contained more.

I will take care of the setTextColor and setNormalTextColor and I will have a look at the TableItem and the events (tomorrow).
I will also change the insert function so that it will create a TableRow and insert the widget in it when you call insert with a widget other than TableRow.

*

texus

  • *****
  • 1280
    • View Profile
    • Texus's Blog
Re: Table
« Reply #27 on: 24 December 2015, 13:43:20 »
Should setTextColor and setNormalTextColor actually do something to the existing labels? Because if the user has created some labels with a custom color then they would get changed as well. It might be better to just say that these functions set the color of all future labels and thus doesn't affect the ones that already exist.

*

texus

  • *****
  • 1280
    • View Profile
    • Texus's Blog
Re: Table
« Reply #28 on: 24 December 2015, 18:15:40 »
You can find my changes here: https://bitbucket.org/texus/tguitable
I have added a few things, but I also seem to have broken a few things.

*

texus

  • *****
  • 1280
    • View Profile
    • Texus's Blog
Re: Table
« Reply #29 on: 25 December 2015, 00:03:38 »
I fixed the remaining problems, you should pull my version and see if there is still something missing or not.