I have an extreme urge to reimplement Gtk’s ColumnView instead of dealing with the original. Not because of bugs but because of policy decisions. The former can get fixed, the latter won’t be. Like: I’ve never had to deal with a list widget where it was a policy decision not to expose the currently focused row. Some dev: “I need to know the currently focused row to display a context menu.” Gtk devs: “That’s not how you do it, register your context menu for individual cells, then you won’t need to know.” Well, I still need to know the currently focused row, e.g. to restore list state. Or to check whether changing focused row succeeded because there are many conditions where it will fail silently. Not possible, just assume that selection and focus are identical (spoiler: way too often they are not). Similarly, invalidating a row is a trivial task in pretty much any framework I had to work with except Gtk. Some dev: “My data changed, how do I invalidate a row?” Gtk devs: “You don’t. Make sure that your list item properties are bound to the respective cell properties, then updates will happen automatically. Never mind that there are zero examples showing how to clean up the bindings in case the cell is reused later, surely you will get that implemented correctly.” I have a suspicion that cells are only supposed to be reused per documentation but this doesn’t actually happen in practice because otherwise lots of applications would turn out buggy in very subtle and annoying ways. Either way, in some cases I have complex enough data that managing updates via bindings would be a horrible mess. So I invalidate columns by re-registering their factory, and now I need to find another hack that allows invalidating single rows. Last time I criticized Gtk I was asked what I was hoping to achieve. Well, nothing at all. I’m just venting. Because Gtk is an extremely frustrating framework to work with, and this is merely a tiny portion of its unfixable issues.