Re: "changed" signal operation for GtkTreeSelection

[Tim Müller <zen18864 zen co uk>]

On Tuesday 03 February 2004 02:13, Ron Lockwood-Childs wrote:

> Instead of using the selection changed signal, I decided to allow the
> user to select an item, then click on it again to switch to the new
> path.  So, the application watches the "button_click_event" on the
> TreeView (returns false to let the TreeView do what it normally does
> with the button press), looks to see what row was clicked on
> (GtkTreeView::get_path_at_pos), compares that to which row is selected
> (GtkTreeView::get_cursor) and changes the directory if they match.
>
> Just a follow-up..  Hope it helps someone else.

An alternative way of achieving the same thing would be to use an idle timeout 
similar to this:

static gboolean
onSelectedRowConfirmed (gpointer rn_data)
{
   gint   rownum = GPOINTER_TO_INT(rn_data);

   g_print ("Row %d has been selected.\n", rownum);

   return FALSE;  /* don't call use again */
}

static void
onSelectionChanged (GtkTreeSelection *sel, gpointer data)
{
    GtkTreeModel  model;
    GtkTreeIter       iter_selrow;
    static gulong     handle; /* 0 */

    if (handle)
    {
        g_source_remove(handle);
        handle = 0;
    }

    if (gtk_tree_selection_get_selected(sel, &model, &iter_selrow))
    {
        GtkTreePath *path;
        gint                    rownum;

        path = gtk_tree_model_get_path(model, &iter_selrow);
        rownum = gtk_tree_path_get_indices(path)[0];  /* ugly */

        handle = g_idle_add(onSelectedRowConfirmed, GINT_TO_POINTER(rownum));

        gtk_tree_path_free(path);
    }
}

This works because all "changed" signals on the tree selection are emitted 
within one and the same main iteration, so the idle timeout will not be 
called between those consecutive changed signals in any case. So what this 
code does is set up an idle timeout with the first changed signal, that then 
gets cancelled with the next signal, and a new idle timeout is set up 
instead. The idle timeout is then called more or less immediately after that 
(ie. after control is given back to the main loop).

Something similar could also be done with a GtkTreeSelection select function 
(which has the advantage that the tree path is passed to it in the callback).

Which way is nicer is a matter of taste, I suppose  :-)

Cheers
-Tim