GNOME Bugzilla – Bug 710315
Revert "treeview: Store editable position differently"
Last modified: 2013-12-28 16:30:57 UTC
Commit 6f9dc0ff seems to break a few things: - When scrolling while there's editing, drawing is all messed up. E.g. the GtkEntry editable gets only half-visible, visible multiple times, at the wrong place... - This ignores completely the given cell_area and forces the editable to be resized over the entire "column", which isn't always what the cell_area is (e.g. when multiple renderers are present in the same "column") (Also, commit says it fixes /TreeView/scrolling/new-row-mixed/path-500 test; but that test passes fine for me with or without it.)
Without looking at the patch in detail, the test is flaky without that patch. To make it fail reliably, I think you needed to run it on a heavily loaded machine. The flakiness depended on some row validation callbacks running/not running before the first expose event.
Well, with the commit it still completely ignores the given cell_area and forces the editable over the whole column/cell, which simply isn't right. And it also fails to draw correctly when scrolling is involved. So while there might be improvements to be done there, this doesn't look like this is it, as it makes things much worse.
*** Bug 721157 has been marked as a duplicate of this bug. ***
Commit 6d811a67 does address the fact that the editable was forced over the whole column/cell, but it didn't fix the fact that when there's scrolling involved while editing, or when starting to edit a not (fully) visible row, it fails to draw correctly/where it should; Something that worked fine before 6f9dc0ff.