On Fri, 2007-04-20 at 06:51 +0000, Fabian Braennstroem wrote:
> Hi John,
>
> John Dennis schrieb am 04/17/2007 07:53 PM:
> > On Tue, 2007-04-17 at 21:15 +0000, Fabian Braennstroem wrote:
> >> Thanks for your advice! I tried to adjust your lines a bit, but I
> >> was not successful:
> >>
> >> def progress_pulse(self):
> >> if self.load_in_progress:
> >> self.progress.pulse()
> >> return True # call again
> >> else:
> >> return False # do not call again
> >>
> >>
> >>
> >> def on_load_data(self , state ):
> >> if state == 'start':
> >> self.load_in_progress = True
> >> self.progress.pulse()
> >> gobject.timeout_add(1, self.progress_pulse)
> >> if state == 'stop':
> >> self.load_in_progress = False
> >>
> >> def callback(self, widget, data=None):
> >> i=0
> >> n=100
> >>
> >> self.on_load_data('start')
> >>
> >> shutil.copytree(file1,"/home/fab/test_copy2")
> >>
> >> self.on_load_data('stop')
> >>
> >>
> >> The progressbar starts to run, if the directory already exists and
> >> 'shutil' stops with an error message; if the copying works than
> >> there is no progressbar movement... strange. Do you know, what I am
> >> doing wrong?
> >
> > It's the same thing I told you originally, you can't both perform a
> > synchronous copy and update the GUI at the same time. You also have to
> > understand how the GTK event loop works.
> >
> > Timeout callbacks are processed in the event loop. Your copy routine is
> > processed in the event loop. They cannot proceed in parallel because the
> > event loop is sequential.
> >
> > In one iteration of the event loop your copy routine installs a timeout
> > callback with load_in_progress=True, does the copy, then sets
> > load_in_progress=False. Sometime later the event loop gets to your
> > timeout handler and calls it. But guess what the value of
> > load_in_progress is?
> >
> > I'm guessing the reason it works in an error condition is because
> > copytree raises an exception which you don't catch (its caught by the
> > event loop instead), thus you never set load_in_progress to False, then
> > when the event loop calls your timeout handler load_in_progress is True
> > and you pulse. BTW, 1 millisecond timeout is way too short.
> >
> > You can cause the event loop to run during the copy with something like
> > this:
> >
> > while gtk.events_pending():
> > gtk.main_iteration(False)
> >
> > But this has to be done inside the copy operation, or you have to
> > structure the copy to be performed in chunks (e.g. idle_add()). But you
> > can't do what you want to do if the copy operation is completely
> > synchronous in one call (as copytree is) and you only have one thread.
>
> Thanks for your help! I will try it ...
> The chunks copy sounds pretty slow to me, but probably every file
> manager is doing it, if it got any progressbar.
I have app that makes a lot of calls to long running "tasks". I use
threads to do it. I spawn a new thread for the action and have the main
thread wait on that action while processing the event loop. I use my
own WorkingDialog class and pass the given instance of that class to the
task in case it can/wants to give some particular status messages.
Additionally the WorkingDialog class supports the pulse and the
percentage settings so the task can update the percentage completion if
it knows it and if not the pulse part takes care of itself.
If want some detail on that I'll be glad to give you some pseudo code
outlining that mechanism.
>
> Greetings!
> Fabian
>
> _______________________________________________
> pygtk mailing list pygtk@daa.com.au
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
--
Steve McClure Racemi
email: [EMAIL PROTECTED] 380 Interstate North Pkwy, SE
voice: 404-892-5850 Suite 250
fax: 404-892-7215 Atlanta, GA 30339
http://www.racemi.com
_______________________________________________
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
