I might have lead you on a wild goose chase:

I have working python code that calls external process (using subprocess.Popen) and now I am writing a UI for it.

To get started I wrote a simple UI that connected to one of those external programs directly to establish the frame work for the new code and figure out how to properly handle the external programs stdout and stderr, be able to display things and cancel it from within my UI. After getting all that to work I thought all I have to do is connect to my actual python code rather than directly to the external program, and that is where I assumed QProcess to be able to do this, when instead I shuold simlpy switch to use QThread and reire that to give me access to stdout, be able to cancel it etc.
So what I am trying to do is simply this:

PySide UI --- calls --> pure python --- calls --> pure python --- calls --> external program

With the stdout of external program and the pure python apps being piped into the PySide UI for processing.


Sorry if I wasted your time :/


frank



On 24/01/14 16:22, Sean Fisk wrote:

Are you wanting to use |QProcess| or |QThread| because your GUI is blocked (aka frozen, not responding)?



--
Sean Fisk


On Thu, Jan 23, 2014 at 10:06 PM, Frank Rueter | OHUfx <[email protected] <mailto:[email protected]>> wrote:

    Actually, it's dawning on me that QProcess may be the wrong thing
    to use here, I guess I should consider using QThread instead,
    seeing all the code I need to run is Python anyway!?
    I was just experimented with QProcess running the external
    programs directly for testing so I kinda got stuck in thinking
    this is the way to go (since I got it all wired up to my UI already).





    On 24/01/14 15:42, Frank Rueter | OHUfx wrote:
    Thanks Sean and Ryan,

    I'm still not quite clear on how this ties into QProcess.start()
    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'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
    <[email protected] <mailto:[email protected]>> 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
        <[email protected] <mailto:[email protected]>> 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
            [email protected] <mailto:[email protected]>
            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
        [email protected] <mailto:[email protected]>
        http://lists.qt-project.org/mailman/listinfo/pyside





    _______________________________________________
    PySide mailing list
    [email protected]  <mailto:[email protected]>
    http://lists.qt-project.org/mailman/listinfo/pyside


    _______________________________________________
    PySide mailing list
    [email protected] <mailto:[email protected]>
    http://lists.qt-project.org/mailman/listinfo/pyside



_______________________________________________
PySide mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/pyside

Reply via email to