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

No releases for March

2017-03-30 Thread Brian Manning
Hi all, There was no new code in the Gtk-Perl repos, so there's no releases for March. The next release announcement for April will be sent out shortly. Thanks, Brian ___ gtk-perl-list mailing list gtk-perl-list@gnome.org

GTK+ with Broadway.

2017-03-30 Thread Igor D
Hi, I'm trying to change the cursor when it is over certain widget and do not succeed to do that when I'm working with GTK+ via Broadway. Without Broadway it works perfectly. Somebody knows about limitation for this case ? Thanks, Igor ___ gtk-list

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: > >

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

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. ___

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

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

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

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

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