Re: Input event reduction

2017-03-30 Thread Stefan Salewski
On Wed, 2017-03-29 at 23:26 +0200, Nicola Fontana wrote: >  > > idle functions do *not* run in the background so if you don't > release the CPU you will experience what you described. > > AFAIK all the GMainLoop code is single-threaded hence, as a > consequence, you will block the UI whenever the

Re: Input event reduction

2017-03-30 Thread Stefan Salewski
On Thu, 2017-03-30 at 09:38 +0200, Stefan Salewski wrote: > Currently I wonder if the call of gtk3.mainIteration() inside the > idle > function is possible and if it would help updating the display. In my > first draft of the Nim toy chess I used something like this > > while gtk3.eventsPending():

Re: Input event reduction

2017-03-30 Thread Nicola Fontana
Il Thu, 30 Mar 2017 09:38:41 +0200 Stefan Salewski scrisse: > On Wed, 2017-03-29 at 23:26 +0200, Nicola Fontana wrote: > >  > > > > idle functions do *not* run in the background so if you don't > > release the CPU you will experience what you described. > > > > AFAIK all the GMainLoop code is s

Re: Input event reduction

2017-03-30 Thread Emmanuele Bassi
On 30 March 2017 at 10:10, Nicola Fontana wrote: > When you are ready from (1) you can spawn the idle callback with > g_source_attach()... no needs for gdk_threads_add_idle(). In the > following StackOverflow answer I provided an example in C: A small correction: use g_main_context_invoke() inst

Re: Input event reduction

2017-03-30 Thread Stefan Salewski
On Thu, 2017-03-30 at 11:10 +0200, Nicola Fontana wrote: >  > > As said you can leverage the main loop and unroll yours, e.g.: > > gboolean my_idle_callback() > { > gint n; > for (n = 0; n < 100; ++n) { > ... > } > return FALSE; > } > > should become: > > gboolean my_unr

Re: Input event reduction

2017-03-30 Thread Stefan Salewski
On Thu, 2017-03-30 at 10:21 +0100, Emmanuele Bassi wrote: > g_idle_add() or, better yet, g_main_context_invoke(). Thanks. While I can remember have read your explanations somewhere already, I really missed that g_main_context_invoke() function. ___ gtk-a

Re: Input event reduction

2017-03-30 Thread Gabriele Greco
> > > Thanks. While I can remember have read your explanations somewhere > already, I really missed that g_main_context_invoke() function. There is some difference/advantage on calling: g_main_context_invoke(NULL, func, data)? instead of g_idle_add(func, data); As far as I can see from the fu

Re: Input event reduction

2017-03-30 Thread Emmanuele Bassi
On 30 March 2017 at 11:21, Gabriele Greco wrote: >> >> Thanks. While I can remember have read your explanations somewhere >> already, I really missed that g_main_context_invoke() function. > > > There is some difference/advantage on calling: > > g_main_context_invoke(NULL, func, data)? > > instead

GFileMonitor - g_signal_handler_block "changed" signal doesn't block handler?

2017-03-30 Thread David C. Rankin
All I have implemented a GFileMonitor/g_file_monitor_file watch for respond to changes to the current file by an external process within an editor[1], but now issuing g_signal_handler_block to prevent the "changed" signal from being handled on normal saves, does not prevent the callback from fir

Re: GFileMonitor - g_signal_handler_block "changed" signal doesn't block handler?

2017-03-30 Thread David C. Rankin
On 03/30/2017 03:39 PM, David C. Rankin wrote: > Let me know what the experts think. There is something funny about the way > block/unblock works with GFileMonitor that I'm missing. For normal signals in > the app, I have no problems with block/unblock. I've posted this complete question to: http