Re: Emitting signals from threads

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I haven't had much time to work on this but I did figure out the following:

The reason that the "Edit" dialog is being opened is that when the
click is processed by the button-press-event handler, the width of the
first column in the TreeView is 0. As a result, the calculation of
where the click occurred always ends up determining that the "Edit"
cell was clicked.

After much digging, I found out that the code which changes the width
of the first column cell to 0 is
"_gtk_tree_view_column_cell_set_dirty()" when called by
"gtk_tree_row_changed()":

Thread 1 "gtkscope" hit Hardware watchpoint 12: ((GtkTreeViewColumn
*)0xa009a0)->priv->width

Old value = 193
New value = 0
_gtk_tree_view_column_cell_set_dirty (tree_column=<optimized out>,
install_handler=1)
    at gtktreeviewcolumn.c:3006
3006   g_signal_handler_block (priv->cell_area_context,
(gdb) bt
#0  0x00007ffff739663f in _gtk_tree_view_column_cell_set_dirty
(tree_column=<optimized out>, install_handler=1) at
gtktreeviewcolumn.c:3006
#1  0x00007ffff737e8b5 in gtk_tree_view_row_changed (model=<optimized
out>, path=0x2c7b690, iter=<optimized out>, data=0x954400) at
gtktreeview.c:9020
#5  0x00007ffff599765f in <emit signal ??? on instance 0x93ef00
[GtkTreeStore]> (instance=instance@entry=0x93ef00,
signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3447
    #2  0x00007ffff597b73d in g_closure_invoke (closure=0xa01640,
return_value=0x0, n_param_values=3, param_values=0x7fffffffad10,
invocation_hint=0x7fffffffac90) at gclosure.c:804
    #3  0x00007ffff598e4ce in signal_emit_unlocked_R
(node=node@entry=0x7fffcc009fa0, detail=detail@entry=0,
instance=instance@entry=0x93ef00,
emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fffffffad10) at
gsignal.c:3635
    #4  0x00007ffff5996cf5 in g_signal_emit_valist (instance=0x93ef00,
signal_id=<optimized out>, detail=0,
var_args=var_args@entry=0x7fffffffaf10) at gsignal.c:3391
#6  0x00007ffff7365950 in gtk_tree_model_row_changed
(tree_model=tree_model@entry=0x93ef00, path=path@entry=0x2c7b690,
iter=iter@entry=0x7fffffffb130) at gtktreemodel.c:1835
#7  0x00007ffff737643b in gtk_tree_store_set_valist
(tree_store=0x93ef00 [GtkTreeStore], iter=0x7fffffffb130,
var_args=var_args@entry=0x7fffffffb030) at gtktreestore.c:1161
#8  0x00007ffff73764e4 in gtk_tree_store_set (tree_store=<optimized
out>, iter=<optimized out>)
    at gtktreestore.c:1190
...

The column is set to be with AUTOMATIC size so that code path in
gtk_tree_row_changed() gets triggered.

However, as I understand it, if my signal is running in the main
context, the signal handler should not be running at the same time as
Gtk is recalculating/repainting the TreeView. It seems as if the
threaded signal handler is not running in the main context. The above
behavior is replicated even if I switched to use g_idle_add() instead
of g_main_context_invoke_full().

On Wed, Jan 9, 2019 at 11:08 AM Mitko Haralanov <voidtrance@xxxxxxxxx> wrote:
>
> Sure, let me try to come up with something and if successful, I'll post it.
>
> Thank you.
>
> On Wed, Jan 9, 2019 at 10:33 AM Luca Bacci <luca.bacci982@xxxxxxxxx> wrote:
> >
> > Hi Mitko,
> > last time I tried creating a simple C application for testing but I did get always correct values. (Btw I used g_idle_add)
> > Can you try to write a minimal test application that still exhibits the problem? That would be very helpful!
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-list



[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux