On Wed, 2003-03-12 at 09:50, Jon Nelson wrote: > On Wed, 12 Mar 2003, Christian Reis wrote: > > > On Wed, Mar 12, 2003 at 08:35:36AM -0600, Jon Nelson wrote: > > > > > > This seems really silly. > > > > > > If you're gonna f up events_pending in this way, then that means you are > > > > > > not going to ever pump the gtk event queue. If you really don't need to > > > > > > call mainiteration, then why don't you just remove the whole > > > > > > while gtk.events_pending(): gtk.mainiteration nonsense. > > > > > > Yes. eventually the function do_real_work_with_data_read_from_file (I > > > am getting tired of typing that) *does* call: > > > > Tip: use vim's ctrl-N feature, or emacs' related completion feature (I > > just did do_<ctrl-N> and it became do_real_work_with_data_read_from_file). > > > > > while gtk.events_pending(): > > > gtk.mainiteration() > > > > > > It's necessary for various reasons, not the least of which is a simple > > > progress bar. > > > > Can't this while become: > > > > while self.check_events and gtk.events_pending(): > > gtk.mainiteration() > > > > And we use the check_events flag like I described before? > > yes it can, but it (essentially) does the exact same thing. > I'll verify your soln. works, but it's essentially the same. > What I'd *really* like is to find out if there is a way to accomplish > what I'm trying to do here. > > The user-perceivable problem is that (assume > do_real_work_with_data_read_from_file takes perhaps a minute), the > application is "frozen" because mainiteration can't be called to update > progress bars, show messages, update cursors, etc... > > Very annoying. > > Is there a better /high-level/ solution to this? > Both of our solutions solve the discrete problem (mainiteration gets > called in situations where it causes things to blow up), but the *real* > bug is that it's not possible to tell gtk to *not* call your > (idle/IO/timeout) function on-demand. Also, why doesn't > gtk.input_remove(proper_args_here) work when called from the IO > callback?
I don't know about better but I have done something "similar" to deal with the fact that I need to do GTK stuff inside other threads in my app. Basically, I event (not-GTK related) that cause code to be executed in another thread. I added a mechanism to queue up the events and code in the main thread will process the events as the result of a GTK timeout. Maybe you could something similar? I'm not sure that you would want to since you found something that works. > > -- > "Never try to write to ROM - it wastes your time and annoys the ROM." > > Jon Nelson <[EMAIL PROTECTED]> > C and Python Code Gardener > _______________________________________________ > pygtk mailing list [EMAIL PROTECTED] > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ -- Steve McClure <[EMAIL PROTECTED]> Racemi, Inc.
signature.asc
Description: This is a digitally signed message part
