Re: GUI freezes waiting for callback function to return

[Michael Torrie]

On 12/15/2012 11:08 AM, Mateusz Marzantowicz wrote:
> Very valuable articles and blog posts.
> 
> Now I know that threading in GUI apps (using GTK+) is much harder then I
> originally thought it is. Although my use case is very simple I must
> employ complicated threading machinery. I'm playing with
> consumer/producer pattern and separate worker thread and I hope it
> doesn't blow up in my face. I've also found application that works
> similarly to my own - baobab (disk usage analyzer).

You should be fine so long as nothing in your thread calls the GUI calls
directly.  Using a queue and the pattern you described is pretty
standard procedure for multi-threaded, or multi-process programming in
general.  And as the other poster said, use asynchronous I/O whenever
possible so you don't always need threads.

You say you have enjoyed complicated threading machinery before.  MFC
certainly never supported GUI calls from threads.  I remember having to
do queues and all kinds of other things to get get my threads to play
nice on Win32.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GUI freezes waiting for callback function to return

[Mateusz Marzantowicz]

On 14.12.2012 11:03, Federico Zamperini wrote:
> I suggest you to read these interesting pages:
>
> http://blog.borovsak.si/2009/06/multi-threaded-gtk-applications.html
> http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness
>
>

Very valuable articles and blog posts.

Now I know that threading in GUI apps (using GTK+) is much harder then I
originally thought it is. Although my use case is very simple I must
employ complicated threading machinery. I'm playing with
consumer/producer pattern and separate worker thread and I hope it
doesn't blow up in my face. I've also found application that works
similarly to my own - baobab (disk usage analyzer).


Thanks for all shared ideas and resources,
Mateusz Marzantowicz
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GUI freezes waiting for callback function to return

[Federico Zamperini]

I suggest you to read these interesting pages:

http://blog.borovsak.si/2009/06/multi-threaded-gtk-applications.html
http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness

Warning: gdk_threads_enter has been deprecated since version 3.6 and 
should not be used in newly-written code. All GDK and GTK+ calls should 
be made from the main thread.

Nevertheless I find those pages useful.

Since I'm lazy I've used this approach 
(gdk_threads_enter/gdk_threads_leave) to change the gui layout from a 
secondary thread instead of using proper thread synchronization, I mean 
like using some kind of inter-thread communication, for example 
(asynchronous) queues 
(http://developer.gnome.org/glib/2.31/glib-Asynchronous-Queues.html#glib-Asynchronous-Queues.description) 
or (gtk)signal emitting to make the main thread execute a callback -- 
the same way when a gui button is pressed.

Unfortunately I use C, not Python, so these are just pointers.

Il 14/12/2012 04:04, Andrew Potter ha scritto:

On Thu, Dec 13, 2012 at 5:57 AM, Mateusz Marzantowicz <
mmarzantow...@osdf.com.pl> wrote:


My application is supposed to do some extensive file operations which
  may take a while depending on number of files.



If you don't want to offload your work to another thread, Glib has a whole
host of asynchronous file handling operations. I guess the python
documentation is here:
http://www.pygtk.org/docs/pygobject/gio-class-referenandce.html

I prefer to use threading of some kind and I'm little bit disappointed that

GTK+ doesn't offer that out of the box for menus, actions and callbacks.



AFAIK Windows and Android requires GUI functions to be called on the main
loop thread, so it is not unusual. Also, since GTK+ is supposed to work on
Windows it inherits that rule. You should be able to create a thread or
call whatever threading library you want from your callback, but if you
want to deliver results back to the GUI it has to be done back on the main
thread.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


-
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.2805 / Database dei virus: 2634/5954 -  Data di rilascio: 
12/12/2012



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

Re: GUI freezes waiting for callback function to return

[Osmo Antero]

Hello,
Audio-recorder has couple of examples of g_timeout_add*() functions.
Ref: https://launchpad.net/audio-recorder

1) Look for:
$ grep -Ri g_timeout src/*.c

2) src/rec-manager.c uses also a GAsyncQueue. See:
   static GAsyncQueue *g_cmd_queue = NULL;
   g_cmd_queue = g_async_queue_new();

3) src/dbus-skype.c has an example of g_thread_try_new().
g_thread_try_new("Skype service thread", func, user_data, &error);

Threads cannot call GTK directly since gdk_threads_enter() / gdk_threads_leave
() was removed i GTK3.
Instead it (and all other modules) feed the message queue, and all is very
well.

My 5 cents.
Feliz Natal!


On Thu, Dec 13, 2012 at 2:59 PM, Osmo Antero  wrote:

> Hello,
> Audio-recorder has couple of examples of g_timeout_add*() functions.
> Ref: https://launchpad.net/audio-recorder
>
> 1) Look for:
> $ grep -Ri g_timeout src/*.c
>
> 2) src/rec-manager.c uses also a GAsyncQueue.  See:
>static GAsyncQueue *g_cmd_queue = NULL;
>g_cmd_queue = g_async_queue_new();
>
> 3) src/dbus-skype.c has an example of g_thread_try_new().
> g_thread_try_new("Skype service thread", func, user_data, &error);
>
> Threads cannot call GTK directly since gdk_threads_enter() / gdk_threads_leave
> () was removed i GTK3.
> Instead it feeds the message queue, all is very well.
>
> My 5 cents.
> Feliz Natal!
>
>


-- 
// moma
   http://www.futuredesktop.org
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GUI freezes waiting for callback function to return

[Mateusz Marzantowicz]

On 13.12.2012 14:27, Perdie Perduta wrote:
> In C++ I create an object in the call back and that in it's
> constructor registers itself to do lengthy processing during gtk idle
> events using:
>
> gint iTag = gtk_idle_add( GtkFunction fIdleActivity, gpointer   pMyObject );
>
> On completion, in the destructor it unregisters itself with:
>
> void gtk_idle_remove( gint iTag );
>
> Sorry, but I also can't help you with Pythonese... I only started
> learning Gtk recently after finally giving up on the Windows MFC,
> Forms applications and other visual studio abominations. :^/
>
> On Fri, Dec 14, 2012 at 1:08 AM,   wrote:
>> On 13 December 2012 11:21, Mateusz Marzantowicz
>>  wrote:
>>> I'm writing very simple application in Python using pygobject. I'm using
>>>
>>> What I've observed is that GUI (menu to be specific) freezes till my
>>> callback function finishes. It's completely unacceptable for GUI
>> This is because callbacks are run by the main GUI thread, so until
>> your callback returns, the GUI can't do anything. To give a nice
>> experience for the user your callbacks must be very short.
>>
>> If you have to do some lengthy processing, you need to process GUI
>> events at regular intervals. In PyGtk this used to be:
>>
>> def my_long_callback():
>> for i in long_time():
>> small_chunk_of_work()
>> while gtk.events_pending():
>> gtk.main_iteration()
>>
>> I don't know what the pygobject equivalent is, something similar.
>>
>> In C you can use threads for background tasks, but I think that's
>> difficult in Python.
>>
>> John
>> ___
>> gtk-app-devel-list mailing list
>> gtk-app-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
>

Thanks for your reply.

I think I can figure it out, how to translate from C/C++ to Python but
I'm stuck with GTK+ application design.

Now, all I can think of is taking advantage of open source and try to
find out how others managed to deal with this GUI freeze.

My application is supposed to do some extensive file operations which
may take a while depending on number of files. I can chunk the work as
John suggested but I don't like this approach. I prefer to use threading
of some kind and I'm little bit disappointed that GTK+ doesn't offer
that out of the box for menus, actions and callbacks.


Mateusz Marzantowicz
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GUI freezes waiting for callback function to return

[Perdie Perduta]

In C++ I create an object in the call back and that in it's
constructor registers itself to do lengthy processing during gtk idle
events using:

gint iTag = gtk_idle_add( GtkFunction fIdleActivity, gpointer   pMyObject );

On completion, in the destructor it unregisters itself with:

void gtk_idle_remove( gint iTag );

Sorry, but I also can't help you with Pythonese... I only started
learning Gtk recently after finally giving up on the Windows MFC,
Forms applications and other visual studio abominations. :^/

On Fri, Dec 14, 2012 at 1:08 AM,   wrote:
> On 13 December 2012 11:21, Mateusz Marzantowicz
>  wrote:
>> I'm writing very simple application in Python using pygobject. I'm using
>>
>> What I've observed is that GUI (menu to be specific) freezes till my
>> callback function finishes. It's completely unacceptable for GUI
>
> This is because callbacks are run by the main GUI thread, so until
> your callback returns, the GUI can't do anything. To give a nice
> experience for the user your callbacks must be very short.
>
> If you have to do some lengthy processing, you need to process GUI
> events at regular intervals. In PyGtk this used to be:
>
> def my_long_callback():
> for i in long_time():
> small_chunk_of_work()
> while gtk.events_pending():
> gtk.main_iteration()
>
> I don't know what the pygobject equivalent is, something similar.
>
> In C you can use threads for background tasks, but I think that's
> difficult in Python.
>
> John
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



-- 
~~~ PEr aRDUa ad asTrA ~~~
(Through adversity to the stars)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GUI freezes waiting for callback function to return

[jcupitt]

On 13 December 2012 11:21, Mateusz Marzantowicz
 wrote:
> I'm writing very simple application in Python using pygobject. I'm using
>
> What I've observed is that GUI (menu to be specific) freezes till my
> callback function finishes. It's completely unacceptable for GUI

This is because callbacks are run by the main GUI thread, so until
your callback returns, the GUI can't do anything. To give a nice
experience for the user your callbacks must be very short.

If you have to do some lengthy processing, you need to process GUI
events at regular intervals. In PyGtk this used to be:

def my_long_callback():
for i in long_time():
small_chunk_of_work()
while gtk.events_pending():
gtk.main_iteration()

I don't know what the pygobject equivalent is, something similar.

In C you can use threads for background tasks, but I think that's
difficult in Python.

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

GUI freezes waiting for callback function to return

[Mateusz Marzantowicz]

Hello,

I'm writing very simple application in Python using pygobject. I'm using
Gtk.Application, Gtk.ApplicationWindow and XML menu definition which is
parsed by Gtk.Builder(). I'm also using Gio.SimpleAction to call method
when user clicks on menu item.

What I've observed is that GUI (menu to be specific) freezes till my
callback function finishes. It's completely unacceptable for GUI
application but I don't know how to make/code it right.

Here is a piece of code that I use for menu actions:

my_action = Gio.SimpleAction.new('my-action', None)
my_action.connect('activate', self.my_callback_function)
self.add_action(my_action)

How can I rewrite this to work in non-blocking way?


Mateusz Marzantowicz
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list