Re: Emitting signals from threads

[Luca Bacci via gtk-list]

Hi, yes you should file a bug

Of course, the sizing of the column is also marked as
> "AUTOMATIC", which may be the reason why. I am assuming that it works
> for you because you are overriding the "AUTOMATIC" sizing by calling
> gtk_tree_view_column_set_resizable() after the UI has been processed.
>

Yes the problem is with AUTOMATIC sizing mode while with other sizing modes
it works correctly.

Il giorno ven 8 mar 2019 alle ore 02:20 Mitko Haralanov <
voidtra...@gmail.com> ha scritto:

> I just tried this and it doesn't work. I set the first column as
> resizable in the main.ui (through Glade) and the bad behavior is still
> present. Of course, the sizing of the column is also marked as
> "AUTOMATIC", which may be the reason why. I am assuming that it works
> for you because you are overriding the "AUTOMATIC" sizing by calling
> gtk_tree_view_column_set_resizable() after the UI has been processed.
>
> On Thu, Mar 7, 2019 at 10:47 AM Luca Bacci 
> wrote:
> >
> > try adding the line
> > gtk_tree_view_column_set_resizable (gtk_tree_view_get_column(view, 0),
> TRUE);
> >
> > Il giorno gio 7 mar 2019 alle ore 19:43 Luca Bacci <
> luca.bacci...@gmail.com> ha scritto:
> >>
> >> just setting column1 as resizable fixes the issue
> >>
> >> Il giorno gio 7 mar 2019 alle ore 18:35 Luca Bacci <
> luca.bacci...@gmail.com> ha scritto:
> >>>
> >>> Yes, go ahead.
> >>>
> >>> I don't know if that can be useful to you, but if you increase the
> time spent in usleep() to something greater it works correctly.
> >>> With usleep(1) I get mixed results:
> >>>
> >>> Third column activated
> >>> Third column activated
> >>> Activated an other column
> >>> Activated an other column
> >>> Third column activated
> >>> Activated an other column
> >>> Activated an other column
> >>> Activated an other column
> >>> Third column activated
> >>> Activated an other column
> >>> Third column activated
> >>> Third column activated
> >>> Third column activated
> >>> Activated an other column
> >>>
> >>> with usleep(10) I always get correct results:
> >>>
> >>> Activated an other column
> >>> Activated an other column
> >>> Activated an other column
> >>> Activated an other column
> >>> Activated an other column
> >>> Activated an other column
> >>> Activated an other column
> >>> Activated an other column
> >>> Activated an other column
> >>> Activated an other column
> >>> Activated an other column
> >>>
> >>>
> >>> Il giorno mer 6 mar 2019 alle ore 20:26 Mitko Haralanov <
> voidtra...@gmail.com> ha scritto:
> 
>  OK, thank you.
> 
>  Please, let me know if you'd like me to file a bug for this?
>  Thanks
> 
>  On Wed, Mar 6, 2019 at 10:27 AM Luca Bacci 
> wrote:
>  >
>  > I'm working on it. But yes, this really seems a bug in Gtk.
>  >
>  > Il mer 6 mar 2019, 18:40 Mitko Haralanov  ha
> scritto:
>  >>
>  >> Hi,
>  >>
>  >> Any update? Does anyone think this is a bug that should be filed
> against Gtk?
>  >>
>  >> Thanks
>  >>
>  >> On Thu, Feb 28, 2019 at 2:05 AM Luca Bacci <
> luca.bacci...@gmail.com> wrote:
>  >> >
>  >> > Hi, I can't promise I will find a solution but I'll certainly
> take a look at this
>  >> >
>  >> > Il gio 28 feb 2019, 02:13 Paul Davis 
> ha scritto:
>  >> >>
>  >> >> You are right, and I withdraw my remarks. As noted, I didn't
> read it carefully enough.
>  >> >>
>  >> >> But yes, g_idle_add_full() runs in the worker thread, however
> that's one thing that is always OK.
>  >> >>
>  >> >> On Wed, Feb 27, 2019 at 6:03 PM Mitko Haralanov <
> voidtra...@gmail.com> wrote:
>  >> >>>
>  >> >>> But that's not how the code is written:
>  >> >>>
>  >> >>> g_task_run_in_thread(obj->task, custom_object_work) ->
>  >> >>>   custom_object_worker() ->
>  >> >>>  signal_emit() ->
>  >> >>> g_idle_add_full(..., signal_emitter, ...);
>  >> >>>
>  >> >>> signal_emitter() is the function that *actually* emits the
> signal.
>  >> >>> signal_emitter() is supposed to be running in the main context
> thread
>  >> >>> by the virtue of being the g_idle_add_full() callback.
>  >> >>>
>  >> >>> Are you saying that the g_idle_add_full() callback also runs
> in the
>  >> >>> worker thread?
>  >> >>>
>  >> >>> On Wed, Feb 27, 2019 at 4:54 PM Paul Davis <
> p...@linuxaudiosystems.com> wrote:
>  >> >>> >
>  >> >>> >
>  >> >>> >
>  >> >>> > On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov <
> voidtra...@gmail.com> wrote:
>  >> >>> >>
>  >> >>> >> How is that? The update is happening from a callback
> executed by the
>  >> >>> >> main context thread?
>  >> >>> >
>  >> >>> >
>  >> >>> > g_task_run_in_thread(obj->task, custom_object_worker);
>  >> >>> >
>  >> >>> > custom_object_worker() emits the "updated" signal. the
> handler modifies the model.
>  >> >>> >
>  >> >>
>  >> >> 

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

I just tried this and it doesn't work. I set the first column as
resizable in the main.ui (through Glade) and the bad behavior is still
present. Of course, the sizing of the column is also marked as
"AUTOMATIC", which may be the reason why. I am assuming that it works
for you because you are overriding the "AUTOMATIC" sizing by calling
gtk_tree_view_column_set_resizable() after the UI has been processed.

On Thu, Mar 7, 2019 at 10:47 AM Luca Bacci  wrote:
>
> try adding the line
> gtk_tree_view_column_set_resizable (gtk_tree_view_get_column(view, 0), TRUE);
>
> Il giorno gio 7 mar 2019 alle ore 19:43 Luca Bacci  
> ha scritto:
>>
>> just setting column1 as resizable fixes the issue
>>
>> Il giorno gio 7 mar 2019 alle ore 18:35 Luca Bacci  
>> ha scritto:
>>>
>>> Yes, go ahead.
>>>
>>> I don't know if that can be useful to you, but if you increase the time 
>>> spent in usleep() to something greater it works correctly.
>>> With usleep(1) I get mixed results:
>>>
>>> Third column activated
>>> Third column activated
>>> Activated an other column
>>> Activated an other column
>>> Third column activated
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Third column activated
>>> Activated an other column
>>> Third column activated
>>> Third column activated
>>> Third column activated
>>> Activated an other column
>>>
>>> with usleep(10) I always get correct results:
>>>
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>>
>>>
>>> Il giorno mer 6 mar 2019 alle ore 20:26 Mitko Haralanov 
>>>  ha scritto:

 OK, thank you.

 Please, let me know if you'd like me to file a bug for this?
 Thanks

 On Wed, Mar 6, 2019 at 10:27 AM Luca Bacci  wrote:
 >
 > I'm working on it. But yes, this really seems a bug in Gtk.
 >
 > Il mer 6 mar 2019, 18:40 Mitko Haralanov  ha 
 > scritto:
 >>
 >> Hi,
 >>
 >> Any update? Does anyone think this is a bug that should be filed 
 >> against Gtk?
 >>
 >> Thanks
 >>
 >> On Thu, Feb 28, 2019 at 2:05 AM Luca Bacci  
 >> wrote:
 >> >
 >> > Hi, I can't promise I will find a solution but I'll certainly take a 
 >> > look at this
 >> >
 >> > Il gio 28 feb 2019, 02:13 Paul Davis  ha 
 >> > scritto:
 >> >>
 >> >> You are right, and I withdraw my remarks. As noted, I didn't read it 
 >> >> carefully enough.
 >> >>
 >> >> But yes, g_idle_add_full() runs in the worker thread, however that's 
 >> >> one thing that is always OK.
 >> >>
 >> >> On Wed, Feb 27, 2019 at 6:03 PM Mitko Haralanov 
 >> >>  wrote:
 >> >>>
 >> >>> But that's not how the code is written:
 >> >>>
 >> >>> g_task_run_in_thread(obj->task, custom_object_work) ->
 >> >>>   custom_object_worker() ->
 >> >>>  signal_emit() ->
 >> >>> g_idle_add_full(..., signal_emitter, ...);
 >> >>>
 >> >>> signal_emitter() is the function that *actually* emits the signal.
 >> >>> signal_emitter() is supposed to be running in the main context 
 >> >>> thread
 >> >>> by the virtue of being the g_idle_add_full() callback.
 >> >>>
 >> >>> Are you saying that the g_idle_add_full() callback also runs in the
 >> >>> worker thread?
 >> >>>
 >> >>> On Wed, Feb 27, 2019 at 4:54 PM Paul Davis 
 >> >>>  wrote:
 >> >>> >
 >> >>> >
 >> >>> >
 >> >>> > On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov 
 >> >>> >  wrote:
 >> >>> >>
 >> >>> >> How is that? The update is happening from a callback executed by 
 >> >>> >> the
 >> >>> >> main context thread?
 >> >>> >
 >> >>> >
 >> >>> > g_task_run_in_thread(obj->task, custom_object_worker);
 >> >>> >
 >> >>> > custom_object_worker() emits the "updated" signal. the handler 
 >> >>> > modifies the model.
 >> >>> >
 >> >>
 >> >> ___
 >> >> gtk-list mailing list
 >> >> gtk-list@gnome.org
 >> >> https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

OK, I can do that but I think it might be still worth the bug.

Thanks for looking into this!

On Thu, Mar 7, 2019 at 10:47 AM Luca Bacci  wrote:
>
> try adding the line
> gtk_tree_view_column_set_resizable (gtk_tree_view_get_column(view, 0), TRUE);
>
> Il giorno gio 7 mar 2019 alle ore 19:43 Luca Bacci  
> ha scritto:
>>
>> just setting column1 as resizable fixes the issue
>>
>> Il giorno gio 7 mar 2019 alle ore 18:35 Luca Bacci  
>> ha scritto:
>>>
>>> Yes, go ahead.
>>>
>>> I don't know if that can be useful to you, but if you increase the time 
>>> spent in usleep() to something greater it works correctly.
>>> With usleep(1) I get mixed results:
>>>
>>> Third column activated
>>> Third column activated
>>> Activated an other column
>>> Activated an other column
>>> Third column activated
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Third column activated
>>> Activated an other column
>>> Third column activated
>>> Third column activated
>>> Third column activated
>>> Activated an other column
>>>
>>> with usleep(10) I always get correct results:
>>>
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>> Activated an other column
>>>
>>>
>>> Il giorno mer 6 mar 2019 alle ore 20:26 Mitko Haralanov 
>>>  ha scritto:

 OK, thank you.

 Please, let me know if you'd like me to file a bug for this?
 Thanks

 On Wed, Mar 6, 2019 at 10:27 AM Luca Bacci  wrote:
 >
 > I'm working on it. But yes, this really seems a bug in Gtk.
 >
 > Il mer 6 mar 2019, 18:40 Mitko Haralanov  ha 
 > scritto:
 >>
 >> Hi,
 >>
 >> Any update? Does anyone think this is a bug that should be filed 
 >> against Gtk?
 >>
 >> Thanks
 >>
 >> On Thu, Feb 28, 2019 at 2:05 AM Luca Bacci  
 >> wrote:
 >> >
 >> > Hi, I can't promise I will find a solution but I'll certainly take a 
 >> > look at this
 >> >
 >> > Il gio 28 feb 2019, 02:13 Paul Davis  ha 
 >> > scritto:
 >> >>
 >> >> You are right, and I withdraw my remarks. As noted, I didn't read it 
 >> >> carefully enough.
 >> >>
 >> >> But yes, g_idle_add_full() runs in the worker thread, however that's 
 >> >> one thing that is always OK.
 >> >>
 >> >> On Wed, Feb 27, 2019 at 6:03 PM Mitko Haralanov 
 >> >>  wrote:
 >> >>>
 >> >>> But that's not how the code is written:
 >> >>>
 >> >>> g_task_run_in_thread(obj->task, custom_object_work) ->
 >> >>>   custom_object_worker() ->
 >> >>>  signal_emit() ->
 >> >>> g_idle_add_full(..., signal_emitter, ...);
 >> >>>
 >> >>> signal_emitter() is the function that *actually* emits the signal.
 >> >>> signal_emitter() is supposed to be running in the main context 
 >> >>> thread
 >> >>> by the virtue of being the g_idle_add_full() callback.
 >> >>>
 >> >>> Are you saying that the g_idle_add_full() callback also runs in the
 >> >>> worker thread?
 >> >>>
 >> >>> On Wed, Feb 27, 2019 at 4:54 PM Paul Davis 
 >> >>>  wrote:
 >> >>> >
 >> >>> >
 >> >>> >
 >> >>> > On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov 
 >> >>> >  wrote:
 >> >>> >>
 >> >>> >> How is that? The update is happening from a callback executed by 
 >> >>> >> the
 >> >>> >> main context thread?
 >> >>> >
 >> >>> >
 >> >>> > g_task_run_in_thread(obj->task, custom_object_worker);
 >> >>> >
 >> >>> > custom_object_worker() emits the "updated" signal. the handler 
 >> >>> > modifies the model.
 >> >>> >
 >> >>
 >> >> ___
 >> >> gtk-list mailing list
 >> >> gtk-list@gnome.org
 >> >> https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Luca Bacci via gtk-list]

try adding the line
gtk_tree_view_column_set_resizable (gtk_tree_view_get_column(view, 0),
TRUE);

Il giorno gio 7 mar 2019 alle ore 19:43 Luca Bacci 
ha scritto:

> just setting column1 as resizable
> 
> fixes the issue
>
> Il giorno gio 7 mar 2019 alle ore 18:35 Luca Bacci <
> luca.bacci...@gmail.com> ha scritto:
>
>> Yes, go ahead.
>>
>> I don't know if that can be useful to you, but if you increase the time
>> spent in usleep() to something greater it works correctly.
>> With usleep(1) I get mixed results:
>>
>> Third column activated
>> Third column activated
>> Activated an other column
>> Activated an other column
>> Third column activated
>> Activated an other column
>> Activated an other column
>> Activated an other column
>> Third column activated
>> Activated an other column
>> Third column activated
>> Third column activated
>> Third column activated
>> Activated an other column
>>
>> with usleep(10) I always get correct results:
>>
>> Activated an other column
>> Activated an other column
>> Activated an other column
>> Activated an other column
>> Activated an other column
>> Activated an other column
>> Activated an other column
>> Activated an other column
>> Activated an other column
>> Activated an other column
>> Activated an other column
>>
>>
>> Il giorno mer 6 mar 2019 alle ore 20:26 Mitko Haralanov <
>> voidtra...@gmail.com> ha scritto:
>>
>>> OK, thank you.
>>>
>>> Please, let me know if you'd like me to file a bug for this?
>>> Thanks
>>>
>>> On Wed, Mar 6, 2019 at 10:27 AM Luca Bacci 
>>> wrote:
>>> >
>>> > I'm working on it. But yes, this really seems a bug in Gtk.
>>> >
>>> > Il mer 6 mar 2019, 18:40 Mitko Haralanov  ha
>>> scritto:
>>> >>
>>> >> Hi,
>>> >>
>>> >> Any update? Does anyone think this is a bug that should be filed
>>> against Gtk?
>>> >>
>>> >> Thanks
>>> >>
>>> >> On Thu, Feb 28, 2019 at 2:05 AM Luca Bacci 
>>> wrote:
>>> >> >
>>> >> > Hi, I can't promise I will find a solution but I'll certainly take
>>> a look at this
>>> >> >
>>> >> > Il gio 28 feb 2019, 02:13 Paul Davis 
>>> ha scritto:
>>> >> >>
>>> >> >> You are right, and I withdraw my remarks. As noted, I didn't read
>>> it carefully enough.
>>> >> >>
>>> >> >> But yes, g_idle_add_full() runs in the worker thread, however
>>> that's one thing that is always OK.
>>> >> >>
>>> >> >> On Wed, Feb 27, 2019 at 6:03 PM Mitko Haralanov <
>>> voidtra...@gmail.com> wrote:
>>> >> >>>
>>> >> >>> But that's not how the code is written:
>>> >> >>>
>>> >> >>> g_task_run_in_thread(obj->task, custom_object_work) ->
>>> >> >>>   custom_object_worker() ->
>>> >> >>>  signal_emit() ->
>>> >> >>> g_idle_add_full(..., signal_emitter, ...);
>>> >> >>>
>>> >> >>> signal_emitter() is the function that *actually* emits the signal.
>>> >> >>> signal_emitter() is supposed to be running in the main context
>>> thread
>>> >> >>> by the virtue of being the g_idle_add_full() callback.
>>> >> >>>
>>> >> >>> Are you saying that the g_idle_add_full() callback also runs in
>>> the
>>> >> >>> worker thread?
>>> >> >>>
>>> >> >>> On Wed, Feb 27, 2019 at 4:54 PM Paul Davis <
>>> p...@linuxaudiosystems.com> wrote:
>>> >> >>> >
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov <
>>> voidtra...@gmail.com> wrote:
>>> >> >>> >>
>>> >> >>> >> How is that? The update is happening from a callback executed
>>> by the
>>> >> >>> >> main context thread?
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > g_task_run_in_thread(obj->task, custom_object_worker);
>>> >> >>> >
>>> >> >>> > custom_object_worker() emits the "updated" signal. the handler
>>> modifies the model.
>>> >> >>> >
>>> >> >>
>>> >> >> ___
>>> >> >> gtk-list mailing list
>>> >> >> gtk-list@gnome.org
>>> >> >> https://mail.gnome.org/mailman/listinfo/gtk-list
>>>
>>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Luca Bacci via gtk-list]

just setting column1 as resizable

fixes the issue

Il giorno gio 7 mar 2019 alle ore 18:35 Luca Bacci 
ha scritto:

> Yes, go ahead.
>
> I don't know if that can be useful to you, but if you increase the time
> spent in usleep() to something greater it works correctly.
> With usleep(1) I get mixed results:
>
> Third column activated
> Third column activated
> Activated an other column
> Activated an other column
> Third column activated
> Activated an other column
> Activated an other column
> Activated an other column
> Third column activated
> Activated an other column
> Third column activated
> Third column activated
> Third column activated
> Activated an other column
>
> with usleep(10) I always get correct results:
>
> Activated an other column
> Activated an other column
> Activated an other column
> Activated an other column
> Activated an other column
> Activated an other column
> Activated an other column
> Activated an other column
> Activated an other column
> Activated an other column
> Activated an other column
>
>
> Il giorno mer 6 mar 2019 alle ore 20:26 Mitko Haralanov <
> voidtra...@gmail.com> ha scritto:
>
>> OK, thank you.
>>
>> Please, let me know if you'd like me to file a bug for this?
>> Thanks
>>
>> On Wed, Mar 6, 2019 at 10:27 AM Luca Bacci 
>> wrote:
>> >
>> > I'm working on it. But yes, this really seems a bug in Gtk.
>> >
>> > Il mer 6 mar 2019, 18:40 Mitko Haralanov  ha
>> scritto:
>> >>
>> >> Hi,
>> >>
>> >> Any update? Does anyone think this is a bug that should be filed
>> against Gtk?
>> >>
>> >> Thanks
>> >>
>> >> On Thu, Feb 28, 2019 at 2:05 AM Luca Bacci 
>> wrote:
>> >> >
>> >> > Hi, I can't promise I will find a solution but I'll certainly take a
>> look at this
>> >> >
>> >> > Il gio 28 feb 2019, 02:13 Paul Davis 
>> ha scritto:
>> >> >>
>> >> >> You are right, and I withdraw my remarks. As noted, I didn't read
>> it carefully enough.
>> >> >>
>> >> >> But yes, g_idle_add_full() runs in the worker thread, however
>> that's one thing that is always OK.
>> >> >>
>> >> >> On Wed, Feb 27, 2019 at 6:03 PM Mitko Haralanov <
>> voidtra...@gmail.com> wrote:
>> >> >>>
>> >> >>> But that's not how the code is written:
>> >> >>>
>> >> >>> g_task_run_in_thread(obj->task, custom_object_work) ->
>> >> >>>   custom_object_worker() ->
>> >> >>>  signal_emit() ->
>> >> >>> g_idle_add_full(..., signal_emitter, ...);
>> >> >>>
>> >> >>> signal_emitter() is the function that *actually* emits the signal.
>> >> >>> signal_emitter() is supposed to be running in the main context
>> thread
>> >> >>> by the virtue of being the g_idle_add_full() callback.
>> >> >>>
>> >> >>> Are you saying that the g_idle_add_full() callback also runs in the
>> >> >>> worker thread?
>> >> >>>
>> >> >>> On Wed, Feb 27, 2019 at 4:54 PM Paul Davis <
>> p...@linuxaudiosystems.com> wrote:
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov <
>> voidtra...@gmail.com> wrote:
>> >> >>> >>
>> >> >>> >> How is that? The update is happening from a callback executed
>> by the
>> >> >>> >> main context thread?
>> >> >>> >
>> >> >>> >
>> >> >>> > g_task_run_in_thread(obj->task, custom_object_worker);
>> >> >>> >
>> >> >>> > custom_object_worker() emits the "updated" signal. the handler
>> modifies the model.
>> >> >>> >
>> >> >>
>> >> >> ___
>> >> >> gtk-list mailing list
>> >> >> gtk-list@gnome.org
>> >> >> https://mail.gnome.org/mailman/listinfo/gtk-list
>>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Luca Bacci via gtk-list]

Yes, go ahead.

I don't know if that can be useful to you, but if you increase the time
spent in usleep() to something greater it works correctly.
With usleep(1) I get mixed results:

Third column activated
Third column activated
Activated an other column
Activated an other column
Third column activated
Activated an other column
Activated an other column
Activated an other column
Third column activated
Activated an other column
Third column activated
Third column activated
Third column activated
Activated an other column

with usleep(10) I always get correct results:

Activated an other column
Activated an other column
Activated an other column
Activated an other column
Activated an other column
Activated an other column
Activated an other column
Activated an other column
Activated an other column
Activated an other column
Activated an other column


Il giorno mer 6 mar 2019 alle ore 20:26 Mitko Haralanov <
voidtra...@gmail.com> ha scritto:

> OK, thank you.
>
> Please, let me know if you'd like me to file a bug for this?
> Thanks
>
> On Wed, Mar 6, 2019 at 10:27 AM Luca Bacci 
> wrote:
> >
> > I'm working on it. But yes, this really seems a bug in Gtk.
> >
> > Il mer 6 mar 2019, 18:40 Mitko Haralanov  ha
> scritto:
> >>
> >> Hi,
> >>
> >> Any update? Does anyone think this is a bug that should be filed
> against Gtk?
> >>
> >> Thanks
> >>
> >> On Thu, Feb 28, 2019 at 2:05 AM Luca Bacci 
> wrote:
> >> >
> >> > Hi, I can't promise I will find a solution but I'll certainly take a
> look at this
> >> >
> >> > Il gio 28 feb 2019, 02:13 Paul Davis  ha
> scritto:
> >> >>
> >> >> You are right, and I withdraw my remarks. As noted, I didn't read it
> carefully enough.
> >> >>
> >> >> But yes, g_idle_add_full() runs in the worker thread, however that's
> one thing that is always OK.
> >> >>
> >> >> On Wed, Feb 27, 2019 at 6:03 PM Mitko Haralanov <
> voidtra...@gmail.com> wrote:
> >> >>>
> >> >>> But that's not how the code is written:
> >> >>>
> >> >>> g_task_run_in_thread(obj->task, custom_object_work) ->
> >> >>>   custom_object_worker() ->
> >> >>>  signal_emit() ->
> >> >>> g_idle_add_full(..., signal_emitter, ...);
> >> >>>
> >> >>> signal_emitter() is the function that *actually* emits the signal.
> >> >>> signal_emitter() is supposed to be running in the main context
> thread
> >> >>> by the virtue of being the g_idle_add_full() callback.
> >> >>>
> >> >>> Are you saying that the g_idle_add_full() callback also runs in the
> >> >>> worker thread?
> >> >>>
> >> >>> On Wed, Feb 27, 2019 at 4:54 PM Paul Davis <
> p...@linuxaudiosystems.com> wrote:
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov <
> voidtra...@gmail.com> wrote:
> >> >>> >>
> >> >>> >> How is that? The update is happening from a callback executed by
> the
> >> >>> >> main context thread?
> >> >>> >
> >> >>> >
> >> >>> > g_task_run_in_thread(obj->task, custom_object_worker);
> >> >>> >
> >> >>> > custom_object_worker() emits the "updated" signal. the handler
> modifies the model.
> >> >>> >
> >> >>
> >> >> ___
> >> >> gtk-list mailing list
> >> >> gtk-list@gnome.org
> >> >> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

OK, thank you.

Please, let me know if you'd like me to file a bug for this?
Thanks

On Wed, Mar 6, 2019 at 10:27 AM Luca Bacci  wrote:
>
> I'm working on it. But yes, this really seems a bug in Gtk.
>
> Il mer 6 mar 2019, 18:40 Mitko Haralanov  ha scritto:
>>
>> Hi,
>>
>> Any update? Does anyone think this is a bug that should be filed against Gtk?
>>
>> Thanks
>>
>> On Thu, Feb 28, 2019 at 2:05 AM Luca Bacci  wrote:
>> >
>> > Hi, I can't promise I will find a solution but I'll certainly take a look 
>> > at this
>> >
>> > Il gio 28 feb 2019, 02:13 Paul Davis  ha 
>> > scritto:
>> >>
>> >> You are right, and I withdraw my remarks. As noted, I didn't read it 
>> >> carefully enough.
>> >>
>> >> But yes, g_idle_add_full() runs in the worker thread, however that's one 
>> >> thing that is always OK.
>> >>
>> >> On Wed, Feb 27, 2019 at 6:03 PM Mitko Haralanov  
>> >> wrote:
>> >>>
>> >>> But that's not how the code is written:
>> >>>
>> >>> g_task_run_in_thread(obj->task, custom_object_work) ->
>> >>>   custom_object_worker() ->
>> >>>  signal_emit() ->
>> >>> g_idle_add_full(..., signal_emitter, ...);
>> >>>
>> >>> signal_emitter() is the function that *actually* emits the signal.
>> >>> signal_emitter() is supposed to be running in the main context thread
>> >>> by the virtue of being the g_idle_add_full() callback.
>> >>>
>> >>> Are you saying that the g_idle_add_full() callback also runs in the
>> >>> worker thread?
>> >>>
>> >>> On Wed, Feb 27, 2019 at 4:54 PM Paul Davis  
>> >>> wrote:
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov  
>> >>> > wrote:
>> >>> >>
>> >>> >> How is that? The update is happening from a callback executed by the
>> >>> >> main context thread?
>> >>> >
>> >>> >
>> >>> > g_task_run_in_thread(obj->task, custom_object_worker);
>> >>> >
>> >>> > custom_object_worker() emits the "updated" signal. the handler 
>> >>> > modifies the model.
>> >>> >
>> >>
>> >> ___
>> >> gtk-list mailing list
>> >> gtk-list@gnome.org
>> >> https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Luca Bacci via gtk-list]

I'm working on it. But yes, this really seems a bug in Gtk.

Il mer 6 mar 2019, 18:40 Mitko Haralanov  ha scritto:

> Hi,
>
> Any update? Does anyone think this is a bug that should be filed against
> Gtk?
>
> Thanks
>
> On Thu, Feb 28, 2019 at 2:05 AM Luca Bacci 
> wrote:
> >
> > Hi, I can't promise I will find a solution but I'll certainly take a
> look at this
> >
> > Il gio 28 feb 2019, 02:13 Paul Davis  ha
> scritto:
> >>
> >> You are right, and I withdraw my remarks. As noted, I didn't read it
> carefully enough.
> >>
> >> But yes, g_idle_add_full() runs in the worker thread, however that's
> one thing that is always OK.
> >>
> >> On Wed, Feb 27, 2019 at 6:03 PM Mitko Haralanov 
> wrote:
> >>>
> >>> But that's not how the code is written:
> >>>
> >>> g_task_run_in_thread(obj->task, custom_object_work) ->
> >>>   custom_object_worker() ->
> >>>  signal_emit() ->
> >>> g_idle_add_full(..., signal_emitter, ...);
> >>>
> >>> signal_emitter() is the function that *actually* emits the signal.
> >>> signal_emitter() is supposed to be running in the main context thread
> >>> by the virtue of being the g_idle_add_full() callback.
> >>>
> >>> Are you saying that the g_idle_add_full() callback also runs in the
> >>> worker thread?
> >>>
> >>> On Wed, Feb 27, 2019 at 4:54 PM Paul Davis 
> wrote:
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov <
> voidtra...@gmail.com> wrote:
> >>> >>
> >>> >> How is that? The update is happening from a callback executed by the
> >>> >> main context thread?
> >>> >
> >>> >
> >>> > g_task_run_in_thread(obj->task, custom_object_worker);
> >>> >
> >>> > custom_object_worker() emits the "updated" signal. the handler
> modifies the model.
> >>> >
> >>
> >> ___
> >> gtk-list mailing list
> >> gtk-list@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

Hi,

Any update? Does anyone think this is a bug that should be filed against Gtk?

Thanks

On Thu, Feb 28, 2019 at 2:05 AM Luca Bacci  wrote:
>
> Hi, I can't promise I will find a solution but I'll certainly take a look at 
> this
>
> Il gio 28 feb 2019, 02:13 Paul Davis  ha scritto:
>>
>> You are right, and I withdraw my remarks. As noted, I didn't read it 
>> carefully enough.
>>
>> But yes, g_idle_add_full() runs in the worker thread, however that's one 
>> thing that is always OK.
>>
>> On Wed, Feb 27, 2019 at 6:03 PM Mitko Haralanov  wrote:
>>>
>>> But that's not how the code is written:
>>>
>>> g_task_run_in_thread(obj->task, custom_object_work) ->
>>>   custom_object_worker() ->
>>>  signal_emit() ->
>>> g_idle_add_full(..., signal_emitter, ...);
>>>
>>> signal_emitter() is the function that *actually* emits the signal.
>>> signal_emitter() is supposed to be running in the main context thread
>>> by the virtue of being the g_idle_add_full() callback.
>>>
>>> Are you saying that the g_idle_add_full() callback also runs in the
>>> worker thread?
>>>
>>> On Wed, Feb 27, 2019 at 4:54 PM Paul Davis  
>>> wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov  
>>> > wrote:
>>> >>
>>> >> How is that? The update is happening from a callback executed by the
>>> >> main context thread?
>>> >
>>> >
>>> > g_task_run_in_thread(obj->task, custom_object_worker);
>>> >
>>> > custom_object_worker() emits the "updated" signal. the handler modifies 
>>> > the model.
>>> >
>>
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Luca Bacci via gtk-list]

Hi, I can't promise I will find a solution but I'll certainly take a look
at this

Il gio 28 feb 2019, 02:13 Paul Davis  ha
scritto:

> You are right, and I withdraw my remarks. As noted, I didn't read it
> carefully enough.
>
> But yes, g_idle_add_full() runs in the worker thread, however that's one
> thing that is always OK.
>
> On Wed, Feb 27, 2019 at 6:03 PM Mitko Haralanov 
> wrote:
>
>> But that's not how the code is written:
>>
>> g_task_run_in_thread(obj->task, custom_object_work) ->
>>   custom_object_worker() ->
>>  signal_emit() ->
>> g_idle_add_full(..., signal_emitter, ...);
>>
>> signal_emitter() is the function that *actually* emits the signal.
>> signal_emitter() is supposed to be running in the main context thread
>> by the virtue of being the g_idle_add_full() callback.
>>
>> Are you saying that the g_idle_add_full() callback also runs in the
>> worker thread?
>>
>> On Wed, Feb 27, 2019 at 4:54 PM Paul Davis 
>> wrote:
>> >
>> >
>> >
>> > On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov 
>> wrote:
>> >>
>> >> How is that? The update is happening from a callback executed by the
>> >> main context thread?
>> >
>> >
>> > g_task_run_in_thread(obj->task, custom_object_worker);
>> >
>> > custom_object_worker() emits the "updated" signal. the handler modifies
>> the model.
>> >
>>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Paul Davis]

You are right, and I withdraw my remarks. As noted, I didn't read it
carefully enough.

But yes, g_idle_add_full() runs in the worker thread, however that's one
thing that is always OK.

On Wed, Feb 27, 2019 at 6:03 PM Mitko Haralanov 
wrote:

> But that's not how the code is written:
>
> g_task_run_in_thread(obj->task, custom_object_work) ->
>   custom_object_worker() ->
>  signal_emit() ->
> g_idle_add_full(..., signal_emitter, ...);
>
> signal_emitter() is the function that *actually* emits the signal.
> signal_emitter() is supposed to be running in the main context thread
> by the virtue of being the g_idle_add_full() callback.
>
> Are you saying that the g_idle_add_full() callback also runs in the
> worker thread?
>
> On Wed, Feb 27, 2019 at 4:54 PM Paul Davis 
> wrote:
> >
> >
> >
> > On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov 
> wrote:
> >>
> >> How is that? The update is happening from a callback executed by the
> >> main context thread?
> >
> >
> > g_task_run_in_thread(obj->task, custom_object_worker);
> >
> > custom_object_worker() emits the "updated" signal. the handler modifies
> the model.
> >
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

But that's not how the code is written:

g_task_run_in_thread(obj->task, custom_object_work) ->
  custom_object_worker() ->
 signal_emit() ->
g_idle_add_full(..., signal_emitter, ...);

signal_emitter() is the function that *actually* emits the signal.
signal_emitter() is supposed to be running in the main context thread
by the virtue of being the g_idle_add_full() callback.

Are you saying that the g_idle_add_full() callback also runs in the
worker thread?

On Wed, Feb 27, 2019 at 4:54 PM Paul Davis  wrote:
>
>
>
> On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov  wrote:
>>
>> How is that? The update is happening from a callback executed by the
>> main context thread?
>
>
> g_task_run_in_thread(obj->task, custom_object_worker);
>
> custom_object_worker() emits the "updated" signal. the handler modifies the 
> model.
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Paul Davis]

On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov 
wrote:

> How is that? The update is happening from a callback executed by the
> main context thread?
>

g_task_run_in_thread(obj->task, custom_object_worker);

custom_object_worker() emits the "updated" signal. the handler modifies the
model.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

How is that? The update is happening from a callback executed by the
main context thread?

On Wed, Feb 27, 2019 at 4:24 PM Paul Davis  wrote:
>
>
>
> On Wed, Feb 27, 2019 at 5:17 PM Mitko Haralanov via gtk-list 
>  wrote:
>>
>> Here is a small program that illustrates the issue:
>>
>
> Yep. You're updating a treemodel from your own thread while the treeview is 
> connected to it. You can't do this.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Paul Davis]

On Wed, Feb 27, 2019 at 5:17 PM Mitko Haralanov via gtk-list <
gtk-list@gnome.org> wrote:

> Here is a small program that illustrates the issue:
>
>
Yep. You're updating a treemodel from your own thread while the treeview is
connected to it. You can't do this.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

Here is a small program that illustrates the issue:

#include 

G_BEGIN_DECLS
#define CUSTOM_OBJECT_TYPE (custom_object_get_type())
G_DECLARE_FINAL_TYPE(CustomObject, custom_object, CUSTOM, OBJECT, GObject);

enum _CustomObjectSignals
{
SIGNAL_UPDATE,
N_SIGNALS,
};

struct _CustomObject
{
GObject parent;
GCancellable *cancel;
GTask *task;
};
G_END_DECLS

G_DEFINE_TYPE(CustomObject, custom_object, G_TYPE_OBJECT);

static guint signal_id;

typedef struct _signal_args
{
const gchar *signal;
gpointer instance;
guint64 value;
} signal_args_t;

static gboolean signal_emitter(gpointer data)
{
signal_args_t *args = data;

g_signal_emit_by_name(args->instance, args->signal, args->value);
return FALSE;
}

void signal_emit(gpointer instance, const gchar *signal, guint64 value)
{
signal_args_t *args;

args = g_new0(signal_args_t, 1);
args->instance = instance;
args->signal = "updated";
args->value = value;
g_idle_add_full(G_PRIORITY_HIGH, signal_emitter, args,
(GDestroyNotify)g_free);
}

static void custom_object_finalize(GObject *object)
{
CustomObject *obj = CUSTOM_OBJECT(object);

G_OBJECT_CLASS(custom_object_parent_class)->finalize(object);
}

static void custom_object_class_init(CustomObjectClass *class)
{
GType params[] = {G_TYPE_UINT64};

G_OBJECT_CLASS(class)->finalize = custom_object_finalize;
signal_id = g_signal_newv("updated", G_TYPE_FROM_CLASS(class),
 G_SIGNAL_RUN_LAST |
G_SIGNAL_NO_RECURSE | G_SIGNAL_NO_HOOKS,
 NULL, NULL, NULL, NULL, G_TYPE_NONE,
1, params);
}

static void custom_object_init(CustomObject *object)
{
}

static CustomObject *custom_object_new(void)
{
CustomObject *object;

object = g_object_new(CUSTOM_OBJECT_TYPE, NULL);
object->cancel = g_cancellable_new();
return object;
}

static void custom_object_worker(GTask *task, gpointer source, gpointer data,
 GCancellable *cancel)
{
CustomObject *obj = CUSTOM_OBJECT(source);
guint64 value = 0;

while (!g_cancellable_is_cancelled(obj->cancel))
{
signal_emit(obj, "updated", ++value);
usleep(10);
}
}

static void custom_object_start(CustomObject *obj)
{
obj->task = g_task_new(obj, obj->cancel, NULL, NULL);
g_task_run_in_thread(obj->task, custom_object_worker);
}

static void custom_object_stop(CustomObject *obj)
{
g_cancellable_cancel(obj->cancel);
}

static void go(GtkButton *button, gpointer data)
{
CustomObject *obj = CUSTOM_OBJECT(data);

custom_object_start(obj);
}

static void on_custom_object_updated(CustomObject *obj, guint64 value,
gpointer data)
{
GtkTreeModel *model = GTK_TREE_MODEL(data);
GtkTreeIter iter;

gtk_tree_model_get_iter_first(model, );
gtk_tree_store_set(GTK_TREE_STORE(model), , 1, value, -1);
}

static gboolean on_tree_view_button_pressed(GtkWidget *widget,
GdkEvent *event, gpointer data)
{
GdkEventButton *button = (GdkEventButton *)event;
GtkTreePath *path;
GtkTreeModel *model = GTK_TREE_MODEL(data);
GtkTreeViewColumn *column;

if (button->type != GDK_BUTTON_PRESS ||
 !gtk_tree_view_get_path_at_pos(GTK_TREE_VIEW(widget),
button->x, button->y,
 , , NULL, NULL))
return FALSE;

if (strcmp(gtk_tree_view_column_get_title(column), "column 3"))
return FALSE;
printf("Third column activated\n");
}

static void renderer_data_func(GtkTreeViewColumn *column, GtkCellRenderer *cell,
 GtkTreeModel *model, GtkTreeIter *iter, gpointer data)
{
guint64 value;

gtk_tree_model_get(model, iter, 1, , -1);
if (GTK_IS_CELL_RENDERER_SPINNER(cell))
g_object_set(G_OBJECT(cell), "active", TRUE, "pulse",
value, NULL);
}

int main(int argc, char **argv)
{
GtkBuilder *builder;
GtkWidget *window, *button;
GtkTreeModel *model;
GtkTreeView *view;
GtkTreeViewColumn *column;
GtkCellRenderer *renderer;
GList *renderers;
GError *error = NULL;
CustomObject *obj;

gtk_init(, );
builder = gtk_builder_new();
if (!gtk_builder_add_from_file(builder, "main.ui", ))
{
g_printerr("Error: %s\n", error->message);
g_clear_error();
return 1;
}
obj = custom_object_new();
window = GTK_WIDGET(gtk_builder_get_object(builder, "mainWindow"));
g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
button = GTK_WIDGET(gtk_builder_get_object(builder, "goButton"));
g_signal_connect(button, "clicked", G_CALLBACK(go), obj);
model = 

Re: Emitting signals from threads

[Paul Davis]

It is possible that I haven't read this thread carefully enough.

You cannot update a GtkTreeModel or any other similar data structure that
is currently being used as "the model" by a GtkTreeView or other similar
widget, from a worker thread.

The model will emit signals reflecting what you've done to it, and the
widget will do "GTK stuff" in its handlers for those signals, which will
execute inside the worker thread.

You *can* update a GtkTreeModel (or similar) from a worker thread if you
ensure that it is detached from any view widget during your updates.


On Wed, Feb 27, 2019 at 3:45 PM Mitko Haralanov via gtk-list <
gtk-list@gnome.org> wrote:

> I could start a new thread but will be confusing for anyone who may be
> reading this thread a year from now researching a similar problem.
>
> So, with that said, let me try to clarify:
>
> The application has a GtkTreeView being populated by a GtkTreeModel.
> The TreeView has 3 columns, the last one having a GtkCellRenderPixbuf
> displaying a "gtk-edit" icon. The TreeView also has a
> button-presse-event callback connected, which checks where in the
> TreeView the mouse button has clicked and if it happens to be on the
> last column/renderer, opens an "Edit" dialog box. One of the other
> columns of the TreeView has a GtkCellRendererSpinner attached to it.
> This cell render has a cell data function that will "spin" the spinner
> when the model gets updated. The GtkTreeModel backing the TreeView
> contains a column that is of type guint64. This is the value that
> causes the GtkCellRendererSpinner to "spin" when it gets updated.
>
> The actual event which causes the model to get updated is the
> application finding a file on the filesystem matching a certain
> pattern. This discovery process is happening in a worker thread as to
> not block the main UI. In that worker thread, the filesystem is
> scanned recursively looking at all files in a directory tree. When a
> file matching the pattern is found, a function is scheduled using
> g_idle_add()/g_main_context_invoke_full(). This callback is what
> actually emits a signal whose handler updates the model.
>
> So, the worker thread is not doing the *real* signal emission. It's
> just scheduling a function to run in the main context thread, which
> does the *real* signal emission.
>
> As I mentioned in a previous email, I haven't had a lot of time to
> create a separate application to show this. I can try to do that if
> things are still not clear but I was hoping that the additional
> information, which I posted earlier might be useful.
>
> Thank you,
> - Mitko
>
> On Wed, Feb 27, 2019 at 2:18 PM Fontana Nicola  wrote:
> >
> > Il giorno mar, 08/01/2019 alle 10.02 -0800, Mitko Haralanov via gtk-list
> ha
> > scritto:
> > > Thanks for the reply.
> > > ...
> >
> > Hi,
> >
> > I find this mail thread really confusing and with a lot of misleading
> > guesses. As already stated elsewhere, a minimal working example would
> > likely be a *much* quicker way to solve your problem. I'd also suggest
> > to start a new clean mail thread.
> >
> > > One of the main reasons why I am not using g_idle_add() is the timing
> > > of the callback. I don't want to defer the processing of the callback
> > > to the "idle" time since this is signal handling related.
> >
> > g_main_context_invoke is just a wrapper around an idle GSource:
> >
> > https://gitlab.gnome.org/GNOME/glib/blob/master/glib/gmain.c#L5854
> >
> > There no magic speed gain in using it instead of g_idle_add: it just
> > happens to be more convenient.
> >
> > > Another advantage of g_main_context_invoke[_full]() is that it will
> > > check the "context" of the caller and, if possible, will call the
> > > callback directly:
> >
> > Here rings an alarm bell: you are in a worker thread and you want to
> > execute some code in the GTK thread; how can you expect that code to be
> > called directly?
> >
> > In another email you said:
> >
> > > The only thing that the threaded signal callback is doing is changing
> > > the *model*, which should be allowed.
> >
> > I don't know what a "threaded signal callback" is, but if with that you
> > meant code executed in the worker thread, can you please point me where
> > you got the idea that the model could be changed from outside the GTK
> > thread? I always thought this was *not* allowed.
> >
> > Apart from that I still did not understand if you have problems with
> > threads, with timing, with user interface not updating properly or
> > other.
> >
> > Ciao.
> > --
> > Nicola
> >
> >
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

I could start a new thread but will be confusing for anyone who may be
reading this thread a year from now researching a similar problem.

So, with that said, let me try to clarify:

The application has a GtkTreeView being populated by a GtkTreeModel.
The TreeView has 3 columns, the last one having a GtkCellRenderPixbuf
displaying a "gtk-edit" icon. The TreeView also has a
button-presse-event callback connected, which checks where in the
TreeView the mouse button has clicked and if it happens to be on the
last column/renderer, opens an "Edit" dialog box. One of the other
columns of the TreeView has a GtkCellRendererSpinner attached to it.
This cell render has a cell data function that will "spin" the spinner
when the model gets updated. The GtkTreeModel backing the TreeView
contains a column that is of type guint64. This is the value that
causes the GtkCellRendererSpinner to "spin" when it gets updated.

The actual event which causes the model to get updated is the
application finding a file on the filesystem matching a certain
pattern. This discovery process is happening in a worker thread as to
not block the main UI. In that worker thread, the filesystem is
scanned recursively looking at all files in a directory tree. When a
file matching the pattern is found, a function is scheduled using
g_idle_add()/g_main_context_invoke_full(). This callback is what
actually emits a signal whose handler updates the model.

So, the worker thread is not doing the *real* signal emission. It's
just scheduling a function to run in the main context thread, which
does the *real* signal emission.

As I mentioned in a previous email, I haven't had a lot of time to
create a separate application to show this. I can try to do that if
things are still not clear but I was hoping that the additional
information, which I posted earlier might be useful.

Thank you,
- Mitko

On Wed, Feb 27, 2019 at 2:18 PM Fontana Nicola  wrote:
>
> Il giorno mar, 08/01/2019 alle 10.02 -0800, Mitko Haralanov via gtk-list ha
> scritto:
> > Thanks for the reply.
> > ...
>
> Hi,
>
> I find this mail thread really confusing and with a lot of misleading
> guesses. As already stated elsewhere, a minimal working example would
> likely be a *much* quicker way to solve your problem. I'd also suggest
> to start a new clean mail thread.
>
> > One of the main reasons why I am not using g_idle_add() is the timing
> > of the callback. I don't want to defer the processing of the callback
> > to the "idle" time since this is signal handling related.
>
> g_main_context_invoke is just a wrapper around an idle GSource:
>
> https://gitlab.gnome.org/GNOME/glib/blob/master/glib/gmain.c#L5854
>
> There no magic speed gain in using it instead of g_idle_add: it just
> happens to be more convenient.
>
> > Another advantage of g_main_context_invoke[_full]() is that it will
> > check the "context" of the caller and, if possible, will call the
> > callback directly:
>
> Here rings an alarm bell: you are in a worker thread and you want to
> execute some code in the GTK thread; how can you expect that code to be
> called directly?
>
> In another email you said:
>
> > The only thing that the threaded signal callback is doing is changing
> > the *model*, which should be allowed.
>
> I don't know what a "threaded signal callback" is, but if with that you
> meant code executed in the worker thread, can you please point me where
> you got the idea that the model could be changed from outside the GTK
> thread? I always thought this was *not* allowed.
>
> Apart from that I still did not understand if you have problems with
> threads, with timing, with user interface not updating properly or
> other.
>
> Ciao.
> --
> Nicola
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Chris Vine via gtk-list]

On Wed, 27 Feb 2019 14:08:34 -0800
Mitko Haralanov  wrote:
> On Wed, Feb 27, 2019 at 1:10 PM Chris Vine via gtk-list
>  wrote:
> >
> > On Wed, 27 Feb 2019 09:49:43 -0800
> > Mitko Haralanov via gtk-list  wrote:
> > [snip]
> > > 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().
> >
> > I am not going to try to penetrate your code, and you may already know
> > this but a GObject signal handler executes in the thread which emits on
> > the signal.  If this is a GDK/GTK+ signal, this would/should be, in
> > almost all cases, the thread in which GTK+ runs, namely the thread
> > of the default main context.
> >
> > g_idle_add() does not of itself emit a signal.  It executes a callback
> > in the main loop of the default main context.
>
> Hi Chris,
> 
> I am not expecting g_idle_add() to emit the signal. I am calling a
> separate function scheduled by g_idle_add() or
> g_main_context_invoke_full(), which does the signal emission. I use
> g_idle_add()/g_main_context_invoke_full() to ensure that this callback
> is, in fact, running in the main context thread.
> 
> However, despite the signal emission occurring in the main context
> thread, the signal handler seems to be running at the same time as GTK
> internal functions are updating the state of the TreeView columns. As
> I understand GTK, this should not be possible.

It depends on what you mean by "at the same time".  They ought not to be
running concurrently in different threads assuming you are not trying
set that up yourself with the deprecated gdk_threads_enter()/leave() and
so forth.  But if the signal handler surrenders control to the main loop
by posting its continuations to the main loop using g_idle_add_full()/
g_main_context_invoke_full() or their cognates, and the "GTK internal
functions ... updating the state of the TreeView columns" to which you
refer do the same, then the continuations may interleave.  Plenty of
GDK drawing works that way, as I understand it.

I am not saying that is what is happening here (I haven't looked at
the code), but it might be.

Chris
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Fontana Nicola]

Il giorno mar, 08/01/2019 alle 10.02 -0800, Mitko Haralanov via gtk-list ha
scritto:
> Thanks for the reply.
> ...

Hi,

I find this mail thread really confusing and with a lot of misleading
guesses. As already stated elsewhere, a minimal working example would
likely be a *much* quicker way to solve your problem. I'd also suggest
to start a new clean mail thread.

> One of the main reasons why I am not using g_idle_add() is the timing
> of the callback. I don't want to defer the processing of the callback
> to the "idle" time since this is signal handling related.

g_main_context_invoke is just a wrapper around an idle GSource:

https://gitlab.gnome.org/GNOME/glib/blob/master/glib/gmain.c#L5854

There no magic speed gain in using it instead of g_idle_add: it just
happens to be more convenient.

> Another advantage of g_main_context_invoke[_full]() is that it will
> check the "context" of the caller and, if possible, will call the
> callback directly:

Here rings an alarm bell: you are in a worker thread and you want to
execute some code in the GTK thread; how can you expect that code to be
called directly?

In another email you said:

> The only thing that the threaded signal callback is doing is changing
> the *model*, which should be allowed.

I don't know what a "threaded signal callback" is, but if with that you
meant code executed in the worker thread, can you please point me where
you got the idea that the model could be changed from outside the GTK
thread? I always thought this was *not* allowed.

Apart from that I still did not understand if you have problems with
threads, with timing, with user interface not updating properly or
other.

Ciao.
-- 
Nicola


___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

Hi Chris,

I am not expecting g_idle_add() to emit the signal. I am calling a
separate function scheduled by g_idle_add() or
g_main_context_invoke_full(), which does the signal emission. I use
g_idle_add()/g_main_context_invoke_full() to ensure that this callback
is, in fact, running in the main context thread.

However, despite the signal emission occurring in the main context
thread, the signal handler seems to be running at the same time as GTK
internal functions are updating the state of the TreeView columns. As
I understand GTK, this should not be possible.

- Mitko

On Wed, Feb 27, 2019 at 1:10 PM Chris Vine via gtk-list
 wrote:
>
> On Wed, 27 Feb 2019 09:49:43 -0800
> Mitko Haralanov via gtk-list  wrote:
> [snip]
> > 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().
>
> I am not going to try to penetrate your code, and you may already know
> this but a GObject signal handler executes in the thread which emits on
> the signal.  If this is a GDK/GTK+ signal, this would/should be, in
> almost all cases, the thread in which GTK+ runs, namely the thread
> of the default main context.
>
> g_idle_add() does not of itself emit a signal.  It executes a callback
> in the main loop of the default main context.
>
> Chris
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Chris Vine via gtk-list]

On Wed, 27 Feb 2019 09:49:43 -0800
Mitko Haralanov via gtk-list  wrote:
[snip]
> 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().

I am not going to try to penetrate your code, and you may already know
this but a GObject signal handler executes in the thread which emits on
the signal.  If this is a GDK/GTK+ signal, this would/should be, in
almost all cases, the thread in which GTK+ runs, namely the thread
of the default main context.

g_idle_add() does not of itself emit a signal.  It executes a callback
in the main loop of the default main context.

Chris
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

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=,
install_handler=1)
at gtktreeviewcolumn.c:3006
3006   g_signal_handler_block (priv->cell_area_context,
(gdb) bt
#0  0x7739663f in _gtk_tree_view_column_cell_set_dirty
(tree_column=, install_handler=1) at
gtktreeviewcolumn.c:3006
#1  0x7737e8b5 in gtk_tree_view_row_changed (model=, path=0x2c7b690, iter=, data=0x954400) at
gtktreeview.c:9020
#5  0x7599765f in  (instance=instance@entry=0x93ef00,
signal_id=, detail=detail@entry=0) at gsignal.c:3447
#2  0x7597b73d in g_closure_invoke (closure=0xa01640,
return_value=0x0, n_param_values=3, param_values=0x7fffad10,
invocation_hint=0x7fffac90) at gclosure.c:804
#3  0x7598e4ce 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=0x7fffad10) at
gsignal.c:3635
#4  0x75996cf5 in g_signal_emit_valist (instance=0x93ef00,
signal_id=, detail=0,
var_args=var_args@entry=0x7fffaf10) at gsignal.c:3391
#6  0x77365950 in gtk_tree_model_row_changed
(tree_model=tree_model@entry=0x93ef00, path=path@entry=0x2c7b690,
iter=iter@entry=0x7fffb130) at gtktreemodel.c:1835
#7  0x7737643b in gtk_tree_store_set_valist
(tree_store=0x93ef00 [GtkTreeStore], iter=0x7fffb130,
var_args=var_args@entry=0x7fffb030) at gtktreestore.c:1161
#8  0x773764e4 in gtk_tree_store_set (tree_store=, iter=)
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  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  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@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

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  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@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

I never said it worked with g_idle_add() (or if I did, I made a typing
mistake). Actually, what I said is that it *doesn't* work with
g_idle_add().

I am not entirely sure what bug "in my code" I could have found since
my code is not responsible for managing and/or painting the columns.
This should be handled entirely in the library. The only thing that
the threaded signal callback is doing is changing the *model*, which
should be allowed. The button click callback is obviously executing
the same code

On Wed, Jan 9, 2019 at 9:37 AM Chris Vine via gtk-list
 wrote:
>
> On Tue, 8 Jan 2019 10:02:58 -0800
> Mitko Haralanov via gtk-list  wrote:
> > Thanks for the reply.
> >
> > When calling g_main_context_invoke_full(), I am using NULL as the
> > context pointer. According to the documentation of
> > g_main_context_invoke():
> >
> > "If context is NULL then the global default main context — as
> > returned by g_main_context_default() — is used."
> >
> > So, the code should be using the correct context.
> >
> > One of the main reasons why I am not using g_idle_add() is the timing
> > of the callback. I don't want to defer the processing of the callback
> > to the "idle" time since this is signal handling related. Another
> > advantage of g_main_context_invoke[_full]() is that it will check the
> > "context" of the caller and, if possible, will call the callback
> > directly:
> >
> >"If context is owned by the current thread, function is called
> > directly. Otherwise, if context is the thread-default main context of
> > the current thread and g_main_context_acquire()
> >succeeds, then function is called and g_main_context_release()
> > is called afterwards.
> >In any other case, an idle source is created to call function
> > and that source is attached to context (presumably to be run in
> > another thread). The idle source is attached with
> >G_PRIORITY_DEFAULT priority. If you want a different priority,
> > use g_main_context_invoke_full()."
> >
> > Your suggested implementation is basically the GLib's async queues.
> > Or, may be, a custom event source. However, it seems that
> > g_main_context_invoke_full() should be doing exactly that. With all
> > due respect, I also don't see how it would solve the issue. If the
> > current implementation has an problem with locking/race conditions,
> > would your suggested implementation suffer from the same issue since
> > it's using the same or similar mechanism for calling the callback?
>
> "With all due respect" this is fine, but I am not sure what more your
> interlocutor can say.  If your code works with g_idle_add() but not
> with g_main_context_invoke_full() then you have a timing issue in your
> code caused by the fact that the callbacks for the default main loop via
> g_main_context_invoke_full() may be executed before the callbacks for
> earlier invocations of g_idle_add().
>
> If it doesn't work with either of them then you have some other issue.
> It is possible you have found a bug in glib but more likely you have
> found a bug in your code.
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Luca Bacci via gtk-list]

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@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Luca Bacci via gtk-list]

s an
> item to
> > >> > > > > that todo-list and schedules a call to your function. If your
> function
> > >> > > > > doesn't return false, it won't even be taken down from the
> todo-list.
> > >> > > > > Each click event ends on that todo-list. Each column resize
> adds
> > >> > > > > multiple items to that todo-list (depending on your column
> resize
> > >> > > > > policy and the number of rows). As soon as you add more items
> to that
> > >> > > > > list, your UI becomes unresponsive. It seems advisable to
> build your
> > >> > > > > own shadow todo-list for the update process, i.e.:
> > >> > > > > * setup a function "update_progress"
> > >> > > > > * on the first threaded update event, call idle_add for the
> function
> > >> > > > > and put the new progress and the row number in your own data
> structure
> > >> > > > > * while the function is still "planned in for idle_add", just
> add new
> > >> > > > > events to your own data structure
> > >> > > > > * process 1 to 10 (maybe some more) events on each of the
> calls
> > >> > > > > * the function returns true as long as there is still some
> events in
> > >> > > > > your own list; it returns false otherwise
> > >> > > > > * apply mutex checks on your data structure (not sure if i
> should
> > >> > > > > mention, I am sure you had this in your mind already)
> > >> > > > >
> > >> > > > > Each time you update a progress bar in your treeview, several
> (at least
> > >> > > > > one) events are added to the gtk-todo list (repaint!,
> re-order? and
> > >> > > > > maybe some more). Doing multiple progress events at once may
> lower the
> > >> > > > > amount of events, gtk has to process (a re-order affects all
> rows -
> > >> > > > > doing an update on multiple rows does not change anything
> here).
> > >> > > > >
> > >> > > > > That's my 5 cents. I hope it helped a bit.
> > >> > > > >
> > >> > > > >
> > >> > > > > regards,
> > >> > > > >
> > >> > > > >
> > >> > > > > ente
> > >> > > > >
> > >> > > > >
> > >> > > > > On Mon, 2019-01-07 at 08:28 -0800, Mitko Haralanov via
> gtk-list wrote:
> > >> > > > > > Anyone have any ideas? I still can't figure out why the
> column sizes
> > >> > > > > > go to
> > >> > > > > > 0.
> > >> > > > > >
> > >> > > > > > Thank you.
> > >> > > > > >
> > >> > > > > > On Tue, Dec 18, 2018, 13:40 Mitko Haralanov <
> > >> > > > > > voidtra...@gmail.com
> > >> > > > > >  wrote:
> > >> > > > > >
> > >> > > > > > > This is Gtk3:
> > >> > > > > > > gtk3-3.22.26-2.fc27.x86_64
> > >> > > > > > >
> > >> > > > > > > On Tue, Dec 18, 2018 at 1:14 PM Luca Bacci via gtk-list <
> > >> > > > > > > gtk-list@gnome.org
> > >> > > > > > > > wrote:
> > >> > > > > > >
> > >> > > > > > > > Is it Gtk2 or Gtk3, which version exactly?
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > > > Il giorno mar 18 dic 2018 alle ore 18:47 Mitko
> Haralanov via gtk-
> > >> > > > > > > > list <
> > >> > > > > > > > gtk-list@gnome.org
> > >> > > > > > > > > ha scritto:
> > >> > > > > > > >
> > >> > > > > > > > > I mistakenly replied only to Luca!! Forwarding to the
> list.
> > >> > > > > > > > >
> > >> > > > > > > > > (Sorry, Luca, my bad)
> > >> > > > > > > > > - Mitko
> > >> > > > > > &g

Re: Emitting signals from threads

[Chris Vine via gtk-list]

On Tue, 8 Jan 2019 10:02:58 -0800
Mitko Haralanov via gtk-list  wrote:
> Thanks for the reply.
> 
> When calling g_main_context_invoke_full(), I am using NULL as the
> context pointer. According to the documentation of
> g_main_context_invoke():
> 
> "If context is NULL then the global default main context — as
> returned by g_main_context_default() — is used."
> 
> So, the code should be using the correct context.
> 
> One of the main reasons why I am not using g_idle_add() is the timing
> of the callback. I don't want to defer the processing of the callback
> to the "idle" time since this is signal handling related. Another
> advantage of g_main_context_invoke[_full]() is that it will check the
> "context" of the caller and, if possible, will call the callback
> directly:
> 
>"If context is owned by the current thread, function is called
> directly. Otherwise, if context is the thread-default main context of
> the current thread and g_main_context_acquire()
>succeeds, then function is called and g_main_context_release()
> is called afterwards.
>In any other case, an idle source is created to call function
> and that source is attached to context (presumably to be run in
> another thread). The idle source is attached with
>G_PRIORITY_DEFAULT priority. If you want a different priority,
> use g_main_context_invoke_full()."
> 
> Your suggested implementation is basically the GLib's async queues.
> Or, may be, a custom event source. However, it seems that
> g_main_context_invoke_full() should be doing exactly that. With all
> due respect, I also don't see how it would solve the issue. If the
> current implementation has an problem with locking/race conditions,
> would your suggested implementation suffer from the same issue since
> it's using the same or similar mechanism for calling the callback?

"With all due respect" this is fine, but I am not sure what more your
interlocutor can say.  If your code works with g_idle_add() but not
with g_main_context_invoke_full() then you have a timing issue in your
code caused by the fact that the callbacks for the default main loop via
g_main_context_invoke_full() may be executed before the callbacks for
earlier invocations of g_idle_add().

If it doesn't work with either of them then you have some other issue.
It is possible you have found a bug in glib but more likely you have
found a bug in your code.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

ction "update_progress"
> >> > > > > * on the first threaded update event, call idle_add for the 
> >> > > > > function
> >> > > > > and put the new progress and the row number in your own data 
> >> > > > > structure
> >> > > > > * while the function is still "planned in for idle_add", just add 
> >> > > > > new
> >> > > > > events to your own data structure
> >> > > > > * process 1 to 10 (maybe some more) events on each of the calls
> >> > > > > * the function returns true as long as there is still some events 
> >> > > > > in
> >> > > > > your own list; it returns false otherwise
> >> > > > > * apply mutex checks on your data structure (not sure if i should
> >> > > > > mention, I am sure you had this in your mind already)
> >> > > > >
> >> > > > > Each time you update a progress bar in your treeview, several (at 
> >> > > > > least
> >> > > > > one) events are added to the gtk-todo list (repaint!, re-order? and
> >> > > > > maybe some more). Doing multiple progress events at once may lower 
> >> > > > > the
> >> > > > > amount of events, gtk has to process (a re-order affects all rows -
> >> > > > > doing an update on multiple rows does not change anything here).
> >> > > > >
> >> > > > > That's my 5 cents. I hope it helped a bit.
> >> > > > >
> >> > > > >
> >> > > > > regards,
> >> > > > >
> >> > > > >
> >> > > > > ente
> >> > > > >
> >> > > > >
> >> > > > > On Mon, 2019-01-07 at 08:28 -0800, Mitko Haralanov via gtk-list 
> >> > > > > wrote:
> >> > > > > > Anyone have any ideas? I still can't figure out why the column 
> >> > > > > > sizes
> >> > > > > > go to
> >> > > > > > 0.
> >> > > > > >
> >> > > > > > Thank you.
> >> > > > > >
> >> > > > > > On Tue, Dec 18, 2018, 13:40 Mitko Haralanov <
> >> > > > > > voidtra...@gmail.com
> >> > > > > >  wrote:
> >> > > > > >
> >> > > > > > > This is Gtk3:
> >> > > > > > > gtk3-3.22.26-2.fc27.x86_64
> >> > > > > > >
> >> > > > > > > On Tue, Dec 18, 2018 at 1:14 PM Luca Bacci via gtk-list <
> >> > > > > > > gtk-list@gnome.org
> >> > > > > > > > wrote:
> >> > > > > > >
> >> > > > > > > > Is it Gtk2 or Gtk3, which version exactly?
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > Il giorno mar 18 dic 2018 alle ore 18:47 Mitko Haralanov via 
> >> > > > > > > > gtk-
> >> > > > > > > > list <
> >> > > > > > > > gtk-list@gnome.org
> >> > > > > > > > > ha scritto:
> >> > > > > > > >
> >> > > > > > > > > I mistakenly replied only to Luca!! Forwarding to the list.
> >> > > > > > > > >
> >> > > > > > > > > (Sorry, Luca, my bad)
> >> > > > > > > > > - Mitko
> >> > > > > > > > >
> >> > > > > > > > > -- Forwarded message -
> >> > > > > > > > > From: Mitko Haralanov <
> >> > > > > > > > > voidtra...@gmail.com
> >> > > > > > > > > >
> >> > > > > > > > > Date: Tue, Dec 18, 2018 at 9:37 AM
> >> > > > > > > > > Subject: Re: Emitting signals from threads
> >> > > > > > > > > To: Luca Bacci <
> >> > > > > > > > > luca.bacci...@gmail.com
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >&

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

 voidtra...@gmail.com
> >  wrote:
> >
> > > This is Gtk3:
> > > gtk3-3.22.26-2.fc27.x86_64
> > >
> > > On Tue, Dec 18, 2018 at 1:14 PM Luca Bacci via gtk-list <
> > > gtk-list@gnome.org
> > > > wrote:
> > >
> > > > Is it Gtk2 or Gtk3, which version exactly?
> > > >
> > > >
> > > > Il giorno mar 18 dic 2018 alle ore 18:47 Mitko Haralanov via gtk-
> > > > list <
> > > > gtk-list@gnome.org
> > > > > ha scritto:
> > > >
> > > > > I mistakenly replied only to Luca!! Forwarding to the list.
> > > > >
> > > > > (Sorry, Luca, my bad)
> > > > > - Mitko
> > > > >
> > > > > -- Forwarded message -
> > > > > From: Mitko Haralanov <
> > > > > voidtra...@gmail.com
> > > > > >
> > > > > Date: Tue, Dec 18, 2018 at 9:37 AM
> > > > > Subject: Re: Emitting signals from threads
> > > > > To: Luca Bacci <
> > > > > luca.bacci...@gmail.com
> > > > > >
> > > > >
> > > > >
> > > > > I found something that is different between the two cases -
> > > > > button click
> > > > > with signals and without.
> > > > >
> > > > > Using the code from the link that Luca posted, I decided to
> > > > > print the
> > > > > size of each column when a button press is received. As it
> > > > > turns out, the
> > > > > width of the columns is different in the two cases:
> > > > >
> > > > > Without thread signals:
> > > > > column[0](193) = 0 -> 193
> > > > > cell[0] = min->109, natural->109
> > > > > column[1](66) = 193 -> 259
> > > > > cell[0] = min->20, natural->20
> > > > > cell[1] = min->16, natural->16
> > > > > cell[2] = min->35, natural->35
> > > > > column[2](36) = 259 -> 295
> > > > > cell[0] = min->16, natural->16
> > > > > x = 105.872116, y = 259.547516
> > > > >
> > > > > (x and y are the coordinates of the button press event)
> > > > >
> > > > > With thread signals:
> > > > > column[0](0) = 0 -> 0
> > > > > cell[0] = min->135, natural->135
> > > > > column[1](66) = 0 -> 66
> > > > > cell[0] = min->20, natural->20
> > > > > cell[1] = min->16, natural->16
> > > > > cell[2] = min->35, natural->35
> > > > > column[2](36) = 66 -> 102
> > > > > cell[0] = min->16, natural->16
> > > > > x = 113.528488, y = 158.563782
> > > > >
> > > > > As you can see, the width of the first column is 0 when the
> > > > > signals are
> > > > > being emitted. As expected, if I were to click very close to
> > > > > the left
> > > > > border of the widget, the edit dialog does not get triggered as
> > > > > the x
> > > > > coordinate falls within column 1:
> > > > >
> > > > > column[0](0) = 0 -> 0
> > > > > cell[0] = min->135, natural->135
> > > > > column[1](66) = 0 -> 66
> > > > > cell[0] = min->20, natural->20
> > > > > cell[1] = min->16, natural->16
> > > > > cell[2] = min->35, natural->35
> > > > > column[2](36) = 66 -> 102
> > > > > cell[0] = min->16, natural->16
> > > > > x = 21.247330, y = 181.310333
> > > > >
> > > > > I could use the cell renderer width if the column width is 0
> > > > > but that
> > > > > seems unreliable since the cell renderer width is not the same
> > > > > as the
> > > > > column and it's also not static.
> > > > >
> > > > > On Tue, Dec 18, 2018 at 8:23 AM Mitko Haralanov <
> > > > > voidtra...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > I am not posting the complete function because there is a lot
> > > > > > of
> > > > > > irrelevant code. I am also not interested in the specific
> > > > > > cell renderer but
> > > > > > rather the row 

Re: Emitting signals from threads

[ente]

Hi,


I am not sure with my answer. Treat it as unreliable.

There seems to be a difference between g_idle_add
and g_main_context_invoke_full. While the documentation of idle_add
says:
"Adds a function to be called [...] to the default main loop." (i.e.
main thread / the only gtk-thread) g_main_context_invoke_full does not
mention the main loop - although it mentions a "context" which I have
no experience with and which may be related to the main loop. So maybe
you must retrieve the correct context using g_main_context_default or
g_main_context_acquire. Keep in mind: glib is thread safe, gtk is not.
g_main_context_invoke_full may support glib multi threading while
g_idle_add clearly sends your function call to the gtk thread.

The effect you are describing makes sense to me. The effects you
observe sound very much like race conditions in the treeview event
handler.

Why aren't you using g_idle_add in the first place? In my experience
this works like a charm. Be careful with one thing tho: The main loop
has a "todo-list". Each time you call "g_idle_add" it adds an item to
that todo-list and schedules a call to your function. If your function
doesn't return false, it won't even be taken down from the todo-list.
Each click event ends on that todo-list. Each column resize adds
multiple items to that todo-list (depending on your column resize
policy and the number of rows). As soon as you add more items to that
list, your UI becomes unresponsive. It seems advisable to build your
own shadow todo-list for the update process, i.e.:
* setup a function "update_progress"
* on the first threaded update event, call idle_add for the function
and put the new progress and the row number in your own data structure
* while the function is still "planned in for idle_add", just add new
events to your own data structure
* process 1 to 10 (maybe some more) events on each of the calls
* the function returns true as long as there is still some events in
your own list; it returns false otherwise
* apply mutex checks on your data structure (not sure if i should
mention, I am sure you had this in your mind already)

Each time you update a progress bar in your treeview, several (at least
one) events are added to the gtk-todo list (repaint!, re-order? and
maybe some more). Doing multiple progress events at once may lower the
amount of events, gtk has to process (a re-order affects all rows -
doing an update on multiple rows does not change anything here).

That's my 5 cents. I hope it helped a bit.


regards,


ente


On Mon, 2019-01-07 at 08:28 -0800, Mitko Haralanov via gtk-list wrote:
> Anyone have any ideas? I still can't figure out why the column sizes
> go to
> 0.
> 
> Thank you.
> 
> On Tue, Dec 18, 2018, 13:40 Mitko Haralanov <
> voidtra...@gmail.com
>  wrote:
> 
> > This is Gtk3:
> > gtk3-3.22.26-2.fc27.x86_64
> > 
> > On Tue, Dec 18, 2018 at 1:14 PM Luca Bacci via gtk-list <
> > gtk-list@gnome.org
> > > wrote:
> > 
> > > Is it Gtk2 or Gtk3, which version exactly?
> > > 
> > > 
> > > Il giorno mar 18 dic 2018 alle ore 18:47 Mitko Haralanov via gtk-
> > > list <
> > > gtk-list@gnome.org
> > > > ha scritto:
> > > 
> > > > I mistakenly replied only to Luca!! Forwarding to the list.
> > > > 
> > > > (Sorry, Luca, my bad)
> > > > - Mitko
> > > > 
> > > > -- Forwarded message -
> > > > From: Mitko Haralanov <
> > > > voidtra...@gmail.com
> > > > >
> > > > Date: Tue, Dec 18, 2018 at 9:37 AM
> > > > Subject: Re: Emitting signals from threads
> > > > To: Luca Bacci <
> > > > luca.bacci...@gmail.com
> > > > >
> > > > 
> > > > 
> > > > I found something that is different between the two cases -
> > > > button click
> > > > with signals and without.
> > > > 
> > > > Using the code from the link that Luca posted, I decided to
> > > > print the
> > > > size of each column when a button press is received. As it
> > > > turns out, the
> > > > width of the columns is different in the two cases:
> > > > 
> > > > Without thread signals:
> > > > column[0](193) = 0 -> 193
> > > > cell[0] = min->109, natural->109
> > > > column[1](66) = 193 -> 259
> > > > cell[0] = min->20, natural->20
> > > > cell[1] = min->16, natural->16
> > > > cell[2] = min->35, natural->35
> > > > column[2](36) = 259 -> 295
> > > > cell[0] = min->16, natural->16
> > >

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

Anyone have any ideas? I still can't figure out why the column sizes go to
0.

Thank you.

On Tue, Dec 18, 2018, 13:40 Mitko Haralanov  This is Gtk3:
> gtk3-3.22.26-2.fc27.x86_64
>
> On Tue, Dec 18, 2018 at 1:14 PM Luca Bacci via gtk-list <
> gtk-list@gnome.org> wrote:
>
>> Is it Gtk2 or Gtk3, which version exactly?
>>
>>
>> Il giorno mar 18 dic 2018 alle ore 18:47 Mitko Haralanov via gtk-list <
>> gtk-list@gnome.org> ha scritto:
>>
>>> I mistakenly replied only to Luca!! Forwarding to the list.
>>>
>>> (Sorry, Luca, my bad)
>>> - Mitko
>>>
>>> ------ Forwarded message -
>>> From: Mitko Haralanov 
>>> Date: Tue, Dec 18, 2018 at 9:37 AM
>>> Subject: Re: Emitting signals from threads
>>> To: Luca Bacci 
>>>
>>>
>>> I found something that is different between the two cases - button click
>>> with signals and without.
>>>
>>> Using the code from the link that Luca posted, I decided to print the
>>> size of each column when a button press is received. As it turns out, the
>>> width of the columns is different in the two cases:
>>>
>>> Without thread signals:
>>> column[0](193) = 0 -> 193
>>> cell[0] = min->109, natural->109
>>> column[1](66) = 193 -> 259
>>> cell[0] = min->20, natural->20
>>> cell[1] = min->16, natural->16
>>> cell[2] = min->35, natural->35
>>> column[2](36) = 259 -> 295
>>> cell[0] = min->16, natural->16
>>> x = 105.872116, y = 259.547516
>>>
>>> (x and y are the coordinates of the button press event)
>>>
>>> With thread signals:
>>> column[0](0) = 0 -> 0
>>> cell[0] = min->135, natural->135
>>> column[1](66) = 0 -> 66
>>> cell[0] = min->20, natural->20
>>> cell[1] = min->16, natural->16
>>> cell[2] = min->35, natural->35
>>> column[2](36) = 66 -> 102
>>> cell[0] = min->16, natural->16
>>> x = 113.528488, y = 158.563782
>>>
>>> As you can see, the width of the first column is 0 when the signals are
>>> being emitted. As expected, if I were to click very close to the left
>>> border of the widget, the edit dialog does not get triggered as the x
>>> coordinate falls within column 1:
>>>
>>> column[0](0) = 0 -> 0
>>> cell[0] = min->135, natural->135
>>> column[1](66) = 0 -> 66
>>> cell[0] = min->20, natural->20
>>> cell[1] = min->16, natural->16
>>> cell[2] = min->35, natural->35
>>> column[2](36) = 66 -> 102
>>> cell[0] = min->16, natural->16
>>> x = 21.247330, y = 181.310333
>>>
>>> I could use the cell renderer width if the column width is 0 but that
>>> seems unreliable since the cell renderer width is not the same as the
>>> column and it's also not static.
>>>
>>> On Tue, Dec 18, 2018 at 8:23 AM Mitko Haralanov 
>>> wrote:
>>>
>>>> I am not posting the complete function because there is a lot of
>>>> irrelevant code. I am also not interested in the specific cell renderer but
>>>> rather the row on which the click occurred.
>>>>
>>>> tatic gboolean on_button_press_event(GtkWidget *widget,
>>>>   GdkEvent *event,
>>>>   gpointer data)
>>>> {
>>>> GtkTreeView *treeview = GTK_TREE_VIEW(widget);
>>>> GdkEventButton *button = (GdkEventButton *)event;
>>>> GtkTreeModel *model;
>>>> GtkTreePath *path;
>>>> GtkTreeIter iter;
>>>> GtkTreeViewColumn *column;
>>>> GtkScopeProjectEditDialog *dialog;
>>>> GtkScopeProjectEditData *pdata, fill;
>>>> GtkScopeProject *project;
>>>> guint response, index;
>>>> gboolean ret = FALSE;
>>>>
>>>> if (button->type != GDK_BUTTON_PRESS ||
>>>> !gtk_tree_view_get_path_at_pos(treeview, button->x, button->y,
>>>>, , NULL, NULL))
>>>> return FALSE;
>>>>
>>>> index = GPOINTER_TO_UINT(g_object_get_data(G_OBJECT(column), "index"));
>>>> if (index != TREEVIEW_COLUMN_EDIT)
>>>> goto done;
>>>> model = gtk_tree_view_get_model(treeview);
>>>> if (!gtk_tree_model_get_iter(model, , path))
>>>> goto done;
>>>> gtk_tree_model_get(model, , PROJECT_COLUMN_OBJ, , -1);
>>>> ...
>>&

Re: Emitting signals from threads

[Mitko Haralanov via gtk-list]

This is Gtk3:
gtk3-3.22.26-2.fc27.x86_64

On Tue, Dec 18, 2018 at 1:14 PM Luca Bacci via gtk-list 
wrote:

> Is it Gtk2 or Gtk3, which version exactly?
>
>
> Il giorno mar 18 dic 2018 alle ore 18:47 Mitko Haralanov via gtk-list <
> gtk-list@gnome.org> ha scritto:
>
>> I mistakenly replied only to Luca!! Forwarding to the list.
>>
>> (Sorry, Luca, my bad)
>> - Mitko
>>
>> -- Forwarded message -
>> From: Mitko Haralanov 
>> Date: Tue, Dec 18, 2018 at 9:37 AM
>> Subject: Re: Emitting signals from threads
>> To: Luca Bacci 
>>
>>
>> I found something that is different between the two cases - button click
>> with signals and without.
>>
>> Using the code from the link that Luca posted, I decided to print the
>> size of each column when a button press is received. As it turns out, the
>> width of the columns is different in the two cases:
>>
>> Without thread signals:
>> column[0](193) = 0 -> 193
>> cell[0] = min->109, natural->109
>> column[1](66) = 193 -> 259
>> cell[0] = min->20, natural->20
>> cell[1] = min->16, natural->16
>> cell[2] = min->35, natural->35
>> column[2](36) = 259 -> 295
>> cell[0] = min->16, natural->16
>> x = 105.872116, y = 259.547516
>>
>> (x and y are the coordinates of the button press event)
>>
>> With thread signals:
>> column[0](0) = 0 -> 0
>> cell[0] = min->135, natural->135
>> column[1](66) = 0 -> 66
>> cell[0] = min->20, natural->20
>> cell[1] = min->16, natural->16
>> cell[2] = min->35, natural->35
>> column[2](36) = 66 -> 102
>> cell[0] = min->16, natural->16
>> x = 113.528488, y = 158.563782
>>
>> As you can see, the width of the first column is 0 when the signals are
>> being emitted. As expected, if I were to click very close to the left
>> border of the widget, the edit dialog does not get triggered as the x
>> coordinate falls within column 1:
>>
>> column[0](0) = 0 -> 0
>> cell[0] = min->135, natural->135
>> column[1](66) = 0 -> 66
>> cell[0] = min->20, natural->20
>> cell[1] = min->16, natural->16
>> cell[2] = min->35, natural->35
>> column[2](36) = 66 -> 102
>> cell[0] = min->16, natural->16
>> x = 21.247330, y = 181.310333
>>
>> I could use the cell renderer width if the column width is 0 but that
>> seems unreliable since the cell renderer width is not the same as the
>> column and it's also not static.
>>
>> On Tue, Dec 18, 2018 at 8:23 AM Mitko Haralanov 
>> wrote:
>>
>>> I am not posting the complete function because there is a lot of
>>> irrelevant code. I am also not interested in the specific cell renderer but
>>> rather the row on which the click occurred.
>>>
>>> tatic gboolean on_button_press_event(GtkWidget *widget,
>>>   GdkEvent *event,
>>>   gpointer data)
>>> {
>>> GtkTreeView *treeview = GTK_TREE_VIEW(widget);
>>> GdkEventButton *button = (GdkEventButton *)event;
>>> GtkTreeModel *model;
>>> GtkTreePath *path;
>>> GtkTreeIter iter;
>>> GtkTreeViewColumn *column;
>>> GtkScopeProjectEditDialog *dialog;
>>> GtkScopeProjectEditData *pdata, fill;
>>> GtkScopeProject *project;
>>> guint response, index;
>>> gboolean ret = FALSE;
>>>
>>> if (button->type != GDK_BUTTON_PRESS ||
>>> !gtk_tree_view_get_path_at_pos(treeview, button->x, button->y,
>>>, , NULL, NULL))
>>> return FALSE;
>>>
>>> index = GPOINTER_TO_UINT(g_object_get_data(G_OBJECT(column), "index"));
>>> if (index != TREEVIEW_COLUMN_EDIT)
>>> goto done;
>>> model = gtk_tree_view_get_model(treeview);
>>> if (!gtk_tree_model_get_iter(model, , path))
>>> goto done;
>>> gtk_tree_model_get(model, , PROJECT_COLUMN_OBJ, , -1);
>>> ...
>>>
>>> The issue is that the column which is returned by
>>> gtk_tree_view_get_path_at_pos() is different depending on whether thread
>>> signals are being emitted vs not. I have verified that the button press
>>> coordinates are the same (button->x and button->y have the same values in
>>> both cases).
>>>
>>>
>>> On Tue, Dec 18, 2018 at 5:24 AM Luca Bacci 
>>> wrote:
>>>
>>>> Hi Mitko! Can you post here the code for the button-press event handler?
>>>> It should more or less 

Re: Emitting signals from threads

[Luca Bacci via gtk-list]

Is it Gtk2 or Gtk3, which version exactly?


Il giorno mar 18 dic 2018 alle ore 18:47 Mitko Haralanov via gtk-list <
gtk-list@gnome.org> ha scritto:

> I mistakenly replied only to Luca!! Forwarding to the list.
>
> (Sorry, Luca, my bad)
> - Mitko
>
> -- Forwarded message -
> From: Mitko Haralanov 
> Date: Tue, Dec 18, 2018 at 9:37 AM
> Subject: Re: Emitting signals from threads
> To: Luca Bacci 
>
>
> I found something that is different between the two cases - button click
> with signals and without.
>
> Using the code from the link that Luca posted, I decided to print the size
> of each column when a button press is received. As it turns out, the width
> of the columns is different in the two cases:
>
> Without thread signals:
> column[0](193) = 0 -> 193
> cell[0] = min->109, natural->109
> column[1](66) = 193 -> 259
> cell[0] = min->20, natural->20
> cell[1] = min->16, natural->16
> cell[2] = min->35, natural->35
> column[2](36) = 259 -> 295
> cell[0] = min->16, natural->16
> x = 105.872116, y = 259.547516
>
> (x and y are the coordinates of the button press event)
>
> With thread signals:
> column[0](0) = 0 -> 0
> cell[0] = min->135, natural->135
> column[1](66) = 0 -> 66
> cell[0] = min->20, natural->20
> cell[1] = min->16, natural->16
> cell[2] = min->35, natural->35
> column[2](36) = 66 -> 102
> cell[0] = min->16, natural->16
> x = 113.528488, y = 158.563782
>
> As you can see, the width of the first column is 0 when the signals are
> being emitted. As expected, if I were to click very close to the left
> border of the widget, the edit dialog does not get triggered as the x
> coordinate falls within column 1:
>
> column[0](0) = 0 -> 0
> cell[0] = min->135, natural->135
> column[1](66) = 0 -> 66
> cell[0] = min->20, natural->20
> cell[1] = min->16, natural->16
> cell[2] = min->35, natural->35
> column[2](36) = 66 -> 102
> cell[0] = min->16, natural->16
> x = 21.247330, y = 181.310333
>
> I could use the cell renderer width if the column width is 0 but that
> seems unreliable since the cell renderer width is not the same as the
> column and it's also not static.
>
> On Tue, Dec 18, 2018 at 8:23 AM Mitko Haralanov 
> wrote:
>
>> I am not posting the complete function because there is a lot of
>> irrelevant code. I am also not interested in the specific cell renderer but
>> rather the row on which the click occurred.
>>
>> tatic gboolean on_button_press_event(GtkWidget *widget,
>>   GdkEvent *event,
>>   gpointer data)
>> {
>> GtkTreeView *treeview = GTK_TREE_VIEW(widget);
>> GdkEventButton *button = (GdkEventButton *)event;
>> GtkTreeModel *model;
>> GtkTreePath *path;
>> GtkTreeIter iter;
>> GtkTreeViewColumn *column;
>> GtkScopeProjectEditDialog *dialog;
>> GtkScopeProjectEditData *pdata, fill;
>> GtkScopeProject *project;
>> guint response, index;
>> gboolean ret = FALSE;
>>
>> if (button->type != GDK_BUTTON_PRESS ||
>> !gtk_tree_view_get_path_at_pos(treeview, button->x, button->y,
>>, , NULL, NULL))
>> return FALSE;
>>
>> index = GPOINTER_TO_UINT(g_object_get_data(G_OBJECT(column), "index"));
>> if (index != TREEVIEW_COLUMN_EDIT)
>> goto done;
>> model = gtk_tree_view_get_model(treeview);
>> if (!gtk_tree_model_get_iter(model, , path))
>> goto done;
>> gtk_tree_model_get(model, , PROJECT_COLUMN_OBJ, , -1);
>> ...
>>
>> The issue is that the column which is returned by
>> gtk_tree_view_get_path_at_pos() is different depending on whether thread
>> signals are being emitted vs not. I have verified that the button press
>> coordinates are the same (button->x and button->y have the same values in
>> both cases).
>>
>>
>> On Tue, Dec 18, 2018 at 5:24 AM Luca Bacci 
>> wrote:
>>
>>> Hi Mitko! Can you post here the code for the button-press event handler?
>>> It should more or less follow the code here:
>>> http://scentric.net/tutorial/sec-misc-get-renderer-from-click.html
>>>
>>> Luca
>>>
>>> Il giorno lun 17 dic 2018 alle ore 20:28 Mitko Haralanov via gtk-list <
>>> gtk-list@gnome.org> ha scritto:
>>>
>>>> Hi,
>>>>
>>>> In my application, I want to be able to update a treeview from a
>>>> separate thread. Each treeview row was a column that is a progress bar. The
>>>> progress to be displayed is generated by a separat

Re: Emitting signals from threads

[Luca Bacci via gtk-list]

Hi Mitko! Can you post here the code for the button-press event handler?
It should more or less follow the code here:
http://scentric.net/tutorial/sec-misc-get-renderer-from-click.html

Luca

Il giorno lun 17 dic 2018 alle ore 20:28 Mitko Haralanov via gtk-list <
gtk-list@gnome.org> ha scritto:

> Hi,
>
> In my application, I want to be able to update a treeview from a separate
> thread. Each treeview row was a column that is a progress bar. The progress
> to be displayed is generated by a separate thread as to not block the UI.
>
> Since GTK is not thread-safe, the way the application is written is that
> the thread, when it needs to emit a signal, will prepare the signal data
> and then call g_main_context_invoke_full(NULL, cb, data, ...) in order to
> be able to call g_singal_emit() in the global default context thread. The
> signal handler updates the tree model, which in turn updates the tree view.
>
> For the most part this works with one big, ugly exception - the same
> treeview has a column, which is supposed to open the item's Edit dialog
> when clicked. So, naturally, I have a button-press handler connected to the
> treeview, which launches the Edit dialog when the button press occurs in
> the correct column.
>
> However, when an update is running and the thread is continuously emitting
> signals, clicking on *any* column of *any* of the other items opens the
> Edit dialog. The treeview behaves as if the items in it have only one
> column.
>
> Every example or document that I have seen in relation to signals from
> threads says to emit the signal from a g_idle_add() handler. However,
> g_main_context_invoke_full(NULL, ...) should be the same as calling
> g_idle_add().
>
> Can someone shed some light into what might be happening?
>
> Thank you.
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list