<br><br><div class="gmail_quote">On Tue, Aug 21, 2012 at 1:17 PM, Ajay Garg <span dir="ltr"><<a href="mailto:ajay@activitycentral.com" target="_blank">ajay@activitycentral.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br><br><div class="gmail_quote"><div class="im">On Tue, Aug 21, 2012 at 1:00 PM, Benjamin Berg <span dir="ltr"><<a href="mailto:benzea@sugarlabs.org" target="_blank">benzea@sugarlabs.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>On Tue, 2012-08-21 at 12:43 +0530, Ajay Garg wrote:<br>
> Does calling "process_updates" causes the GUI updates to take place,<br>
> before the user returns from the function?<br>
<br>
</div>Yes, the updates are done immediately and the drawing commands are<br>
pushed out to the X server. And I do expect that this is *exactly* what<br>
you requested.<br>
You don't know exactly when the GUI update will be visible on the<br>
screen. But that is normal and has nothing to do with process_updates.<br>
<br>
An example where this mechanism was used in GTK+ is scrollbars. When you<br>
are dragging them, they should be redrawn right away so that they move<br>
correctly.<br>
<br>
Benjamin<br></blockquote></div><div><br><br>Awesome !!!! <br>I'll give this a try right away, and get back to you with the results !!<br></div></div></blockquote><div><br>Damn. Doesn't work :-(<br><br><br> <br></div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div><br>Thanks a ton !!!<br><br><br>Thanks and Regards,<br>Ajay<br> <br></div>
<div><div class="h5"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div><br>
> That is, will the following scenario necessarily happen ::<br>
><br>
> logic statement 1<br>
> update GUI<br>
> process_updates ===> causes the GUI update<br>
> logic statement 2 ===> necessarily after GUI<br>
> update<br>
><br>
><br>
><br>
> I doubt that the above is a guarantee, as you have already mentioned<br>
> that the actual GUI processing will take place whenever X server sees<br>
> it fit.<br>
> Anyhow, just wish to confirm :)<br>
><br>
><br>
> Thanks and Regards,<br>
> Ajay<br>
><br>
> Please<br>
> note that you don't have much control here, you don't know how<br>
> fast the<br>
> update will happen, or even if it is ever visible to the user.<br>
> The X<br>
> server will process the drawing commands when it sees fit.<br>
><br>
> > My intention is to somehow have GUI updates in a synchronous<br>
> manner,<br>
> > and not rely upon "gobject.idle_add", which would have to<br>
> have<br>
> > dividing a long workflow into many sub-parts, and chaining<br>
> these<br>
> > sub-parts through "gobject.idle_add".<br>
> > This is EXTREMELY painful, especially when one needs to do<br>
> it on an<br>
> > already existing codebase.<br>
><br>
><br>
> As an alternative you could do something like:<br>
><br>
> def idle_add_function(pos):<br>
> if pos[0] == 1:<br>
> # logic 1<br>
> elif pos[0] == 2:<br>
> # logic 2<br>
> else:<br>
> return False<br>
><br>
> queue_update()<br>
><br>
> pos[0] += 1<br>
> return True<br>
><br>
> Where pos = [0] to begin with (the usage of the list is just<br>
> so that it<br>
> is global in a way, any object will do, it just needs to be<br>
> something<br>
> permuteable).<br>
><br>
> Benjamin<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Sugar-devel mailing list<br>
> <a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
<br>
<br>
</blockquote></div></div></div><br>
</blockquote></div><br>