Hey Joe, The thing is, since your example is really trivial, I can really only comment on the trivial example itself. Normally one wouldn't want to process a whole bunch of long running/blocking tasks one after the next, in a single method, while adding and removing widgets from a layout. The layout is obviously having a drawing issue related to timing, from everything happening within that same stack.
I can offer a tweak for the example that shows how it could be corrected, by splitting up your tasks into pieces that allow the stack to return to the event loop again. http://pastebin.com/5s5mx6KE In a more real world example, you might abstract these tasks into objects emit their own progress (QThread already does this), and then be able to chain them up so one starts after the next. Or when one is done, a queue is checked and the next pending task runs. Are these tasks that can be run in a thread? If so, you can use a thread pool or QThreads and coordinate with their signals. Anyways, basically the issue is that the layout is unhappy having itself modified so much from a single stack. - Justin On Mon Nov 10 2014 at 7:03:33 PM Joe Weidenbach <[email protected]> wrote: > Hey All, > > I'm having an issue with a tool I'm working on regarding slot-based > widget deletion. > > I'm trying to create a UI where my object which handles data processing > reports it's progress on various (possibly nested) tasks back to the > UI. It's a mesh processor, so it can be pretty intensive. I'm actually > using these progress bars to try and identify where a memory leak is > right now, so I can track it down, but it would be dead useful to have > for general purposes as well. > > I've made up a simpler script to demo the situation, here: > http://pythonfiddle.com/progress-bar-test > > The relevant code is in the final class, in the three slots that connect > to PBTester (lines 84-113). I don't think I need to call self.update() > on every loop, but it does slow things down for the visual of the > progress bars. > > The issue I'm having is that when the processCompleted Signal fires, it > doesn't seem to actually delete the given progress bar. It's removed > from the layout, but the visual stays in place and gets overlaid by the > new progress bar. My guess from the research I've done is that this has > something to do with deleteLater not being called while in the process, > but I don't understand the event loop well enough yet to make much sense > of it. The closest page I've been able to find recommended calling > emit() with Qt.QueuedConnection, and I did try that, but I don't think I > was doing it right, as it didn't seem to do anything. I'm not using > threads either, so I don't think it's a sync issue, but I'm not sure if > Qt is using them under the hood or not. > > Hopefully that makes sense. Any thoughts from the pros? > > Thanks, > > Joe > > --- > This email is free from viruses and malware because avast! Antivirus > protection is active. > http://www.avast.com > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/python_inside_maya/5460552B.3000500%40gmail.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3AZ8gG9zLc%3Dsa7aH1ME1P%3D9yp9nSnOR7A0ENKmjVDoiQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
