Re: GtkTreeView: g_signal_handlers_unblock_by_func
Tadej Borovšak wrote:
Hello.
Essentially adding a simple store model:
store = gtk_list_store_new (1, G_TYPE_STRING);
while (foo_bar != NULL)
{
gtk_list_store_append (store, &iter);
gtk_list_store_set (store, &iter, 0, my_name, -1);
}
gtk_tree_view_set_model (GTK_TREE_VIEW (treeview), GTK_TREE_MODEL (store));
g_object_unref (store);
I need to block before and unblock in the end because treeview is connected
to this signal:
g_signal_connect (treeview, "cursor-changed",
G_CALLBACK (update_model), window);
Everytime a user clicks on a row, "cursor-changed" is triggered,
update_model is called, and a new model replaces the previous one. It
happens that this model change triggers again the "cursor-changed" signal,
so to prevent "cursor-changed" from calling again update_model, I have to
block the signal before I change the store model. The issue here is the
signal must be unblocked again only at the very end. What happens now is,
the signal is unblocked at the end, but GTK still calls update_model AFTER
that... the timer solves the issue, because it forces GTK to clean all his
stuff before calling the timer... in fact this works even with the delay set
to zero...
My assumptions were correct. The thing that is causing you troubles
here is GtkTreeView's internally installed idle callbacks that update
the tree view after the function that caused the changes returns. I'm
afraid that there is no other way around it but to use g_idle_add.
Idle callbacks that are installed by GtkTreeView have quite high
priority, so your installed timeout/idle handlers will be called after
the ones GtkTreeView installed.
Thanks Tadej,
so I will use the timeout method, which according to your explanation
(and my testing) should work fine in all systems,
Cheers,
Carlos
Tadej
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkTreeView: g_signal_handlers_unblock_by_func
Hello.
> Essentially adding a simple store model:
>
> store = gtk_list_store_new (1, G_TYPE_STRING);
> while (foo_bar != NULL)
> {
> gtk_list_store_append (store, &iter);
> gtk_list_store_set (store, &iter, 0, my_name, -1);
> }
> gtk_tree_view_set_model (GTK_TREE_VIEW (treeview), GTK_TREE_MODEL (store));
> g_object_unref (store);
>
> I need to block before and unblock in the end because treeview is connected
> to this signal:
>
> g_signal_connect (treeview, "cursor-changed",
> G_CALLBACK (update_model), window);
>
> Everytime a user clicks on a row, "cursor-changed" is triggered,
> update_model is called, and a new model replaces the previous one. It
> happens that this model change triggers again the "cursor-changed" signal,
> so to prevent "cursor-changed" from calling again update_model, I have to
> block the signal before I change the store model. The issue here is the
> signal must be unblocked again only at the very end. What happens now is,
> the signal is unblocked at the end, but GTK still calls update_model AFTER
> that... the timer solves the issue, because it forces GTK to clean all his
> stuff before calling the timer... in fact this works even with the delay set
> to zero...
My assumptions were correct. The thing that is causing you troubles
here is GtkTreeView's internally installed idle callbacks that update
the tree view after the function that caused the changes returns. I'm
afraid that there is no other way around it but to use g_idle_add.
Idle callbacks that are installed by GtkTreeView have quite high
priority, so your installed timeout/idle handlers will be called after
the ones GtkTreeView installed.
Tadej
--
Tadej Borovšak
tadeboro.blogspot.com
tadeb...@gmail.com
tadej.borov...@gmail.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkTreeView: g_signal_handlers_unblock_by_func
Tadej Borovšak wrote:
Hello.
Only situation that comes to my mind that would cause
g_signal_handlers_block_by_func to misbehave is if you do something
inside blocked part of code that installs idle handler to do the real
work. What are you doing inside "do_stuff" part?
Essentially adding a simple store model:
store = gtk_list_store_new (1, G_TYPE_STRING);
while (foo_bar != NULL)
{
gtk_list_store_append (store, &iter);
gtk_list_store_set (store, &iter, 0, my_name, -1);
}
gtk_tree_view_set_model (GTK_TREE_VIEW (treeview), GTK_TREE_MODEL (store));
g_object_unref (store);
I need to block before and unblock in the end because treeview is
connected to this signal:
g_signal_connect (treeview, "cursor-changed",
G_CALLBACK (update_model), window);
Everytime a user clicks on a row, "cursor-changed" is triggered,
update_model is called, and a new model replaces the previous one. It
happens that this model change triggers again the "cursor-changed"
signal, so to prevent "cursor-changed" from calling again update_model,
I have to block the signal before I change the store model. The issue
here is the signal must be unblocked again only at the very end. What
happens now is, the signal is unblocked at the end, but GTK still calls
update_model AFTER that... the timer solves the issue, because it forces
GTK to clean all his stuff before calling the timer... in fact this
works even with the delay set to zero...
I can prepare and send to you a working example, if you are interested.
Thank you very much,
Carlos
Tadej
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkTreeView: g_signal_handlers_unblock_by_func
Hello. Only situation that comes to my mind that would cause g_signal_handlers_block_by_func to misbehave is if you do something inside blocked part of code that installs idle handler to do the real work. What are you doing inside "do_stuff" part? Tadej -- Tadej Borovšak tadeboro.blogspot.com tadeb...@gmail.com tadej.borov...@gmail.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkTreeView: g_signal_handlers_unblock_by_func
Hi all,
To avoid some reentrant callbacks, in a few cases I have to use code
such as:
g_signal_handlers_block_by_func (widget, func, data);
do_stuff;
g_signal_handlers_unblock_by_func (widget, func, data);
Usually this works fine, but I have a Treeview where unblock
seems to be done too early, before GTK finnishes handling do_stuff,
resulting in undesired callbacks. I solved the problem using a timer
such as (to delay the unblock):
g_signal_handlers_block_by_func (widget, func, data);
do_stuff;
g_timeout_add (0, my_timer, data);
int my_timer (void *data)
{
g_signal_handlers_unblock_by_func (widget, func, data);
return FALSE;
}
As I said, this seems to work fine in all systems I tested (even with
the timer delay set to 0...).
My questions are: 1) is there a better, more elegant, more robust, way
of doing this? 2) why the bock/unblock mechanism does not work as
expected in treeview?
Best regards,
Carlos
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
