UpsilonNumworks/Upsilon
1
0
Fork 0
mirror of https://github.com/UpsilonNumworks/Upsilon.git synced 2026-01-19 00:37:25 +01:00
Code Issues Packages Projects Releases Wiki Activity

Revert "[escher] Force relayouting in a table view"

Browse Source 
This reverts commit 94281b906d5135f4d3181ca248f572e32be9119c.
The commit created a lot of blinking in the calculation history (for
instance for multiple lines of 56) + "the table's size might be
miscomputed" due to the layouting order (but we have not searched for an
example of such a miscomputation)
This commit is contained in:
Léa Saviot
2019-10-16 10:45:48 +02:00
parent 5787d50a45
commit 2c497d4f55
1 changed files with 17 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
escher/src/table_view.cpp
View File

@@ -34,8 +34,23 @@ const char * TableView::className() const {
#endif
void TableView::layoutSubviews(bool force) {
// We force the layoutSubviews in case the frame did not change.
ScrollView::layoutSubviews(true);
/* On the one hand, ScrollView::layoutSubviews()
* calls setFrame(...) over m_contentView,
* which typically calls layoutSubviews() over m_contentView.
* However, if the frame happens to be unchanged,
* setFrame(...) does not call layoutSubviews.
* On the other hand, calling only m_contentView.layoutSubviews()
* does not relayout ScrollView when the offset
* or the content's size changes.
* For those reasons, we call both of them explicitly.
* Besides, one must call layoutSubviews() over
* m_contentView first, in order to reload the table's data,
* otherwise the table's size might be miscomputed...
* FIXME:
* Finally, this solution is not optimal at all since
* layoutSubviews is called twice over m_contentView. */
m_contentView.layoutSubviews(force);
ScrollView::layoutSubviews(force);
}
void TableView::reloadCellAtLocation(int i, int j) {