GNOME Bugzilla – Bug 75702
scroll cell in view bug?
Last modified: 2011-02-04 16:09:56 UTC
This is a really bad bug report, unfortuantely I don't have a nice simple example. I have a GtkDialog with a GtkScrolledWindow containing a treeview. In response to a toggled ToggleButton, I execute the following code: static void cb_dialog_formula_guru_zoom_toggled (GtkWidget *button, FormulaGuruState *state) { GtkTreeSelection *selection = gtk_tree_view_get_selection (state->treeview); GtkTreeIter iter; GtkTreePath *path; if (gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (button))) { gtk_widget_hide (state->main_button_area); gtk_widget_hide (state->clear_button); gtk_widget_hide (state->selector_button); gtk_tree_view_set_headers_visible (state->treeview, FALSE); gtk_widget_get_size_request (state->dialog, &state->old_width_request, &state->old_height_request); gtk_window_get_size (GTK_WINDOW (state->dialog), &state->old_width, &state->old_height); gtk_widget_set_size_request (state->dialog,state->old_width_request,100); /* FIXME: the ideal `shrunk size' should probably not be hardcoded.*/ gtk_window_resize (GTK_WINDOW (state->dialog),state->old_width_request,100); gtk_window_set_resizable (GTK_WINDOW (state->dialog), FALSE); } else { gtk_widget_show (state->main_button_area); gtk_widget_show (state->clear_button); gtk_widget_show (state->selector_button); gtk_tree_view_set_headers_visible (state->treeview, TRUE); gtk_window_set_resizable (GTK_WINDOW (state->dialog), TRUE); gtk_widget_set_size_request (state->dialog, state->old_width_request, state->old_height_request); gtk_window_resize (GTK_WINDOW (state->dialog), state->old_width, state->old_height); } /* FIXME: this should keep the selection in sight, unfortunately it does not for */ /* the size reduction case. */ if (gtk_tree_selection_get_selected (selection, NULL, &iter)) { path = gtk_tree_model_get_path (GTK_TREE_MODEL (state->model), &iter); gtk_tree_view_scroll_to_cell (state->treeview, path, NULL, FALSE, 0, 0); gtk_tree_path_free (path); } return; } I would have expected that after this code the selection (if it exists) would be visible. Unfortunately, only in the case of window enlargement (else clause) does this work. In the first (if) case while the content scrolls it does not scroll far enough to make the selection visible.
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
I wrote a small testcase (different from yours, but the same idea). What seems to happen is that gtk_tree_view_size_allocate (which handles the resize, indirectly triggered by gtk_window_resize) is being called after the call to gtk_tree_view_scroll_to_cell to bring the selected cell in sight. Because of that _scroll_to_cell thinks the selected row is still in sight and doesnt scroll. So, I dont really think this is a GtkTreeView bug. I'll let you and Jonathan decide on that :).
yeah -- you'll need to scroll to cell _after_ you've resized the tree. The TreeView cannot really know about pending changes in the dialog. )-:
Pardon me? I am calling gtk_widget_set_size_request and gtk_window_resize prior to: gtk_tree_view_scroll_to_cell Now, the gtk_window_resize may only schedule a resize so that scroll_to_cell can sneak in before, but even if this isn't a treeview bug it is still a gtksomething bug. From an api point of view, I should be able to assume that after calling gtk_window_resize any further calls assume that the window size has changed.
Unfortunately, this is fundamentally the way that X works, and isn't GTK specific. It's up to the window manager to resize it, and the dialog won't know until it actually is resized if it got the size it requested. You need to listen for the configure_event on the toplevel. Only after that event has been processed can you call the scroll_to.