Benjamin, Thanks for the reply. <div class="gmail_quote">On Tue, Aug 21, 2012 at 12:35 PM, Benjamin Berg <<a href="mailto:benzea@sugarlabs.org" target="_blank">benzea@sugarlabs.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On Tue, 2012-08-21 at 12:18 +0530, Ajay Garg wrote: > I am wanting to solve an issue, which in the present case seems > possible ONLY by using two threads. </div>Adding threads into the mix would not help you with your issue (threading support in GTK+ is currently being deprecated for good reasons, so then you can only do GTK+ calls from the main thread). In the normal case, when the GUI is updated a queue_draw() is done. The corresponding expose events are only fired when the main loop is executed, ie. when your function returns. I think what you are searching for right now is the the process_updates function of GdkWindow. This does exactly what you are requesting. </blockquote><div> A straightforward query here (sorry for my limited knowledge) :: Does calling "process_updates" causes the GUI updates to take place, before the user returns from the function? That is, will the following scenario necessarily happen :: logic statement 1 update GUI process_updates ===> causes the GUI update logic statement 2 ===> necessarily after GUI update I doubt that the above is a guarantee, as you have already mentioned that the actual GUI processing will take place whenever X server sees it fit. Anyhow, just wish to confirm :) Thanks and Regards, Ajay </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Please note that you don't have much control here, you don't know how fast the update will happen, or even if it is ever visible to the user. The X server will process the drawing commands when it sees fit. <div class="im"> > My intention is to somehow have GUI updates in a synchronous manner, > and not rely upon "gobject.idle_add", which would have to have > dividing a long workflow into many sub-parts, and chaining these > sub-parts through "gobject.idle_add". > This is EXTREMELY painful, especially when one needs to do it on an > already existing codebase. </div>As an alternative you could do something like: def idle_add_function(pos): if pos[0] == 1: # logic 1 elif pos[0] == 2: # logic 2 else: return False queue_update() pos[0] += 1 return True Where pos = [0] to begin with (the usage of the list is just so that it is global in a way, any object will do, it just needs to be something permuteable). Benjamin </blockquote></div>