[Solved] treeview + gtk_tree_view_scroll_to_cell

damarcus · **Joined:** Mon Jul 11, 2011 10:24 am **Posts:** 12

Hello,

In my current project I have a tree view with drag and drop functionality. Beneath this treeview there is a table, and its fields are shown or hidden depending on the type of row that is currently selected, so the visualised size of the table differs.
The treeview is placed inside a scrolled window. There are cases that if one clicks on the last visible row of the treeview, the uppopping table overlaps this last row. Now I want to scroll to the last row to make it visible again. So I wrote his code:

Code:

  path = gtk_tree_model_get_path (model, &iter);
  while (gtk_events_pending ()) // Delay until the scrolling can be done properly.
    gtk_main_iteration();
  gtk_tree_view_scroll_to_cell (GTK_TREE_VIEW (treeview), path, NULL, FALSE, 0, 0);
  gtk_tree_path_free (path);

This works, the while loop is necessary because otherwise the srolling would be done before the table beneath the treeview has popped up.
But I figured out that the while loop causes some kind of problem. Sometimes when I click randomly on a row of the tree view and move the mouse somewhere else after the row has been selected, the row is dragged (so even with a single click, not the usual way by keeping the mouse pressed).
If I remove the while loop this is not happening. I am not sure but it seems also that this dragging effect does rarely occur when the size of the table does not change, for example when I click on two rows of the same type (the treeview displays a context menu structure), so if I click on a menu item and then on a menu item again, the dragging effect won't occur, but if I click on a row representing a separator and afterwards a row representing a menu item, the size of the table changes, and the dragging effect is more likely to occur.
The code above is always executed when one of the rows is clicked, since gtk_tree_view_scroll_to_cell (as far as I could gather from the documentation) does nothing anyway when a scolling is not necessary.

Since this may sound a bit abstact I placed a Linux 32-Bit binary (Gtk3) inside http://download-mirror.savannah.gnu.org ... ladi/test/ if somebody wants to see this, it's just necessary to load the supplied menu.xml afterwards and click for example on a separator first and then on a menu (there is a "type" column to differentiate them) so the size of the table beneath the treeview changes. Source is placed inside http://download-mirror.savannah.gnu.org ... s//obladi/ , the code above is placed at the very end of editing.c . Source is also attached to this posting, a menu file can be found at http://download-mirror.savannah.gnu.org ... ladi/test/ .
By the way I encountered this problem on a slower machine than I am usually used to work with. I can't remember having seen this effect (at least that often) on my faster machine I usually work with. So I wonder if this is a problem related to speed/time in connection with that while loop or something similar.

Linux used: Linux Mint 13 with mate, GTk 3.4

Thanks,

Marcus

tadeboro · **Posted:** Wed Oct 03, 2012 8:25 am

Hi.

I think you can solve this issue by replacing your (very hacky;) loop with idle callback. This will give GTK+ time to update itself normaly and when everything is done and ready, your idle callback will scroll the tree view.

Something similar to this should work:

Code:

  // If the last row is clicked, an overlapping of it by entry fields is avoided by this.
  path = gtk_tree_model_get_path (model, &iter);
  gdk_threads_add_idle ((GSourceFunc)fix_overlap, path);


/* This is your callback function */
static gboolean fix_overlap (GtkTreePath *path)
{
  gtk_tree_view_scroll_to_cell (GTK_TREE_VIEW (treeview), path, NULL, FALSE, 0, 0);
  gtk_tree_path_free (path);
  
  return FALSE;
}

damarcus · **Joined:** Mon Jul 11, 2011 10:24 am **Posts:** 12

Perfect! That really did it! Thanks a million!
Btw. I was informed that GtkTable has become deprecated with Gtk 3.4, so I am going to replace that with GtkGrid, too.

Thanks again!

Cheers,

Marcus

errol · **Posted:** Wed Oct 03, 2012 8:57 am

Hi,

Code:

guint               gdk_threads_add_idle                (GSourceFunc function,
                                                         gpointer data);

Was deprecated in GTK+ 3.6 please use

Code:

guint               g_idle_add                          (GSourceFunc function,
                                                         gpointer data);

So modifying Tradj's code it should look like

Code:

  // If the last row is clicked, an overlapping of it by entry fields is avoided by this.
  path = gtk_tree_model_get_path (model, &iter);
  g_idle_add ((GSourceFunc)fix_overlap, path);


/* This is your callback function */
static gboolean fix_overlap (GtkTreePath *path)
{
  gtk_tree_view_scroll_to_cell (GTK_TREE_VIEW (treeview), path, NULL, FALSE, 0, 0);
  gtk_tree_path_free (path);
 
  return FALSE;
}

damarcus · **Joined:** Mon Jul 11, 2011 10:24 am **Posts:** 12

It's really hard to keep up these days... Updated with this and works as well.

Thanks,

Marcus

tadeboro · **Posted:** Wed Oct 03, 2012 9:15 am

Hi.

Actually, gdk_threads_add_idle() is not deprecated. GDK threading related functions that were deprecated are gdk_threads_init(), gdk_threads_enter(), gdk_threads_leave() and gdk_threads_set_lock_functions().

There was a recent discussion about this topic on GTK+ mailing list and can be seen here: Clarification of GTK/GDK locking pre GTK 4.0. Main point is: if you cannot be sure that the code you use calls GTK+ functions from single thread only (this includes all of the libraries you link against), use gdk_threads_add_*() family of functions to avoid getting into trouble.

In application, posted by damarcus, g_idle_add() would work too since he's the only consumer of GTK+ library. But in complex apps (especially ones that use large body of 3rd party libraries), you're better off with gdk variant.

Cheers,
Tadej

errol · **Posted:** Wed Oct 03, 2012 9:41 am

Tadej,

Thanks for that. The documentation is not great and to be honest is a bit misleading in places on the gdk_threads_* front and the whole thing is becoming a mess.

GTK+ Forums

[Solved] treeview + gtk_tree_view_scroll_to_cell

Who is online