From frank at ohufx.com Tue Sep 3 08:31:09 2013 From: frank at ohufx.com (Frank Rueter | OHUfx) Date: Tue, 03 Sep 2013 18:31:09 +1200 Subject: [PySide] a couple of QProgressDialog questions Message-ID: <5225822D.3020304@ohufx.com> 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. 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? 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? 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. Am I on the right track or are there easier/better ways? Cheers, frank From frank at ohufx.com Tue Sep 3 09:34:08 2013 From: frank at ohufx.com (Frank Rueter | OHUfx) Date: Tue, 03 Sep 2013 19:34:08 +1200 Subject: [PySide] a couple of QProgressDialog questions In-Reply-To: <5225822D.3020304@ohufx.com> References: <5225822D.3020304@ohufx.com> Message-ID: <522590F0.7010808@ohufx.com> oops, ignore that redundant perform()method in there please: http://pastebin.com/7YRXPGqP On 9/3/13 6:31 PM, 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. > 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? > > 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? > > 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. > > 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 From sebastian at risefx.com Tue Sep 3 10:01:11 2013 From: sebastian at risefx.com (Sebastian Elsner) Date: Tue, 03 Sep 2013 10:01:11 +0200 Subject: [PySide] a couple of QProgressDialog questions In-Reply-To: <5225822D.3020304@ohufx.com> References: <5225822D.3020304@ohufx.com> Message-ID: <52259747.60008@risefx.com> 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 From sebastian at risefx.com Tue Sep 3 10:05:22 2013 From: sebastian at risefx.com (Sebastian Elsner) Date: Tue, 03 Sep 2013 10:05:22 +0200 Subject: [PySide] a couple of QProgressDialog questions In-Reply-To: <52259747.60008@risefx.com> References: <5225822D.3020304@ohufx.com> <52259747.60008@risefx.com> Message-ID: <52259842.70102@risefx.com> One thing to clarify. Neither QThread nor QProgressDialog go into the subclass of the QObject. They are all top level objects. On 09/03/2013 10:01 AM, 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 > -- 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 From frank at ohufx.com Sat Sep 7 07:44:24 2013 From: frank at ohufx.com (Frank Rueter | OHUfx) Date: Sat, 07 Sep 2013 17:44:24 +1200 Subject: [PySide] a couple of QProgressDialog questions In-Reply-To: <52259747.60008@risefx.com> References: <5225822D.3020304@ohufx.com> <52259747.60008@risefx.com> Message-ID: <522ABD38.5000109@ohufx.com> 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 > From sebastian at risefx.com Sat Sep 7 08:37:04 2013 From: sebastian at risefx.com (Sebastian Elsner) Date: Sat, 07 Sep 2013 08:37:04 +0200 Subject: [PySide] a couple of QProgressDialog questions In-Reply-To: <522ABD38.5000109@ohufx.com> References: <5225822D.3020304@ohufx.com> <52259747.60008@risefx.com> <522ABD38.5000109@ohufx.com> Message-ID: <522AC990.6090504@risefx.com> 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 From frank at ohufx.com Sat Sep 7 08:41:54 2013 From: frank at ohufx.com (Frank Rueter | OHUfx) Date: Sat, 07 Sep 2013 18:41:54 +1200 Subject: [PySide] a couple of QProgressDialog questions In-Reply-To: <522AC990.6090504@risefx.com> References: <5225822D.3020304@ohufx.com> <52259747.60008@risefx.com> <522ABD38.5000109@ohufx.com> <522AC990.6090504@risefx.com> Message-ID: <522ACAB2.5020402@ohufx.com> 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. Cheers, frank 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 From lucericml at gmail.com Mon Sep 9 17:28:20 2013 From: lucericml at gmail.com (Luc-Eric Rousseau) Date: Mon, 9 Sep 2013 11:28:20 -0400 Subject: [PySide] Wrapinstance is not 64-bit safe Message-ID: Hello, my team has logged the following Pyside bug: PYSIDE-191 wrapInstance should accept 64-bit address It causes pyside's wrapinstance to fail if an object's address is larger than 32-bit. This is apparently becoming more frequent under Windows 8. We've found a similar bug logged last August PYSIDE-103 shiboken.wrapInstance raises OverflowError for large addresse" We're proposing a fix in PYSIDE-191 From cernunnos.wynand at gmail.com Tue Sep 10 19:30:19 2013 From: cernunnos.wynand at gmail.com (cernunnos.wynand at gmail.com) Date: Tue, 10 Sep 2013 19:30:19 +0200 Subject: [PySide] Doc PySide 1.2.1 API Reference? Message-ID: <20130910193019.011a5a31@ubsev> Hello, Is there already an API Reference Documentation for PySide 1.2.1? On the website[1] I have not found it. Greetings, Cernunnos [1] http://qt-project.org/wiki/Category:LanguageBindings::PySide From amos.anderson at protabit.com Wed Sep 11 00:55:01 2013 From: amos.anderson at protabit.com (Amos Anderson) Date: Tue, 10 Sep 2013 15:55:01 -0700 Subject: [PySide] shiboken build issue with PythonLibs Message-ID: Hello PySide list! I'm trying to compile PySide on an OSX 10.6 machine, but I run into a problem where shiboken is linking to a python symbol __PyTrash_thread_deposit_object which doesn't exist in the local python it's supposed to be linking against (the symbol __PyTrash_deposit_object exists there instead, c.f. the text pasted below). That is, I'm storing a version of python in a project directory, and shiboken is supposed to link against that, but it appears to be linking against the python in /Library/Frameworks/Python.framework (which has extra symbols that my project python does not have). The environment.sh script is finding my python, and my python's libraries are on DYLD_LIBRARY_PATH, but shiboken and/or cmake seem to be ignoring them. The build works if I delete my python from /Library/Frameworks/Python.framework. I even tried adding: -DPYTHON_LIBRARY=/Users/amosa/triad/tools/python/lib/libpython2.7.dylib -DPYTHON_INCLUDE=/Users/amosa/triad/tools/python/include to the cmake command in build_and_install, but that didn't help. it printed: -- Found PythonLibs: /Users/amosa/triad/tools/python/lib/libpython2.7.dylib (found suitable version "2.7.5", minimum required is "2.6") -- Found PythonInterp: /Users/amosa/triad/tools/python/bin/python2.7 (found version "2.7.3") I can't explain the version discrepancy (my Frameworks version is 2.7.5, my local version is 2.7.3) I'm using cmake 2.8.10.1 So anyway, I have a solution available, but it's a hack... it would be nice to know if there's a way available that's less of a hack. Any suggestions? Thanks! Amos. [tower]/Users/amosa/triad> ./triad.sh mercurial version: 12958:b1a1cd107c97 Python 2.7.3 (default, Sep 10 2013, 11:59:53) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from PySide import QtGui Traceback (most recent call last): File "", line 1, in ImportError: dlopen(/Users/amosa/triad/tools/pyside/pyside-sandbox/lib/python2.7/site-packages/PySide/QtGui.so, 2): Symbol not found: __PyTrash_thread_deposit_object Referenced from: /Users/amosa/triad/tools/pyside/pyside-sandbox/lib/libshiboken-python2.7.1.1.dylib Expected in: flat namespace in /Users/amosa/triad/tools/pyside/pyside-sandbox/lib/libshiboken-python2.7.1.1.dylib >>> import OpenGL >>> import PySide >>> [tower]/Users/amosa/triad/tools/pyside/pyside-sandbox/lib> nm libshiboken-python2.7.1.1.dylib | grep Trash U __PyTrash_thread_deposit_object U __PyTrash_thread_destroy_chain [tower]/Users/amosa/triad/tools/pyside/pyside-sandbox/lib> nm ../../../python/lib/libpython2.7.dylib | grep Trash 000000000018ed20 D __PyTrash_delete_later 000000000018ed18 D __PyTrash_delete_nesting 00000000000561e0 T __PyTrash_deposit_object 0000000000056200 T __PyTrash_destroy_chain [tower]/Library/Frameworks/Python.framework/Versions/2.7> nm Python | grep Trash 0000000000193f00 D __PyTrash_delete_later 0000000000193ef8 D __PyTrash_delete_nesting 0000000000057140 T __PyTrash_deposit_object 0000000000057190 T __PyTrash_destroy_chain 0000000000057160 T __PyTrash_thread_deposit_object 00000000000571d0 T __PyTrash_thread_destroy_chain [tower]/Users/amosa/triad/tools/pyside/test/PySide-BuildScripts-2763427> diff build_and_install ../../BuildScripts/build_and_install 36c36 < PYSIDE_BS_CMAKE_FLAGS="-DALTERNATIVE_QT_INCLUDE_DIR=/Library/Frameworks/" --- > PYSIDE_BS_CMAKE_FLAGS="-DALTERNATIVE_QT_INCLUDE_DIR=/Users/amosa/triad/tools/qt/include/" [tower]/Users/amosa/triad/tools/pyside/test/PySide-BuildScripts-2763427> diff environment.sh ../../BuildScripts/environment.sh 21c21 < export PYSIDESANDBOXPATH=$HOME/pkg/pyside-sandbox-python3 --- > export PYSIDESANDBOXPATH=/Users/amosa/triad/tools/pyside/pyside-sandbox-python3 24,25c24,25 < PYTHONXY=`python -V 2>&1 | sed -e 's/Python \(2\.[0-9]*\).*/python\1/'` < export PYSIDESANDBOXPATH=$HOME/pkg/pyside-sandbox --- > PYTHONXY=`/Users/amosa/triad/tools/python/bin/python -V 2>&1 | sed -e 's/Python \(2\.[0-9]*\).*/python\1/'` > export PYSIDESANDBOXPATH=/Users/amosa/triad/tools/pyside/pyside-sandbox 33a34,37 > echo "#### python ="`which python` > echo "#### path = $PATH" > echo "#### dyld = $DYLD_LIBRARY_PATH" > #### python =/Users/amosa/triad/tools/python/bin/python #### path = /Users/amosa/triad/tools/pyside/pyside-sandbox/bin:/Users/amosa/triad/tools/python/bin:/Library/Frameworks/Python.framework/Versions/2.7/bin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/texbin:/Users/amos/bin:/Users/amosa/triad/apps:/Users/amosa/triad/tools/cmake/bin/ #### dyld = /Users/amosa/triad/tools/pyside/pyside-sandbox/lib:/Users/amosa/triad/tools/python/lib::/Users/amosa/triad/lib:/usr/local/cuda/lib From jpe at wingware.com Wed Sep 11 18:16:49 2013 From: jpe at wingware.com (John Ehresman) Date: Wed, 11 Sep 2013 12:16:49 -0400 Subject: [PySide] shiboken build issue with PythonLibs In-Reply-To: References: Message-ID: <52309771.9080404@wingware.com> On 9/10/13 6:55 PM, Amos Anderson wrote: > Hello PySide list! > > I'm trying to compile PySide on an OSX 10.6 machine, but I run into a problem where shiboken is linking to a python symbol __PyTrash_thread_deposit_object which doesn't exist in the local python it's supposed to be linking against (the symbol __PyTrash_deposit_object exists there instead, c.f. the text pasted below). That is, I'm storing a version of python in a project directory, and shiboken is supposed to link against that, but it appears to be linking against the python in /Library/Frameworks/Python.framework (which has extra symbols that my project python does not have). The environment.sh script is finding my python, and my python's libraries are on DYLD_LIBRARY_PATH, but shiboken and/or cmake seem to be ignoring them. The build works if I delete my python from /Library/Frameworks/Python.framework. > > I even tried adding: > -DPYTHON_LIBRARY=/Users/amosa/triad/tools/python/lib/libpython2.7.dylib -DPYTHON_INCLUDE=/Users/amosa/triad/tools/python/include > to the cmake command in build_and_install, but that didn't help. it printed: > -- Found PythonLibs: /Users/amosa/triad/tools/python/lib/libpython2.7.dylib (found suitable version "2.7.5", minimum required is "2.6") > -- Found PythonInterp: /Users/amosa/triad/tools/python/bin/python2.7 (found version "2.7.3") > I can't explain the version discrepancy (my Frameworks version is 2.7.5, my local version is 2.7.3) This is a binary incompatibility between Python 2.7.3 and Python 2.7.5. My guess is that your using the headers from 2.7.5, but trying to link against 2.7.3. Cheers, John From erik.johansson at fido.se Thu Sep 12 11:45:32 2013 From: erik.johansson at fido.se (Erik Johansson) Date: Thu, 12 Sep 2013 11:45:32 +0200 Subject: [PySide] Percent sign in QTableWidget Message-ID: Hi Percent sign in QTableWidget. I can not get it to show in the cell. The string gets cut off. In the tooltip it is shown. I have tried converting it to unicode and str. Various encodings utf-8, ascii. Escaping the % sign with %% and \% with no luck. Can someone help me out? Or have I hit some bug? Cheers, Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.johansson at fido.se Thu Sep 12 12:56:00 2013 From: erik.johansson at fido.se (Erik Johansson) Date: Thu, 12 Sep 2013 12:56:00 +0200 Subject: [PySide] Percent sign in QTableWidget In-Reply-To: References: Message-ID: PySide 1.1.2 and Qt 4.7.1 (Autodesk Maya 2012) if it helps. Cheers, Erik On Thu, Sep 12, 2013 at 11:45 AM, Erik Johansson wrote: > Hi > > Percent sign in QTableWidget. I can not get it to show in the cell. The > string gets cut off. In the tooltip it is shown. > > I have tried converting it to unicode and str. Various encodings utf-8, > ascii. Escaping the % sign with %% and \% with no luck. > > Can someone help me out? Or have I hit some bug? > > Cheers, > Erik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amos.anderson at protabit.com Thu Sep 12 18:26:34 2013 From: amos.anderson at protabit.com (Amos Anderson) Date: Thu, 12 Sep 2013 09:26:34 -0700 Subject: [PySide] shiboken build issue with PythonLibs In-Reply-To: <52309771.9080404@wingware.com> References: <52309771.9080404@wingware.com> Message-ID: <9EF676B2-058F-43AE-B85A-2EADF2290024@protabit.com> On Sep 11, 2013, at 9:16 AM, John Ehresman wrote: > On 9/10/13 6:55 PM, Amos Anderson wrote: >> Hello PySide list! >> >> I'm trying to compile PySide on an OSX 10.6 machine, but I run into a problem where shiboken is linking to a python symbol __PyTrash_thread_deposit_object which doesn't exist in the local python it's supposed to be linking against (the symbol __PyTrash_deposit_object exists there instead, c.f. the text pasted below). That is, I'm storing a version of python in a project directory, and shiboken is supposed to link against that, but it appears to be linking against the python in /Library/Frameworks/Python.framework (which has extra symbols that my project python does not have). The environment.sh script is finding my python, and my python's libraries are on DYLD_LIBRARY_PATH, but shiboken and/or cmake seem to be ignoring them. The build works if I delete my python from /Library/Frameworks/Python.framework. >> >> I even tried adding: >> -DPYTHON_LIBRARY=/Users/amosa/triad/tools/python/lib/libpython2.7.dylib -DPYTHON_INCLUDE=/Users/amosa/triad/tools/python/include >> to the cmake command in build_and_install, but that didn't help. it printed: >> -- Found PythonLibs: /Users/amosa/triad/tools/python/lib/libpython2.7.dylib (found suitable version "2.7.5", minimum required is "2.6") >> -- Found PythonInterp: /Users/amosa/triad/tools/python/bin/python2.7 (found version "2.7.3") >> I can't explain the version discrepancy (my Frameworks version is 2.7.5, my local version is 2.7.3) > > This is a binary incompatibility between Python 2.7.3 and Python 2.7.5. My guess is that your using the headers from 2.7.5, but trying to link against 2.7.3. > I agree... the question is how can I prevent cmake/shiboken from compiling using two different pythons concurrently? Thanks! Amos. > Cheers, > > John From matthew.woehlke at kitware.com Thu Sep 12 19:05:04 2013 From: matthew.woehlke at kitware.com (Matthew Woehlke) Date: Thu, 12 Sep 2013 13:05:04 -0400 Subject: [PySide] shiboken build issue with PythonLibs In-Reply-To: <9EF676B2-058F-43AE-B85A-2EADF2290024@protabit.com> References: <52309771.9080404@wingware.com> <9EF676B2-058F-43AE-B85A-2EADF2290024@protabit.com> Message-ID: On 2013-09-12 12:26, Amos Anderson wrote: > the question is how can I prevent cmake/shiboken from compiling using two different pythons concurrently? Use ccmake/cmakegui to check/ensure that PYTHON_EXECUTABLE, PYTHON_INCLUDE_DIR and PYTHON_LIBRARY are all pointing to the same version of Python? (You'll need to turn on display of advanced options, 't' key in ccmake.) -- Matthew From amos.anderson at protabit.com Thu Sep 12 23:13:14 2013 From: amos.anderson at protabit.com (Amos Anderson) Date: Thu, 12 Sep 2013 14:13:14 -0700 Subject: [PySide] Documentation mistake for PySide/PyPi Message-ID: Hello PySide list -- I started this email to ask for help fixing a bug, but after pawing through the setup.py script, I found the fix myself... So this email is to request that this be documented somewhere like on the PyPi page! I was using a command like this to build pyside: python setup.py build --cmake /Users/amosa/triad/tools/cmake/bin/cmake --qmake /Users/amosa/triad/tools/qt/Qt/bin/qmake but I was getting this error with all the things I tried (different OSX machines, different cmake versions, different pythons, etc): /bin/sh: line 1: 13240 Segmentation fault: 11 /Users/amos/triad/tools/pyside/PySide-1.2.1/pyside_install/py2.7-qt4.8.4-64bit-release/bin/shiboken --generator-set=shiboken --enable-parent-ctor-heuristic --enable-pyside-extensions --enable-return-value-heuristic --use-isnull-as-nb_nonzero /Users/amos/triad/tools/pyside/PySide-1.2.1/pyside_build/py2.7-qt4.8.4-64bit-release/pyside/PySide/pyside_global.h --include-paths=/Users/amos/triad/tools/pyside/PySide-1.2.1/sources/pyside/PySide:/Library/Frameworks --typesystem-paths=/Users/amos/triad/tools/pyside/PySide-1.2.1/sources/pyside/PySide:/Users/amos/triad/tools/pyside/PySide-1.2.1/sources/pyside/PySide/QtCore --output-directory=/Users/amos/triad/tools/pyside/PySide-1.2.1/pyside_build/py2.7-qt4.8.4-64bit-release/pyside/PySide/QtCore --license-file=/Users/amos/triad/tools/pyside/PySide-1.2.1/sources/pyside/PySide/QtCore/../licensecomment.txt /Users/amos/triad/tools/pyside/PySide-1.2.1/pyside_build/py2.7-qt4.8.4-64bit-release/pyside/PySide/QtCore/typesystem_core.xml --api-version=4.8 --drop-type-entries="" make[2]: *** [PySide/QtCore/PySide/QtCore/qabstracteventdispatcher_wrapper.cpp] Error 139 make[1]: *** [PySide/QtCore/CMakeFiles/QtCore.dir/all] Error 2 make: *** [all] Error 2 error: Error compiling pyside The problem was that I needed to set the environment variable QTDIR... It's unintuitive to me to tell people that they should specify the path to qmake when using the PyPi install, but then say nothing about QTDIR! Well, perhaps at least this email will show up when people google the error message. Thanks! Amos. From backup.rlacko at gmail.com Thu Sep 12 23:59:29 2013 From: backup.rlacko at gmail.com (Roman Lacko) Date: Thu, 12 Sep 2013 23:59:29 +0200 Subject: [PySide] Documentation mistake for PySide/PyPi In-Reply-To: References: Message-ID: Hi Amos, thanks for reporting this. We (setup.py authors) know about missing documentation in setup.py (and PyPI) about building on OSX. We will try to update the documentation and add the missing parts before next release. Thanks Roman 2013/9/12 Amos Anderson > Hello PySide list -- > > I started this email to ask for help fixing a bug, but after pawing > through the setup.py script, I found the fix myself... So this email is to > request that this be documented somewhere like on the PyPi page! I was > using a command like this to build pyside: > > python setup.py build --cmake /Users/amosa/triad/tools/cmake/bin/cmake > --qmake /Users/amosa/triad/tools/qt/Qt/bin/qmake > > but I was getting this error with all the things I tried (different OSX > machines, different cmake versions, different pythons, etc): > > > /bin/sh: line 1: 13240 Segmentation fault: 11 > /Users/amos/triad/tools/pyside/PySide-1.2.1/pyside_install/py2.7-qt4.8.4-64bit-release/bin/shiboken > --generator-set=shiboken --enable-parent-ctor-heuristic > --enable-pyside-extensions --enable-return-value-heuristic > --use-isnull-as-nb_nonzero > /Users/amos/triad/tools/pyside/PySide-1.2.1/pyside_build/py2.7-qt4.8.4-64bit-release/pyside/PySide/pyside_global.h > --include-paths=/Users/amos/triad/tools/pyside/PySide-1.2.1/sources/pyside/PySide:/Library/Frameworks > --typesystem-paths=/Users/amos/triad/tools/pyside/PySide-1.2.1/sources/pyside/PySide:/Users/amos/triad/tools/pyside/PySide-1.2.1/sources/pyside/PySide/QtCore > --output-directory=/Users/amos/triad/tools/pyside/PySide-1.2.1/pyside_build/py2.7-qt4.8.4-64bit-release/pyside/PySide/QtCore > --license-file=/Users/amos/triad/tools/pyside/PySide-1.2.1/sources/pyside/PySide/QtCore/../licensecomment.txt > /Users/amos/triad/tools/pyside/PySide-1.2.1/pyside_build/py2.7-qt4.8.4-64bit-release/pyside > /PySide/QtCore/typesystem_core.xml --api-version=4.8 > --drop-type-entries="" > make[2]: *** > [PySide/QtCore/PySide/QtCore/qabstracteventdispatcher_wrapper.cpp] Error 139 > make[1]: *** [PySide/QtCore/CMakeFiles/QtCore.dir/all] Error 2 > make: *** [all] Error 2 > error: Error compiling pyside > > > > The problem was that I needed to set the environment variable QTDIR... > It's unintuitive to me to tell people that they should specify the path to > qmake when using the PyPi install, but then say nothing about QTDIR! Well, > perhaps at least this email will show up when people google the error > message. > > Thanks! > Amos. > > > > > > > > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter_karasev at agilent.com Fri Sep 13 00:57:33 2013 From: peter_karasev at agilent.com (peter_karasev at agilent.com) Date: Thu, 12 Sep 2013 16:57:33 -0600 Subject: [PySide] building pyside on vs2012 + qt4.8.4 + python 2.7.3 ? Message-ID: <848BA640153D0F4EAAD378DA60AC071D0F27599A6E@cos-us-mb14.agilent.com> Hi, It would be nice if I can compile pyside on visual studio 2012 with QT 4.8.4 and python 2.7.3, both of which are also compiled with vs2012 x64. Has anyone done this in the past, there must be some modified step to take in the setup? In particular, I suspect that some CMake steps try to infer the compiler version from the python version, which is wrong in this case- 2.7.3 python is custom build on the vs2012 compiler. Any info is appreciated, and I'll be happy to share any modified build config files if I get it going satisfactorily. ------------------------ Peter A. Karasev From peter_karasev at agilent.com Fri Sep 13 08:12:12 2013 From: peter_karasev at agilent.com (peter_karasev at agilent.com) Date: Fri, 13 Sep 2013 00:12:12 -0600 Subject: [PySide] building pyside on vs2012 + qt4.8.4 + python 2.7.3 ? In-Reply-To: References: <848BA640153D0F4EAAD378DA60AC071D0F27599A6E@cos-us-mb14.agilent.com> Message-ID: <848BA640153D0F4EAAD378DA60AC071D0F27599AE2@cos-us-mb14.agilent.com> Not exactly. To step back a bit, I see that the linux instructions involve cmake: http://qt-project.org/wiki/Building_PySide_on_Linux (and this works great, I got pyside + boost::python both running in an embedded shell in my application and so on) But, the windows build instructions don't running cmake manually (presumably it gets called from the scripts): http://qt-project.org/wiki/Building_PySide_on_Windows Are these instructions just wrong? Should I expect mirroring the linux instructions on windows to work mostly the same? I guess I will start to dig into the pyside-setup scripts at this point ... it is also possible that I have a %PATH% issue, mine is basically empty since there are too many versions of DLLs on the computer. -----Original Message----- From: Owen Kelly [mailto:owensother at sympatico.ca] Sent: Thursday, September 12, 2013 5:17 PM To: KARASEV,PETER (A-WestlakeVillage,ex1) Subject: RE: [PySide] building pyside on vs2012 + qt4.8.4 + python 2.7.3 ? Not sure if this is what you mean, but I am able to force cmake to do 2008 builds like this: cmake .. -G "Visual Studio 9 2008" maybe there is a similar string for the MSVC version that you are targeting. -----Original Message----- From: pyside-bounces+oekelly=ieee.org at qt-project.org [mailto:pyside-bounces+oekelly=ieee.org at qt-project.org] On Behalf Of peter_karasev at agilent.com Sent: September-12-13 6:58 PM To: pyside at qt-project.org; contact at pyside.org Subject: [PySide] building pyside on vs2012 + qt4.8.4 + python 2.7.3 ? Hi, It would be nice if I can compile pyside on visual studio 2012 with QT 4.8.4 and python 2.7.3, both of which are also compiled with vs2012 x64. Has anyone done this in the past, there must be some modified step to take in the setup? In particular, I suspect that some CMake steps try to infer the compiler version from the python version, which is wrong in this case- 2.7.3 python is custom build on the vs2012 compiler. Any info is appreciated, and I'll be happy to share any modified build config files if I get it going satisfactorily. ------------------------ Peter A. Karasev _______________________________________________ PySide mailing list PySide at qt-project.org http://lists.qt-project.org/mailman/listinfo/pyside From peter_karasev at agilent.com Fri Sep 13 08:23:19 2013 From: peter_karasev at agilent.com (peter_karasev at agilent.com) Date: Fri, 13 Sep 2013 00:23:19 -0600 Subject: [PySide] building pyside on vs2012 + qt4.8.4 + python 2.7.3 ? In-Reply-To: <848BA640153D0F4EAAD378DA60AC071D0F27599AE2@cos-us-mb14.agilent.com> References: <848BA640153D0F4EAAD378DA60AC071D0F27599A6E@cos-us-mb14.agilent.com> <848BA640153D0F4EAAD378DA60AC071D0F27599AE2@cos-us-mb14.agilent.com> Message-ID: <848BA640153D0F4EAAD378DA60AC071D0F27599AE3@cos-us-mb14.agilent.com> Yep adding to the PATH and setting PYTHONHOME gets all the projects in shiboken built. Here were my commands: C:\cygwin\home\pkarasev\source\build-shiboken-debug\shibokenmodule>set PATH=C:\hped\builds\tfstools\vs2012\win32_64\cmake\2.8.10.2\bin;%PATH% C:\cygwin\home\pkarasev\source\build-shiboken-debug\shibokenmodule>set PATH=C:\hped\builds\tfstools\vs2012\win32_64\python\2.7.3\win32_64\debug\python\bin;%PATH% C:\cygwin\home\pkarasev\source\build-shiboken-debug\shibokenmodule>set PYTHONHOME=C:\hped\builds\tfstools\vs2012\win32_64\python\2.7.3\win32_64\debug\python C:\cygwin\home\pkarasev\source\build-shiboken-debug\shibokenmodule>cd ../ C:\cygwin\home\pkarasev\source\build-shiboken-debug>cmake-gui . C:\cygwin\home\pkarasev\source\build-shiboken-debug>devenv -pk -----Original Message----- From: pyside-bounces+peter_karasev=agilent.com at qt-project.org [mailto:pyside-bounces+peter_karasev=agilent.com at qt-project.org] On Behalf Of peter_karasev at agilent.com Sent: Thursday, September 12, 2013 11:12 PM To: oekelly at ieee.org Cc: pyside at qt-project.org Subject: Re: [PySide] building pyside on vs2012 + qt4.8.4 + python 2.7.3 ? Not exactly. To step back a bit, I see that the linux instructions involve cmake: http://qt-project.org/wiki/Building_PySide_on_Linux (and this works great, I got pyside + boost::python both running in an embedded shell in my application and so on) But, the windows build instructions don't running cmake manually (presumably it gets called from the scripts): http://qt-project.org/wiki/Building_PySide_on_Windows Are these instructions just wrong? Should I expect mirroring the linux instructions on windows to work mostly the same? I guess I will start to dig into the pyside-setup scripts at this point ... it is also possible that I have a %PATH% issue, mine is basically empty since there are too many versions of DLLs on the computer. -----Original Message----- From: Owen Kelly [mailto:owensother at sympatico.ca] Sent: Thursday, September 12, 2013 5:17 PM To: KARASEV,PETER (A-WestlakeVillage,ex1) Subject: RE: [PySide] building pyside on vs2012 + qt4.8.4 + python 2.7.3 ? Not sure if this is what you mean, but I am able to force cmake to do 2008 builds like this: cmake .. -G "Visual Studio 9 2008" maybe there is a similar string for the MSVC version that you are targeting. -----Original Message----- From: pyside-bounces+oekelly=ieee.org at qt-project.org [mailto:pyside-bounces+oekelly=ieee.org at qt-project.org] On Behalf Of peter_karasev at agilent.com Sent: September-12-13 6:58 PM To: pyside at qt-project.org; contact at pyside.org Subject: [PySide] building pyside on vs2012 + qt4.8.4 + python 2.7.3 ? Hi, It would be nice if I can compile pyside on visual studio 2012 with QT 4.8.4 and python 2.7.3, both of which are also compiled with vs2012 x64. Has anyone done this in the past, there must be some modified step to take in the setup? In particular, I suspect that some CMake steps try to infer the compiler version from the python version, which is wrong in this case- 2.7.3 python is custom build on the vs2012 compiler. Any info is appreciated, and I'll be happy to share any modified build config files if I get it going satisfactorily. ------------------------ Peter A. Karasev _______________________________________________ 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 From Zhu.Zhong at alcatel-sbell.com.cn Fri Sep 13 10:12:51 2013 From: Zhu.Zhong at alcatel-sbell.com.cn (ZHONG Zhu) Date: Fri, 13 Sep 2013 08:12:51 +0000 Subject: [PySide] Can't find QIdentityProxyModel from QtGui or QtCore In-Reply-To: <848BA640153D0F4EAAD378DA60AC071D0F27599AE2@cos-us-mb14.agilent.com> References: <848BA640153D0F4EAAD378DA60AC071D0F27599A6E@cos-us-mb14.agilent.com> <848BA640153D0F4EAAD378DA60AC071D0F27599AE2@cos-us-mb14.agilent.com> Message-ID: Is QIdentityProxyModel built in PySide 1.2.1? From Zhu.Zhong at alcatel-sbell.com.cn Mon Sep 16 05:08:39 2013 From: Zhu.Zhong at alcatel-sbell.com.cn (ZHONG Zhu) Date: Mon, 16 Sep 2013 03:08:39 +0000 Subject: [PySide] Can't find QIdentityProxyModel from QtGui or QtCore In-Reply-To: References: <848BA640153D0F4EAAD378DA60AC071D0F27599A6E@cos-us-mb14.agilent.com> <848BA640153D0F4EAAD378DA60AC071D0F27599AE2@cos-us-mb14.agilent.com> Message-ID: Hope someone can help confirm this. If it's missing, can PySide team include this class in? Thanks! -----Original Message----- From: pyside-bounces+zhu.zhong=alcatel-sbell.com.cn at qt-project.org [mailto:pyside-bounces+zhu.zhong=alcatel-sbell.com.cn at qt-project.org] On Behalf Of ZHONG Zhu Sent: Friday, September 13, 2013 4:13 PM To: pyside at qt-project.org Subject: [PySide] Can't find QIdentityProxyModel from QtGui or QtCore Is QIdentityProxyModel built in PySide 1.2.1? _______________________________________________ PySide mailing list PySide at qt-project.org http://lists.qt-project.org/mailman/listinfo/pyside From techtonik at gmail.com Mon Sep 16 08:34:51 2013 From: techtonik at gmail.com (anatoly techtonik) Date: Mon, 16 Sep 2013 09:34:51 +0300 Subject: [PySide] Can't find QIdentityProxyModel from QtGui or QtCore In-Reply-To: References: <848BA640153D0F4EAAD378DA60AC071D0F27599A6E@cos-us-mb14.agilent.com> <848BA640153D0F4EAAD378DA60AC071D0F27599AE2@cos-us-mb14.agilent.com> Message-ID: On Mon, Sep 16, 2013 at 6:08 AM, ZHONG Zhu wrote: > Hope someone can help confirm this. If it's missing, can PySide team include this class in? Thanks! There is no PySide team anymore, only a bunch of contributors, including you. =) And no, I don't know how to check if a symbol is exported or missing from PySide. But I would try getting PySide source, and grep *.xml files for QIdentityProxyModel. *.xml files contain mappings of C++ names and types to Python, and IIRC they called "type definitions" or typedefs, so if anything should be included - it should be included there. I couldn't get the format of those files - it's too C++ish and XMLish, so I can't tell it supports inclusion masks like QIdentity* that may spoil the fun. Hope this helps. -- anatoly t. From schampailler at skynet.be Sat Sep 21 08:41:38 2013 From: schampailler at skynet.be (Stefan Champailler) Date: Sat, 21 Sep 2013 08:41:38 +0200 Subject: [PySide] Percent sign in QTableWidget In-Reply-To: References: Message-ID: <523D3FA2.10207@skynet.be> Have you got a bit of code to show that bug ? It's quite difficult to know exactly how it happens. Personnally I use QTableView and not QTableWidget. But there I've encountered lots of issues but none of theses were bugs. It's just that celle rendering is more complicated than it seems (well, for me :-)) Stefan On 09/12/2013 12:56 PM, Erik Johansson wrote: > PySide 1.1.2 and Qt 4.7.1 (Autodesk Maya 2012) if it helps. > > Cheers, > Erik > > > On Thu, Sep 12, 2013 at 11:45 AM, Erik Johansson wrote: > >> Hi >> >> Percent sign in QTableWidget. I can not get it to show in the cell. The >> string gets cut off. In the tooltip it is shown. >> >> I have tried converting it to unicode and str. Various encodings utf-8, >> ascii. Escaping the % sign with %% and \% with no luck. >> >> Can someone help me out? Or have I hit some bug? >> >> Cheers, >> Erik >> > > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside -- Timeo Danaos et dona ferentes -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.johansson at fido.se Sat Sep 21 12:08:54 2013 From: erik.johansson at fido.se (Erik Johansson) Date: Sat, 21 Sep 2013 12:08:54 +0200 Subject: [PySide] Percent sign in QTableWidget In-Reply-To: <523D3FA2.10207@skynet.be> References: <523D3FA2.10207@skynet.be> Message-ID: It was actually not a bug with the percent sign not being shown. It was Wordwrap that for some reason considered % being a good place to split a line (long filepath with %04d.exr at the end). On top of that I had fixed height cells so could not see the second row in the cell. When I turned of wordwrap all worked good. Cheers, Erik On Sat, Sep 21, 2013 at 8:41 AM, Stefan Champailler wrote: > Have you got a bit of code to show that bug ? It's quite difficult to > know exactly how it happens. > > Personnally I use QTableView and not QTableWidget. But there I've > encountered lots of issues but none of theses were bugs. It's just that > celle rendering is more complicated than it seems (well, for me :-)) > > Stefan > > > > > On 09/12/2013 12:56 PM, Erik Johansson wrote: > > PySide 1.1.2 and Qt 4.7.1 (Autodesk Maya 2012) if it helps. > > Cheers, > Erik > > > On Thu, Sep 12, 2013 at 11:45 AM, Erik Johansson wrote: > > > Hi > > Percent sign in QTableWidget. I can not get it to show in the cell. The > string gets cut off. In the tooltip it is shown. > > I have tried converting it to unicode and str. Various encodings utf-8, > ascii. Escaping the % sign with %% and \% with no luck. > > Can someone help me out? Or have I hit some bug? > > Cheers, > Erik > > > > > _______________________________________________ > PySide mailing listPySide at qt-project.orghttp://lists.qt-project.org/mailman/listinfo/pyside > > > -- > Timeo Danaos et dona ferentes > > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.turtle at gmail.com Sun Sep 22 22:46:48 2013 From: john.turtle at gmail.com (John Tourtellott) Date: Sun, 22 Sep 2013 16:46:48 -0400 Subject: [PySide] Shiboken-generated __nonzero__() methods and truth value testing Message-ID: I am using Shiboken to wrap a small class library. In my typesystem.xml file, I have added a __nonzero__() method to some of the classes using the element. The method gets generated OK and I can call it from python, however, python is *not* calling the Shiboken-generated __nonzero__() method when doing truth value testing, for example, in an "if object:" expression. Looking briefly at the Shiboken source, in particular, CppGenerator::hasBoolCast(), I get the impression that I *must* use the --use-isnull-as-nb_nonzero command-line option in order to get the expected boolean value. My tests further indicate that this option only applies to isNull() methods that are implemented in the C++ classes, not added via the typesystem file. Is this correct? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.woehlke at kitware.com Mon Sep 23 19:20:26 2013 From: matthew.woehlke at kitware.com (Matthew Woehlke) Date: Mon, 23 Sep 2013 13:20:26 -0400 Subject: [PySide] Shiboken-generated __nonzero__() methods and truth value testing In-Reply-To: References: Message-ID: On 2013-09-22 16:46, John Tourtellott wrote: > I am using Shiboken to wrap a small class library. In my typesystem.xml > file, I have added a __nonzero__() method to some of the classes using the > element. The method gets generated OK and I can call it from > python, however, python is *not* calling the Shiboken-generated > __nonzero__() method when doing truth value testing, for example, in an "if > object:" expression. > > Looking briefly at the Shiboken source, in particular, > CppGenerator::hasBoolCast(), I get the impression that I *must* use the > --use-isnull-as-nb_nonzero command-line option in order to get the expected > boolean value. My tests further indicate that this option only applies to > isNull() methods that are implemented in the C++ classes, not added via the > typesystem file. Is this correct? According to http://stackoverflow.com/questions/9828822/how-should-nonzero-be-implemented-using-the-python-c-api, type customizations like this never use "normal" functions, but must use the nb_* members of the cpython object structure. Do I guess there are a few options: 1. Add a C++ isNull(). 2. Modify Shiboken to allow specifying the name of the nb_bool method. (Still must implement it in C++) 3. Modify Shiboken to recognize typesystem-added functions for nb_bool. 4. Modify Shiboken to (preferentially?) recognize __nonzero__ as the nb_bool method (likely in combination with (3)). (2), (3) and (4) are more or less orthogonal; there would be benefit to implementing all of them. I happen to know that (1) is not feasible in our case, as the class in question is an STL class. -- Matthew