After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 477175 - gtk_tree_view_set_cursor doesn't scroll the treeview correctly
gtk_tree_view_set_cursor doesn't scroll the treeview correctly
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
2.11.x
Other Linux
: Normal normal
: ---
Assigned To: gtktreeview-bugs
gtktreeview-bugs
: 510897 517495 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-09-15 10:51 UTC by Juri Pakaste
Modified: 2008-05-30 20:23 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
patch (2.82 KB, patch)
2008-01-09 10:51 UTC, Kristian Rietveld
committed Details | Review

Description Juri Pakaste 2007-09-15 10:51:29 UTC
gtk_tree_view_set_cursor doesn't work right when trying to focus on an editable entry that is on a new, partially invisible row appended to the end of the list. The problem might not be quite that specific, but at least it manifests in that situation.

This is easy to reproduce with at least xchat-gnome's IRC Preferences preference page, where there's a tree view listing words to hightlight. Happens with my own code too, so I don't think there's anything particularly magical with xchat-gnome. In xchat-gnome, when you add words to highlight, things get weird when all the words won't fit in the visible space.

I've tested this with multiple theme engines (Clearlooks, Murrina.) I'm running Ubuntu Gutsy, with Gtk+ 2.11.6. This happens with both the normal Ubuntu package and with a package that doesn't have the treeview resizing patch that's normally included in the binaries.

Symptoms:

When the new line to add wouldn't be completely visible on the screen, it looks like the treeview might be scrolled correctly, but the entry is only halfway visible.

When the new line to add would be completely invisible, the treeview is scrolled correctly, but the entry is completely invisible. It looks like just a selected line, but when you blindly type text and press enter, the text appears out of nowhere on the line.
Comment 1 Kristian Rietveld 2008-01-09 10:51:50 UTC
Created attachment 102451 [details] [review]
patch

Hmm, this one was quite nasty and took a while to find and fix.  This patch seems to do the trick.  I am not too happy about the special case in gtk_tree_view_adjustment_changed(), but I don't see another way to fix this nicely at this point.  Will try to commit later today and add extra assertions that check for this to the unit tests.
Comment 2 Kristian Rietveld 2008-01-10 09:24:51 UTC
Committed on trunk r19331 including unit test updates:

2008-01-10  Kristian Rietveld  <kris@imendio.com>

        Fix #477175, reported by Juri Pakaste.

        * gtk/gtktreeprivate.h:
        * gtk/gtktreeview.c (gtk_tree_view_top_row_to_dy): do not set
        tree_view->priv->dy here directly, just calculate the new value
        and set it on the adjustment,
        (gtk_tree_view_adjustment_changed): add guards to not call
        gtk_tree_view_dy_to_top_row() if we are currently in
        gtk_tree_view_top_row_to_dy(),
        (gtk_tree_view_put): fix coordinate annotation: these are bin_window
        coordinates, not tree coordinates,
        (gtk_tree_view_real_start_editing): add cast.

        * gtk/tests/treeview-scrolling.c: add an assertion for checking the
        position of the editable in the "create new row and start editing"
        tests.
Comment 3 Carlos Garnacho 2008-02-19 18:45:29 UTC
*** Bug 517495 has been marked as a duplicate of this bug. ***
Comment 4 Kristian Rietveld 2008-05-30 20:23:45 UTC
*** Bug 510897 has been marked as a duplicate of this bug. ***