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 103583 - GtkTreeview scroll_to alignment problem
GtkTreeview scroll_to alignment problem
Status: VERIFIED INCOMPLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
2.2.x
Other other
: Normal normal
: ---
Assigned To: gtktreeview-bugs
gtktreeview-bugs
Depends on:
Blocks:
 
 
Reported: 2003-01-15 16:42 UTC by Erik Simonsen
Modified: 2011-02-04 16:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Erik Simonsen 2003-01-15 16:42:09 UTC
Sometimes during normal execution, gtk_tree_view_clamp_node is run after
gtk_tree_view_scroll_to_X.  If gtk_tree_view_scroll_to_X has queued the
scroll, clamp node will preserve the destination, but will not maintain the
alignment.  I think the function would be improved if it checked for a
queued alignment as follows:

static void
gtk_tree_view_clamp_node_visible (GtkTreeView *tree_view,
                  GtkRBTree   *tree,
                  GtkRBNode   *node)
{
  GtkTreePath *path = NULL;
  gint use_align = 0;
  gfloat row_align = 0;
  gfloat col_align = 0;

  /* We process updates because we want to clear old selected items when we
scroll.
   * if this is removed, we get a "selection streak" at the bottom. */
  if (!GTK_WIDGET_REALIZED (tree_view))
    return;

  if (tree_view->priv->scroll_to_use_align) {
     use_align = 1;
     row_align = tree_view->priv->scroll_to_row_align;
     col_align = tree_view->priv->scroll_to_col_align;
  }

  path = _gtk_tree_view_find_path (tree_view, tree, node);

  if (path)
    {
      gtk_tree_view_scroll_to_cell (tree_view, path, NULL, use_align,
row_align, col_align);
      gtk_tree_path_free (path);
    }
}
Comment 1 Kristian Rietveld 2003-01-27 22:01:12 UTC
Rationale sounds okay. Maybe nice for 2.2.2. I didn't test it yet though.
Comment 2 Matthias Clasen 2003-06-10 09:57:04 UTC
Move remaining bugs off 2.2.2 target milestone.
Comment 3 Jonathan Blandford 2003-07-14 16:24:58 UTC
I don't see how to trigger this bug, and why fixing it in
clamp_row_visible is right.  Can you give a test case, or example of
when this will happen?

Also, you lost the gdk_window_process_updates() call and moved the
comment.  That call is important (as the comment implies. :-)
Comment 4 Soren Sandmann Pedersen 2003-07-14 16:38:05 UTC
> Also, you lost the gdk_window_process_updates() call and moved the
> comment.  That call is important (as the comment implies. :-)

Back when this bug was filed, there was no call to process_updates()
there. (See bug 101235).
Comment 5 Kristian Rietveld 2003-08-15 19:27:22 UTC
Might change behaviour => 2.4
Comment 6 Jonathan Blandford 2004-03-09 04:56:37 UTC
Ping?  Is this bug still relevant?
Comment 7 Elijah Newren 2004-06-19 18:46:14 UTC
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as
Matthias said he was trying to do himself on IRC and was asking for help with. 
If you see this message, it means I was successful at fixing the borken-ness in
bugzilla :)  Sorry for the spam; just query on this message and delete all
emails you get with this message, since there will probably be a lot.
Comment 8 Kjartan Maraas 2005-01-19 21:03:50 UTC
Closing this as there has been no movement in ascertaining this bug is still there.