GNOME Bugzilla – Bug 546005
priv->tree is not created for unrealized (I think) treeview
Last modified: 2009-07-30 12:05:06 UTC
The following test from PyGTK: import gtk model = gtk.ListStore(str) treeview = gtk.TreeView(model) treeview.set_cursor(1) now fails with a critical warning from GTK+: /home/paul/test/test.py:4: GtkWarning: gtk_tree_view_set_cursor_on_cell: assertion `tree_view->priv->tree != NULL' failed treeview.set_cursor(1) It used to work before (the test is for another unrelated bug in PyGTK itself). Looks like priv->tree is created only on 'realize' event now.
I think the cause is the fix for Bug 498010 in r20208. gtk_tree_view_set_cursor_on_cell probably should check for tree_view->priv->model != NULL instead of tree_view->priv->tree != NULL. Because a tree view can have a model without having a tree.
It has been suggested that this is causing bug #517960 - Port the url bar completion func to GRegex (epiphany). I have seen it for more than just 2 months, maybe it's not related to my bug? any idea?
(In reply to comment #0) > The following test from PyGTK: > > import gtk > model = gtk.ListStore(str) > treeview = gtk.TreeView(model) > treeview.set_cursor(1) > > now fails with a critical warning from GTK+: > > /home/paul/test/test.py:4: GtkWarning: gtk_tree_view_set_cursor_on_cell: > assertion `tree_view->priv->tree != NULL' failed > treeview.set_cursor(1) > > It used to work before (the test is for another unrelated bug in PyGTK itself). > Looks like priv->tree is created only on 'realize' event now. It didn't really work before, simply because you cannot set the cursor on a tree view that does not have a model set. Before it just did nothing and didn't spew an error; now gtk_tree_view_set_cursor() explicitly checks for the internal rbtree to have been created. We could change it to check for the model as Bjorn said, but that will again cause gtk_tree_view_real_set_cursor() to fail silently. Diego: basically this warning appears when you try to scroll the tree view when it does not have a model set.
Well, I guess you know better, I didn't even know about this test before it started causing 'make check' fail :) Can you then suggest how to correct the test?
(In reply to comment #3) > (In reply to comment #0) > > The following test from PyGTK: > > > > import gtk > > model = gtk.ListStore(str) > > treeview = gtk.TreeView(model) > > treeview.set_cursor(1) > > > > now fails with a critical warning from GTK+: > > > > /home/paul/test/test.py:4: GtkWarning: gtk_tree_view_set_cursor_on_cell: > > assertion `tree_view->priv->tree != NULL' failed > > treeview.set_cursor(1) > > > > It used to work before (the test is for another unrelated bug in PyGTK itself). > > Looks like priv->tree is created only on 'realize' event now. > > It didn't really work before, simply because you cannot set the cursor on a > tree view that does not have a model set. The tree view in the test does have a model. The model is empty but that is irrelevant. :) > Before it just did nothing and > didn't spew an error; now gtk_tree_view_set_cursor() explicitly checks for the > internal rbtree to have been created. It fails silently because the tree path 1 is invalid. The model has no rows so no tree path is valid. It has always been the case that invalid tree paths failed silently. > We could change it to check for the model as Bjorn said, but that will again > cause gtk_tree_view_real_set_cursor() to fail silently. Yes, but only if the tree path is invalid. For example: model = gtk.ListStore(str) model.append(['hi']) view = gtk.TreeView(model) view.set_cursor((0,)) assert view.get_cursor() == ((0,), None) that code is perfectly valid but will trigger the priv->tree != NULL assertion.
I don't see how the test case in comment 5 can trigger the assertion. When you set the model upon construction of the tree view, the rbtree is created. The set_cursor() and get_cursor() calls cannot hit the priv->tree != NULL assertions. The unit test from the opening comment did break. The code has now been changed to return silently again and the docs have been updated to clarify this. I've added both of your tests to the (new!) tree view unit tests.