[PySide] a couple of QProgressDialog questions

Frank Rueter | OHUfx frank at ohufx.com
Sat Sep 7 08:41:54 CEST 2013

Cool, thanks.
As for the import * statements, I totally agree, I never do this except 
for those two packages. Still, probably better to not be lazy and import 
the proper namespace.


On 7/09/13 6:37 PM, Sebastian Elsner wrote:
> Looks pretty good! I totally forgot that QProcess is asynchronous so you
> can save the thread
> The only thing I dont like is :
> from PySide.QtCore import *
> from PySide.QtGui import *
> which is not recommended, because it will pollute your namespace with
> stuff you might not know about - overwriting functions with unexpected
> behavior.
> For the "100% not emitted" problem: just connect the QProcess.finished
> signal to your __read method. The doc says the buffers are still intact
> after this signal is emitted and you are able to read from stdout and
> get the 100% done line.
> Am 07.09.2013 07:44, schrieb Frank Rueter | OHUfx:
>> Here is what I got:
>> http://pastebin.com/kCUkSsUX
>> I didn't even need QThread at all since QProcess seems to be taking care
>> of everything as expected.
>> It's working nicely, though I had a few times where the last signal of
>> 100% wasn't emitted for some reason.
>> Does this look about right?
>> Cheers and thanks again for the help!
>> frank
>> On 3/09/13 8:01 PM, Sebastian Elsner wrote:
>>> On 09/03/2013 08:31 AM, Frank Rueter | OHUfx wrote:
>>>> Hi everybody,
>>>> after almost a year of having to neglect PySide I'm finally making some
>>>> time for it again, only to feel like I almost forgot everything I
>>>> learned :-D
>>>> I'm trying to do something fairly common and wanted to sanity check my
>>>> approach, so here is my sandbox script to figure out how to use
>>>> QProgressDialog:
>>>> http://pastebin.com/4kVhPiUx
>>>> It all works as expected except for the fact that when I hit cancel, the
>>>> progress stops (as expected), and the second time I hit the cancel
>>>> button the dialog closes. Seems wrong, and I'm sure I should be doing it
>>>> better, so that the progress stops and the dialog closes at the same
>>>> time. This behaviour seems to be the same even if setAutoClose() is set
>>>> to True.
>>> auto close only works if the current progress value is equal with the
>>> maximum value.
>>>> Should manually close the window when wasCanceled() is true, or set the
>>>> progress' value to it's maximum to let auroClose take over? Or is there
>>>> a better way?
>>> I normally do dlg.setValue(dlg.maximum()) and let autoclose do the rest,
>>> because afaik it also takes care of resetting stuff
>>>> My second question is:
>>>> What is the best approach to connect a QProgressDialog to another thread
>>>> that is running a command line application?
>>>> I'm guessing I should write a wrapper around the external application
>>>> (using QEvent or QProcess?), grabbing it's stdout, parsing it to get the
>>>> actual progress value, then connecting that to the QProgressDialog widget.
>>>> Is that the way to do it?
>>> Thats basically it. Your example suggests, that you want to put the
>>> computation code in the QProgressDialog subclass - don't. This is how
>>> the pieces should work together:
>>> Create a subclass of QObject. This is your object, that launches the
>>> QProgress and runs in its own thread watching and parsing the output of
>>> the QProgress. This class communicates ONLY via signals and slots with
>>> the main thread (normal method calls to the QProgress/within the thread
>>> are OK). This means you need a signal, which signals what the current
>>> progress is. Do not follow the old QThread documentation it is WRONG :)
>>> Read up on this topic here:
>>> http://blog.qt.digia.com/blog/2010/06/17/youre-doing-it-wrong/ and get a
>>> recent 4.8.4 documentation. Move this QObject to a QThread instance and
>>> connect the usual signals according to the docs. Create a
>>> QProgressDialog, connecting the canceled signal to a slot in your
>>> QObject to signal to stop the computation. Connect the progress signal
>>> from the QObject to the setValue of your progress dialog. For this to
>>> work you do only need to subclass QObject.
>>>> Ultimately I would like a simple Dialog, that has both a progress bar
>>>> and a text widget, to show the application's stdout as well as the
>>>> overall progress.
>>> Thats totally possible, just fire up qtdesigner and put it together.
>>> As an exercise you could try to de-couple this new dialog totally from
>>> the actual type of command line program it is running by providing a way
>>> to generally configure the command line to run and a regex to parse the
>>> stdout for progress.
>>>> Am I on the right track or are there easier/better ways?
>>>> Cheers,
>>>> frank
>>>> _______________________________________________
>>>> PySide mailing list
>>>> PySide at qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/pyside
>> _______________________________________________
>> PySide mailing list
>> PySide at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/pyside
> _______________________________________________
> PySide mailing list
> PySide at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/pyside

More information about the PySide mailing list