[prev in list] [next in list] [prev in thread] [next in thread] 

List:       konq-bugs
Subject:    [Bug 93791] [test case] displays a table that appears to have empty
From:       Vincent Ricard <magic () magicninja ! org>
Date:       2007-05-13 16:36:53
Message-ID: 20070513163653.10932.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=93791         




------- Additional Comments From magic magicninja org  2007-05-13 18:36 -------
Here is my analysis, if someone can tell me how to fix that, i'll code it.

This appears in the debug output _after_ having removed the tHead (and all its rows \
                and cells):
---
AutoTableLayout::layout()
    tableWidth=45,  nEffCols=4
    effcol 0 is of type 0 value 0, minWidth=40, maxWidth=40
        effective: type 0 value 0, minWidth=40, maxWidth=40
    effcol 1 is of type 0 value 0, minWidth=1, maxWidth=1
        effective: type 0 value 0, minWidth=1, maxWidth=1
    effcol 2 is of type 0 value 0, minWidth=1, maxWidth=1
        effective: type 0 value 0, minWidth=1, maxWidth=1
    effcol 3 is of type 0 value 0, minWidth=1, maxWidth=1
        effective: type 0 value 0, minWidth=1, maxWidth=1
---

That means that the size RenderTable::columns member is still '4' after the removal \
(whereas it should be '1' after the new insertion). As far as i can tell, the size of \
'columns' always increases (when needed) and never decreases in the code.

Should we recompute 'columns' when we call 'removeChildNode' by looking through all \
tr's? Could be very inefficient...

So the conclusion is... i need a table layout guru ;)

PS: i didn't check the FixedLayout behavior.
_______________________________________________
Konq-bugs mailing list
Konq-bugs@mail.kde.org
https://mail.kde.org/mailman/listinfo/konq-bugs


[prev in list] [next in list] [prev in thread] [next in thread]