[PySide] a couple of QProgressDialog questions

[Sebastian Elsner]

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


-- 
check out www.pointcloud9.com

Sebastian Elsner - Pipeline Technical Director - RISE

t: +49 30 20180300 florian at risefx.com
f: +49 30 61651074 www.risefx.com

RISE FX GmbH
Schlesische Strasse 28, Aufgang B, 10997 Berlin
c/o action concept, An der Hasenkaule 1-7, 50354 Hürth
Geschaeftsfuehrer: Sven Pannicke, Robert Pinnow
Handelsregister Berlin HRB 106667 B