And of course I ran into trouble :-D
Here is my test code trying to ustilise QThread:
http://pastebin.com/Q26Q9M1M
The basic structure seems to work (the extra thread and the main thread
are running at the same time), but my UI does not update according to
the signal connections, e.g.:
When the thread starts the progress bar is supposed to be shown, the "Do
Work" button should be disabled, the "Cancel" button disabled.
etc.
I tried calling self.update() in the MainUI when the thread starts but
to no avail.
I'm sure I'm missing something obvious as usual.
I tried to adhere to what I learnt on this list about threading and
avoid sub-classing QThread.
Cheers,
frank
On 24/01/14 17:41, Frank Rueter | OHUfx wrote:
Great, thanks. I shall adjust my code.
I am interested in seeing how you would go about it, but let me have a
go from scratch, I will be able to understand things much better
afterwards :)
Cheers,
frank
On 24/01/14 17:38, Sean Fisk wrote:
On Thu, Jan 23, 2014 at 10:44 PM, Frank Rueter | OHUfx
<fr...@ohufx.com <mailto:fr...@ohufx.com>> wrote:
Much appreciated but as I mentioned, I think I jumped the gun
with my post and should be using QThread to hook the python code
to my QProgressBar and debug output window (QTextEdit).
That would be a correct way to use |QProgressBar|. Also, for
subprocess output, I would consider using |QPlainTextEdit| instead of
|QTextEdit| as is is more performant with high amounts of text.
If you are interested, I just wrote an asynchronous module for PySide
for the project on which I am currently working. It is based on
Python's futures <http://pythonhosted.org/futures/> module and works
great with Qt's signals/slots. Although the project is primarily
closed-source, I would be happy to share the async implementation
with you. I don't know if would fit your needs, but for us it's much
easier than manually spawning |QThread|s and even easier than
|QThreadPool|.
Good luck!
I will investigate that now
On 24/01/14 16:08, Sean Fisk wrote:
On Thu, Jan 23, 2014 at 9:42 PM, Frank Rueter | OHUfx
<fr...@ohufx.com <mailto:fr...@ohufx.com>> wrote:
Thanks Sean and Ryan,
I'm still not quite clear on how this ties into QProcess.start()
It doesn't tie in with |QProcess| at all. We're advising to
avoid using that :)
I do have a if __name__ ... block in the script in question.
An example would certainly be awesome, but if it's less
hassle, explaining how your and Ryan's advise helps use
QProcess on a python module might already suffice. Maybe a
simlpe example says it all though?!
I will whip up a simple example for you, but it might take a few
hours (lots of stuff to do right now).
I'm not using python 3 btw
Thanks guys for your help!!
frank
On 24/01/14 15:33, Sean Fisk wrote:
Hi Frank,
You should definitely avoid calling Python as a subprocess
if you can. As far as Ryan's example, I agree with the |if
__name__...| but I think that using the |imp| module is a
bit overkill. I would recommend using Setuptool's
|entry_points| keyword
<http://pythonhosted.org/setuptools/setuptools.html#automatic-script-creation>.
Or distutils' |scripts| keyword
<http://docs.python.org/2/distutils/setupscript.html#installing-scripts>,
if you must.
An example of a well-known Python package which does this
is Pygments
<https://bitbucket.org/birkenfeld/pygments-main>, which has
a large "library" component but also comes with the
|pygmentize| command-line script. The Pygments codebase is
pretty large, so if you would like me to whip up a simpler
example I'd be glad to do so.
Cheers,
--
Sean Fisk
On Thu, Jan 23, 2014 at 9:17 PM, Frank Rueter | OHUfx
<fr...@ohufx.com <mailto:fr...@ohufx.com>> wrote:
Sorry if I'm being thick, but I'm not quite
understanding how this helps to connect a python
function to qprocess?! All your code does is execute
the script, right?!
I can already call myscript.main() straight up, but
maybe I'm missing the point as I'm unfamiliar with the
imp module.
Let me elaborate a little bit more:
myscript.main() calls a bunch of other python scripts
that (directly or through other scripts again) execute
external programs to do some conversion work. Those
external programs spit out their progress to stdout
which I can see fine when I run myscript.main()
manually in a python terminal.
Now I need run myscript.main() via QProcess and grab
stdout to do be able to show a progress bar as well as
show stdout and stderr in a debug window inside my QT code.
Cheers,
frank
On 24/01/14 14:58, Ryan Gonzalez wrote:
If you put an "if __name__ == '__main__'" and a main
functions, you could always import the script from the
GUI frontend. Example:
myscript.py
def main(argv):
do_cool_stuff()
return 0
if __name__ == '__main__':
sys.exit(main(sys.argv))
mygui.py(Python 2):
import imp
...
main = imp.load_module('myscript',
*imp.find_module('myscript'))
main.main(my_argv)
mygui.py(Python 3):
import importlib.machinery
main =
importlib.machinery.SourceFileLoader('myscript',
'myscript.py').load_module('myscript')
main.main(my_argv)
On Thu, Jan 23, 2014 at 7:48 PM, Frank Rueter | OHUfx
<fr...@ohufx.com <mailto:fr...@ohufx.com>> wrote:
Hi all,
I got a little code design question:
I have a python script that does a lot of file
processing/converting/uploading etc and I'd like
to write a decent
interface for it now.
The main goal is to be able to show the user
detailed info about the
current step and progress as well as clean up
properly in case the whole
thing is cancelled.
My existing python code needs to stay independent
of QT so any
application that supports python can use it.
I am wondering now how to best connect the python
script and the PySide
code. Should I just run the script as an argument
to the python
interpreter like I would with any other program? E.g.:
process = QtCore.QProcess(self)
process.start(<path_to_python>,
<path_to_python_script>)
As simple as this seems, it feels odd to use
python to call itself as an
external program.
I'm happy to go that way but am curious how others
are doing this?!
Cheers,
frank
_______________________________________________
PySide mailing list
PySide@qt-project.org <mailto:PySide@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/pyside
--
Ryan
If anybody ever asks me why I prefer C++ to C, my
answer will be simple: "It's
becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't
think that was nul-terminated."
_______________________________________________
PySide mailing list
PySide@qt-project.org <mailto:PySide@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/pyside
_______________________________________________
PySide mailing list
PySide@qt-project.org
http://lists.qt-project.org/mailman/listinfo/pyside
_______________________________________________
PySide mailing list
PySide@qt-project.org
http://lists.qt-project.org/mailman/listinfo/pyside
