From javier.correa at gmail.com Fri Nov 2 23:27:24 2012 From: javier.correa at gmail.com (Javier Correa) Date: Fri, 2 Nov 2012 22:27:24 +0000 Subject: [PySide] PySide for mac Message-ID: Hello, the binary files for mac osx are down, and I've tried to build from source but I'm getting a segmentation fault from shiboken. Is there any mirror with the mac version of pyside ( pyside-1.1.1-qt48-py27apple.pkg )? -- Regards, Javier Correa PhD Student @ Imperial College, London, UK Por favor, no imprimas este e-mail si realmente no lo necesitas... Conservar el medio ambiente es nuestra tarea... Please, don't print this e-mail if it's not needed... preserving the environment is our task... -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Sun Nov 4 03:55:17 2012 From: matthew.brett at gmail.com (Matthew Brett) Date: Sat, 3 Nov 2012 19:55:17 -0700 Subject: [PySide] Best place to discuss fixes to pyside-setup? Message-ID: Hi, I have been making some modifications to the PySide setup.py and other scripts to make it work with OSX. I see there is: https://github.com/PySide/pyside-setup but there don't appear to be any pull requests or issues associated. Should I use those - or should I first send or discuss changes on this list? Thanks in advance for any pointers, Best, Matthew From backup.rlacko at gmail.com Sun Nov 4 13:22:10 2012 From: backup.rlacko at gmail.com (Roman Lacko) Date: Sun, 4 Nov 2012 13:22:10 +0100 Subject: [PySide] Best place to discuss fixes to pyside-setup? In-Reply-To: References: Message-ID: Hi Matthew, I'm author of pyside-setup, you can use github pull requests and issue list. And thanks for adding MacOSX support to pyside-setup. Regards R. 2012/11/4 Matthew Brett > Hi, > > I have been making some modifications to the PySide setup.py and other > scripts to make it work with OSX. I see there is: > > https://github.com/PySide/pyside-setup > > but there don't appear to be any pull requests or issues associated. > Should I use those - or should I first send or discuss changes on this > list? > > Thanks in advance for any pointers, > > Best, > > Matthew > _______________________________________________ > 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 matthew.brett at gmail.com Mon Nov 5 20:24:10 2012 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 5 Nov 2012 11:24:10 -0800 Subject: [PySide] Best place to discuss fixes to pyside-setup? In-Reply-To: References: Message-ID: Hi, On Sun, Nov 4, 2012 at 4:22 AM, Roman Lacko wrote: > Hi Matthew, > > I'm author of pyside-setup, you can use github pull requests and issue list. > And thanks for adding MacOSX support to pyside-setup. No problem - I will submit a pull request today. Where is the best place to discuss design-type issues - here or on Issues or the Wiki? Cheers, Matthew From techtonik at gmail.com Mon Nov 5 22:47:55 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 6 Nov 2012 00:47:55 +0300 Subject: [PySide] Best place to discuss fixes to pyside-setup? In-Reply-To: References: Message-ID: On Mon, Nov 5, 2012 at 10:24 PM, Matthew Brett wrote: > Hi, > > On Sun, Nov 4, 2012 at 4:22 AM, Roman Lacko wrote: >> Hi Matthew, >> >> I'm author of pyside-setup, you can use github pull requests and issue list. >> And thanks for adding MacOSX support to pyside-setup. > > No problem - I will submit a pull request today. Where is the best > place to discuss design-type issues - here or on Issues or the Wiki? I suspect that here is fine. From matthew.brett at gmail.com Tue Nov 6 03:12:49 2012 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 5 Nov 2012 18:12:49 -0800 Subject: [PySide] PySide-setup setup.py install fails because system library rpath not set Message-ID: Hi, I am just getting used to PySide-setup - thanks for all the work on that. I wanted to see if I could get pyside built and compiled using a standard: git clone git://github.com/PySide/pyside-setup.git cd pyside-setup python setup.py install (this on Ubuntu 12.04) All goes well, with the resulting output finishing with: Patched rpath in /home/mb312/dev_trees/pyside-setup/PySide/QtDeclarative.so to /home/mb312/dev_trees/pyside-setup/PySide. Patched rpath in /home/mb312/dev_trees/pyside-setup/PySide/shiboken.so to /home/mb312/dev_trees/pyside-setup/PySide. Patched rpath in /home/mb312/dev_trees/pyside-setup/PySide/QtHelp.so to /home/mb312/dev_trees/pyside-setup/PySide. PySide package successfully installed in /home/mb312/dev_trees/pyside-setup/PySide... But - these lines are telling me that the libraries are being patched inside the local PySide directory, not the directory to which the files are being installed. And indeed: (pyside27)[mb312 at blanca ~/dev_trees/pyside-setup (master)]$ python Python 2.7.3 (default, Aug 1 2012, 05:16:07) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import PySide >>> print PySide.__file__ PySide/__init__.pyc >>> import PySide.QtCore >>> exit() - the import works in the local directory, but: (pyside27)[mb312 at blanca ~/dev_trees/pyside-setup (master)]$ cd .. (pyside27)[mb312 at blanca ~/dev_trees]$ python Python 2.7.3 (default, Aug 1 2012, 05:16:07) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import PySide >>> print PySide.__file__ /home/mb312/.virtualenvs/pyside27/local/lib/python2.7/site-packages/PySide/__init__.pyc >>> import PySide.QtCore Traceback (most recent call last): File "", line 1, in ImportError: libpyside-python2.7.so.1.1: cannot open shared object file: No such file or directory importing from where we've installed to, does _not_ work. I guess one fix would be to move the local 'PySide' directory out of the way before running the last `pyside_postinstall.py` command, that does the rpath patching above? But that would break something else? Cheers, Matthew From backup.rlacko at gmail.com Tue Nov 6 09:04:03 2012 From: backup.rlacko at gmail.com (Roman Lacko) Date: Tue, 6 Nov 2012 09:04:03 +0100 Subject: [PySide] PySide-setup setup.py install fails because system library rpath not set In-Reply-To: References: Message-ID: Hi, Thanks for reporting this bug Rpath should be patched to install dir not to actual build dir, I will fix this. Regards R. 2012/11/6 Matthew Brett > Hi, > > I am just getting used to PySide-setup - thanks for all the work on that. > > I wanted to see if I could get pyside built and compiled using a standard: > > git clone git://github.com/PySide/pyside-setup.git > cd pyside-setup > python setup.py install > > (this on Ubuntu 12.04) > > All goes well, with the resulting output finishing with: > > Patched rpath in > /home/mb312/dev_trees/pyside-setup/PySide/QtDeclarative.so to > /home/mb312/dev_trees/pyside-setup/PySide. > Patched rpath in /home/mb312/dev_trees/pyside-setup/PySide/shiboken.so > to /home/mb312/dev_trees/pyside-setup/PySide. > Patched rpath in /home/mb312/dev_trees/pyside-setup/PySide/QtHelp.so > to /home/mb312/dev_trees/pyside-setup/PySide. > PySide package successfully installed in > /home/mb312/dev_trees/pyside-setup/PySide... > > But - these lines are telling me that the libraries are being patched > inside the local PySide directory, not the directory to which the > files are being installed. And indeed: > > (pyside27)[mb312 at blanca ~/dev_trees/pyside-setup (master)]$ python > Python 2.7.3 (default, Aug 1 2012, 05:16:07) > [GCC 4.6.3] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import PySide > >>> print PySide.__file__ > PySide/__init__.pyc > >>> import PySide.QtCore > >>> exit() > > - the import works in the local directory, but: > > (pyside27)[mb312 at blanca ~/dev_trees/pyside-setup (master)]$ cd .. > (pyside27)[mb312 at blanca ~/dev_trees]$ python > Python 2.7.3 (default, Aug 1 2012, 05:16:07) > [GCC 4.6.3] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import PySide > >>> print PySide.__file__ > > /home/mb312/.virtualenvs/pyside27/local/lib/python2.7/site-packages/PySide/__init__.pyc > >>> import PySide.QtCore > Traceback (most recent call last): > File "", line 1, in > ImportError: libpyside-python2.7.so.1.1: cannot open shared object > file: No such file or directory > > importing from where we've installed to, does _not_ work. > > I guess one fix would be to move the local 'PySide' directory out of > the way before running the last `pyside_postinstall.py` command, that > does the rpath patching above? But that would break something else? > > Cheers, > > Matthew > _______________________________________________ > 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 davecurtis at sonic.net Mon Nov 12 07:02:01 2012 From: davecurtis at sonic.net (Dave Curtis) Date: Sun, 11 Nov 2012 22:02:01 -0800 Subject: [PySide] total n00b question about hellogl geometry hookup Message-ID: <50A090D9.7020402@sonic.net> Hello, I am a total n00b with OpenGL, and still very new to Qt/pyside as well, so this question is very basic, but every time I dive into the documentation I go down a rabbit hole and get lost in the sheer mass of it. I am trying to modify the hellogl.py example found here: http://qt.gitorious.org/pyside/pyside-examples/blobs/master/examples/opengl/hellogl.py My geometry is coming from a new Python module called pyPolyCSG https://github.com/jamesgregson/pyPolyCSG which does constructive solid geometry. My goal is to create a mesh using pyPolyCSG, and render that in place of the Qt logo in the hellogl example. pyPolyCSG has these methods for extracting geometry: obj.get_vertices() - returns vertex coordinates as a 2D numpy array obj.get_triangles() - temporarily triangulates the mesh and returns a 2D numpy array of triangle vertex ids and so I have gotten as far as creating nice numpy arrays of vertices and triangles of the object I want to render. And of course, I can easily gut out the Qt logo construction code from hellogl.py :) My problem is that I just can't seem to connect the dots here... given that I have a nice batch of vertices and triangles, how can I get that hooked up to OpenGL rendering? Thanks, Dave From Zhu.Zhong at alcatel-sbell.com.cn Thu Nov 15 08:04:05 2012 From: Zhu.Zhong at alcatel-sbell.com.cn (ZHONG Zhu) Date: Thu, 15 Nov 2012 07:04:05 +0000 Subject: [PySide] where to find the user guide for Shiboken Message-ID: hi, I'm trying to use Shiboken to wrap my shared library file (.dll file, on WindowsXP, based on Qt) with Shiboken. But seems there's not enough guide on the qt site. Can anyone point me to the right web page? Thanks! BR, Zhu -------------- EasyTest (Alcatel-Lucent automation test tool) NOW FREE on internet at https://github.com/EasyTest2012/EasyTest -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpe at wingware.com Thu Nov 15 23:52:06 2012 From: jpe at wingware.com (John Ehresman) Date: Thu, 15 Nov 2012 17:52:06 -0500 Subject: [PySide] Problems with QStyle deletion Message-ID: <50A57216.5090700@wingware.com> I'm trying to fix a bug that causes segfaults if QApplication.style() and QApplication.setStyle() are used repeatedly. I think the issue is: 1) a PyObject* is created for the QStyle* returned by style() and its shiboken parent is set to the global app which adds 1 to the refcount 2) the next call to setStyle delete's the C++ QStyle but the PyObject* remains in the binding map 3) at some future point, another C++ object is created with the same address as the first QStyle* and unpredictable errors occur if the new C++ object is not a QStyle I was expecting pyside to connect to the destroyed signal (QStyle is a QObject) and for the PyObject* to be removed from the binding map when the QStyle is deleted, but that couldn't see that happening when I stepped through the QObject destructor. Any hints of how to fix this would be appreciated. Thanks, John From tismer at stackless.com Sat Nov 17 01:11:57 2012 From: tismer at stackless.com (Christian Tismer) Date: Sat, 17 Nov 2012 01:11:57 +0100 Subject: [PySide] setup.py patch for OS X Message-ID: Hi guys, I did not understand why pip never worked on OS X until I looked into the source which just treats the non-windows world as being linux. So I wrote a patch that added the few missing bits to make setup.py and pyside_postinstall.py work correctly under mac os x. I would like to contribute this to pyside and would like to know how/where to submit the patch. In any case, I will make those changes available as a pyside sub-project of pydica, tomorrow. http://bitbucket.org/pydica/pyside Cheers - chris mailto:tismer at stackless.com Sent from my Ei4Steve From backup.rlacko at gmail.com Mon Nov 19 15:39:43 2012 From: backup.rlacko at gmail.com (Roman Lacko) Date: Mon, 19 Nov 2012 15:39:43 +0100 Subject: [PySide] setup.py patch for OS X In-Reply-To: References: Message-ID: Hi Christian, thanks for patch. Here is another patch for mac OSX provided by Matthew Bratt [1]. I will merge Matthew's patch and than we can review your changes. Regards Roman [1] https://github.com/PySide/pyside-setup/pull/3 2012/11/17 Christian Tismer > Hi guys, > > I did not understand why pip never worked on OS X until I looked into > the source which just treats the non-windows world as being linux. > > So I wrote a patch that added the few missing bits to make setup.py and > pyside_postinstall.py work correctly under mac os x. > > I would like to contribute this to pyside and would like to know how/where > to > submit the patch. > > In any case, I will make those changes available as a pyside sub-project > of pydica, tomorrow. > > http://bitbucket.org/pydica/pyside > > Cheers - chris > > mailto:tismer at stackless.com > > Sent from my Ei4Steve > _______________________________________________ > 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 tismer at stackless.com Mon Nov 19 23:30:16 2012 From: tismer at stackless.com (Christian Tismer) Date: Mon, 19 Nov 2012 23:30:16 +0100 Subject: [PySide] setup.py patch for OS X In-Reply-To: References: Message-ID: <50AAB2F8.1060202@stackless.com> Hi Roman, thank *you* for the Mac patch. It is much better developed than mine. I tried to make the minimum changes, so I will rewrite my stuff on top of Matthews version, which is a real improvement. The main difference is that my setup version works with Homebrew, which the patched version does not. I think to rewrite things a bit more to probe how Qt was created, and hopefully support the --standalone option. I'll be back then - ciao -- Chris On 11/19/12 3:39 PM, Roman Lacko wrote: > Hi Christian, > > thanks for patch. > > Here is another patch for mac OSX provided by Matthew Bratt [1]. > I will merge Matthew's patch and than we can review your changes. > > Regards > Roman > > [1] https://github.com/PySide/pyside-setup/pull/3 > > 2012/11/17 Christian Tismer > > > Hi guys, > > I did not understand why pip never worked on OS X until I looked into > the source which just treats the non-windows world as being linux. > > So I wrote a patch that added the few missing bits to make > setup.py and > pyside_postinstall.py work correctly under mac os x. > > I would like to contribute this to pyside and would like to know > how/where to > submit the patch. > > In any case, I will make those changes available as a pyside > sub-project > of pydica, tomorrow. > > http://bitbucket.org/pydica/pyside > > Cheers - chris > > mailto:tismer at stackless.com > > Sent from my Ei4Steve > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > > -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tismer at stackless.com Tue Nov 20 02:10:57 2012 From: tismer at stackless.com (Christian Tismer) Date: Tue, 20 Nov 2012 02:10:57 +0100 Subject: [PySide] setup.py patch for OS X In-Reply-To: <50AAB2F8.1060202@stackless.com> References: <50AAB2F8.1060202@stackless.com> Message-ID: <50AAD8A1.5010700@stackless.com> Hi again, Install-hell hits me again. :-( I uninstalled my homebrew version and tried to make sure that the new version from Matthew Bratt works for me. But it doesn't. I used his version of setup.py after removal and installing of Qt 4.8.3 into /Library/Frameworks and /Developer/Qt/Applications as the default is. No changes to any path related stuff in ~/.profile . When trying the build (on OS X 10.8.2), I get the following error: > Linking CXX executable shiboken > ld: framework not found QtCore > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make[2]: *** [generator/shiboken] Error 1 > make[1]: *** [generator/CMakeFiles/shiboken.dir/all] Error 2 > make: *** [all] Error 2 > error: Error compiling shiboken > (pydica)minimax:PySide-1.1.2 tismer$ This is actually the very same problem that hit me since days and made me try Homebrew, which admittedly has its other shortcomings. /Library/Frameworks is on the path, and QtCore can be seen from there. Can somebody enlighten me what's wrong here? The patched setup.py should work on a standard installation, before I try to improve it and make it more flexible. Is that due to the fact that Matt uses OS X 10.6, as I think to recall? Or is ist an issue to use the shiboken module from Homebrew, as I did here? In any case, this should really not matter if things are in shape. cheers - Chris On 19.11.12 23:30, Christian Tismer wrote: > Hi Roman, > > thank *you* for the Mac patch. It is much better developed than > mine. I tried to make the minimum changes, so I will rewrite my > stuff on top of Matthews version, which is a real improvement. > > The main difference is that my setup version works with Homebrew, > which the patched version does not. > I think to rewrite things a bit more to probe how Qt was created, > and hopefully support the --standalone option. > > I'll be back then - > > ciao -- Chris > > > On 11/19/12 3:39 PM, Roman Lacko wrote: >> Hi Christian, >> >> thanks for patch. >> >> Here is another patch for mac OSX provided by Matthew Bratt [1]. >> I will merge Matthew's patch and than we can review your changes. >> >> Regards >> Roman >> >> [1] https://github.com/PySide/pyside-setup/pull/3 >> >> 2012/11/17 Christian Tismer > > >> >> Hi guys, >> >> I did not understand why pip never worked on OS X until I looked into >> the source which just treats the non-windows world as being linux. >> >> So I wrote a patch that added the few missing bits to make >> setup.py and >> pyside_postinstall.py work correctly under mac os x. >> >> I would like to contribute this to pyside and would like to know >> how/where to >> submit the patch. >> >> In any case, I will make those changes available as a pyside >> sub-project >> of pydica, tomorrow. >> >> http://bitbucket.org/pydica/pyside >> >> Cheers - chris >> >> mailto:tismer at stackless.com >> >> Sent from my Ei4Steve >> _______________________________________________ >> PySide mailing list >> PySide at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/pyside >> >> > > > -- > Christian Tismer :^) > Software Consulting : Have a break! Take a ride on Python's > Karl-Liebknecht-Str. 121 : *Starship*http://starship.python.net/ > 14482 Potsdam : PGP key ->http://pgp.uni-mainz.de > phone +49 173 24 18 776 fax +49 (30) 700143-0023 > PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 > whom do you want to sponsor today?http://www.stackless.com/ > > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Tue Nov 20 03:09:00 2012 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 19 Nov 2012 18:09:00 -0800 Subject: [PySide] setup.py patch for OS X In-Reply-To: <50AAD8A1.5010700@stackless.com> References: <50AAB2F8.1060202@stackless.com> <50AAD8A1.5010700@stackless.com> Message-ID: Hi, On Mon, Nov 19, 2012 at 5:10 PM, Christian Tismer wrote: > Hi again, > > Install-hell hits me again. :-( > > I uninstalled my homebrew version and tried to make sure that > the new version from Matthew Bratt works for me. But it doesn't. > > I used his version of setup.py after removal and installing > of Qt 4.8.3 into /Library/Frameworks and /Developer/Qt/Applications > as the default is. > > No changes to any path related stuff in ~/.profile . > > When trying the build (on OS X 10.8.2), I get the following error: > > Linking CXX executable shiboken > ld: framework not found QtCore > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make[2]: *** [generator/shiboken] Error 1 > make[1]: *** [generator/CMakeFiles/shiboken.dir/all] Error 2 > make: *** [all] Error 2 > error: Error compiling shiboken > (pydica)minimax:PySide-1.1.2 tismer$ > > > This is actually the very same problem that hit me since days and made me > try Homebrew, > which admittedly has its other shortcomings. > /Library/Frameworks is on the path, and QtCore can be seen from there. > > Can somebody enlighten me what's wrong here? > The patched setup.py should work on a standard installation, before I try to > improve it and make it more flexible. > Is that due to the fact that Matt uses OS X 10.6, as I think to recall? Yes, that's right - I'm on 10.6 on a couple of boxes, but I have a 10.7 - I'll give it a try. It would be very good to get it working across the standard setups. Cheers, Matthew From tismer at stackless.com Tue Nov 20 22:53:54 2012 From: tismer at stackless.com (Christian Tismer) Date: Tue, 20 Nov 2012 22:53:54 +0100 Subject: [PySide] setup.py patch for OS X In-Reply-To: References: <50AAB2F8.1060202@stackless.com> <50AAD8A1.5010700@stackless.com> Message-ID: <89E84B49-95A1-45F9-BDAB-56F1AA258A6B@stackless.com> Hi Matt, Sent from my Ei4Steve On Nov 20, 2012, at 3:09, Matthew Brett wrote: > Hi, > > On Mon, Nov 19, 2012 at 5:10 PM, Christian Tismer wrote: >> Hi again, >> >> Install-hell hits me again. :-( >> >> I uninstalled my homebrew version and tried to make sure that >> the new version from Matthew Bratt works for me. But it doesn't. >> >> I used his version of setup.py after removal and installing >> of Qt 4.8.3 into /Library/Frameworks and /Developer/Qt/Applications >> as the default is. >> >> No changes to any path related stuff in ~/.profile . >> >> When trying the build (on OS X 10.8.2), I get the following error: >> >> Linking CXX executable shiboken >> ld: framework not found QtCore >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> make[2]: *** [generator/shiboken] Error 1 >> make[1]: *** [generator/CMakeFiles/shiboken.dir/all] Error 2 >> make: *** [all] Error 2 >> error: Error compiling shiboken >> (pydica)minimax:PySide-1.1.2 tismer$ >> >> >> This is actually the very same problem that hit me since days and made me >> try Homebrew, >> which admittedly has its other shortcomings. >> /Library/Frameworks is on the path, and QtCore can be seen from there. >> >> Can somebody enlighten me what's wrong here? >> The patched setup.py should work on a standard installation, before I try to >> improve it and make it more flexible. >> Is that due to the fact that Matt uses OS X 10.6, as I think to recall? > > Yes, that's right - I'm on 10.6 on a couple of boxes, but I have a > 10.7 - I'll give it a try. > > It would be very good to get it working across the standard setups. Good news: Your installer works as is on Mountain Lion !! The only problem was cmake 2.8.10.1 installed by homebrew. I actually found a hint on gmane that was actually from you :-) (earlier this year). Downgrading cmake to 2.8.9 did the trick. Maybe we need to add a version check that prevends the trouble I had with this. I think of black-listing versions that do not work. Cheers - chris From matthew.brett at gmail.com Wed Nov 21 01:14:23 2012 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 20 Nov 2012 16:14:23 -0800 Subject: [PySide] setup.py patch for OS X In-Reply-To: <89E84B49-95A1-45F9-BDAB-56F1AA258A6B@stackless.com> References: <50AAB2F8.1060202@stackless.com> <50AAD8A1.5010700@stackless.com> <89E84B49-95A1-45F9-BDAB-56F1AA258A6B@stackless.com> Message-ID: Hi, On Tue, Nov 20, 2012 at 1:53 PM, Christian Tismer wrote: > Hi Matt, > > Sent from my Ei4Steve > > On Nov 20, 2012, at 3:09, Matthew Brett wrote: > >> Hi, >> >> On Mon, Nov 19, 2012 at 5:10 PM, Christian Tismer wrote: >>> Hi again, >>> >>> Install-hell hits me again. :-( >>> >>> I uninstalled my homebrew version and tried to make sure that >>> the new version from Matthew Bratt works for me. But it doesn't. >>> >>> I used his version of setup.py after removal and installing >>> of Qt 4.8.3 into /Library/Frameworks and /Developer/Qt/Applications >>> as the default is. >>> >>> No changes to any path related stuff in ~/.profile . >>> >>> When trying the build (on OS X 10.8.2), I get the following error: >>> >>> Linking CXX executable shiboken >>> ld: framework not found QtCore >>> clang: error: linker command failed with exit code 1 (use -v to see >>> invocation) >>> make[2]: *** [generator/shiboken] Error 1 >>> make[1]: *** [generator/CMakeFiles/shiboken.dir/all] Error 2 >>> make: *** [all] Error 2 >>> error: Error compiling shiboken >>> (pydica)minimax:PySide-1.1.2 tismer$ >>> >>> >>> This is actually the very same problem that hit me since days and made me >>> try Homebrew, >>> which admittedly has its other shortcomings. >>> /Library/Frameworks is on the path, and QtCore can be seen from there. >>> >>> Can somebody enlighten me what's wrong here? >>> The patched setup.py should work on a standard installation, before I try to >>> improve it and make it more flexible. >>> Is that due to the fact that Matt uses OS X 10.6, as I think to recall? >> >> Yes, that's right - I'm on 10.6 on a couple of boxes, but I have a >> 10.7 - I'll give it a try. >> >> It would be very good to get it working across the standard setups. > > Good news: > Your installer works as is on Mountain Lion !! > > The only problem was cmake 2.8.10.1 installed by homebrew. > > I actually found a hint on gmane that was actually from you :-) (earlier this year). Oh - really - 2.8.10.1 busted? I thought they had fixed the bug in 2.8.10.1 - any chance of reporting back to the cmake guys on the list? > Downgrading cmake to 2.8.9 did the trick. > Maybe we need to add a version check that prevends the trouble I had with this. > I think of black-listing versions that do not work. I was hoping it was just 2.8.10 that was bust - but if the current version is bust, yes, we probably ought to check... Best, Matthew From dthomas at willowgarage.com Wed Nov 21 13:26:54 2012 From: dthomas at willowgarage.com (Dirk Thomas) Date: Wed, 21 Nov 2012 13:26:54 +0100 Subject: [PySide] Regression with QGenericReturnArgument (with patch/workaround) Message-ID: <50ACC88E.4020604@willowgarage.com> I have sent a message to the mailing list [1] and filled an issue [2] regarding a regression with QGenericReturnArgument months ago. Since 1.1.0 headers containing QGenericReturnArgument parameters no longer work. It was working with 1.0.6 (other versions in between not checked). The reported issue has a simple-to-apply workaround. Please take a closer look and apply this patch for the next patch release. - Dirk [1] http://lists.qt-project.org/pipermail/pyside/2012-June/000536.html [2] https://bugreports.qt-project.org/browse/PYSIDE-76 From tismer at stackless.com Wed Nov 21 22:13:36 2012 From: tismer at stackless.com (Christian Tismer) Date: Wed, 21 Nov 2012 22:13:36 +0100 Subject: [PySide] setup.py patch for OS X In-Reply-To: References: <50AAB2F8.1060202@stackless.com> <50AAD8A1.5010700@stackless.com> <89E84B49-95A1-45F9-BDAB-56F1AA258A6B@stackless.com> Message-ID: <50AD4400.5070803@stackless.com> Hi Matt, On 11/21/12 1:14 AM, Matthew Brett wrote: ... >> Good news: >> Your installer works as is on Mountain Lion !! >> >> The only problem was cmake 2.8.10.1 installed by homebrew. >> >> I actually found a hint on gmane that was actually from you :-) (earlier this year). > Oh - really - 2.8.10.1 busted? I thought they had fixed the bug in > 2.8.10.1 - any chance of reporting back to the cmake guys on the list? I am not on this list, and I'm not sure if I should go this far. Honestly, this install problem is becoming quite a lot for me. I don't think I want to become also a cmake developer ;-) Is there anybody on the cmake mailing list who could pls. do that? Simply reporting that 2.8.10.1 has the same problem as 2.8.10 concerning QtCore library not found? >> Downgrading cmake to 2.8.9 did the trick. >> Maybe we need to add a version check that prevends the trouble I had with this. >> I think of black-listing versions that do not work. > I was hoping it was just 2.8.10 that was bust - but if the current > version is bust, yes, we probably ought to check... Ok, I think I will put a check into setup.py with some comment. There are more problems, see next post ;-) cheers - Chris -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From tismer at stackless.com Thu Nov 22 00:08:09 2012 From: tismer at stackless.com (Christian Tismer) Date: Thu, 22 Nov 2012 00:08:09 +0100 Subject: [PySide] cmake OS X setup.py pyside-tools Message-ID: <50AD5ED9.20405@stackless.com> Hi again, while testing Matt's setup.py on a standard Qt 4.8.3 install (which works great on a fresh Mountain Lion), I encountered another quirk: When building with a used developer machine (a pyside 1.1.0 was still lingering around in the system Python), this happens: After building for a long time, pyside-tools gets compiled, and that crashes, because cmake now finds pyside 1.1.0 . I compared the CMakeCache.txt files to find that out. The reason is simple: The macro CMakeLists.txt simply checks find_package(PySide 1.0.6 REQUIRED) which is not a really good idea: After building pyside correctly, this is also the pyside that we want to build pyside-tools for, not anything that happens to be installed elsewhere. I'm wondering how this should be fixed: In the case of building pyside-tools right after pyside, things are clear: the built version should be used. But in the general case (building pyside-tools alone, it gets more tricky. It is not neccessarily the same python that builds as the one that installs, right? Do you think it would be sufficient to patch pyside-tools/CMakeLists.txt simply to require the exact version that was just built, or that is installed in site-packages? What would be "the right thing (TM)" ? cheers - chris -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From tismer at stackless.com Fri Nov 23 01:55:49 2012 From: tismer at stackless.com (Christian Tismer) Date: Fri, 23 Nov 2012 01:55:49 +0100 Subject: [PySide] cmake OS X setup.py pyside-tools In-Reply-To: <50AD5ED9.20405@stackless.com> References: <50AD5ED9.20405@stackless.com> Message-ID: <50AEC995.2000005@stackless.com> Hi, solved this issue. On 22.11.12 00:08, Christian Tismer wrote: > Hi again, > > while testing Matt's setup.py on a standard Qt 4.8.3 install > (which works great on a fresh Mountain Lion), I encountered > another quirk: > > When building with a used developer machine (a pyside 1.1.0 was still > lingering around in the system Python), this happens: > > After building for a long time, pyside-tools gets compiled, and that > crashes, because cmake now finds pyside 1.1.0 . > > I compared the CMakeCache.txt files to find that out. > The reason is simple: > The macro CMakeLists.txt simply checks > > find_package(PySide 1.0.6 REQUIRED) > > which is not a really good idea: > After building pyside correctly, this is also the pyside that we > want to build pyside-tools for, not anything that happens to be > installed elsewhere. > > I'm wondering how this should be fixed: > In the case of building pyside-tools right after pyside, things are > clear: the built version should be used. > > But in the general case (building pyside-tools alone, it gets > more tricky. It is not neccessarily the same python that builds > as the one that installs, right? > > Do you think it would be sufficient to patch pyside-tools/CMakeLists.txt > simply to require the exact version that was just built, or that is > installed in site-packages? > > What would be "the right thing (TM)" ? > > cheers - chris > pyside-tools is not configured correctly and contradicts the settings in setup.py. I think the following changes are necessary: > diff --git a/CMakeLists.txt b/CMakeLists.txt > index 1d609d7..9fa3169 100644 > --- a/CMakeLists.txt > +++ b/CMakeLists.txt > @@ -3,8 +3,8 @@ cmake_minimum_required(VERSION 2.6) > project(pyside-tools) > > find_package(PythonInterp REQUIRED) > -find_package(Qt4 4.5.0 REQUIRED) > -find_package(PySide 1.0.6 REQUIRED) > +find_package(Qt4 4.6.0 REQUIRED) > +find_package(PySide 1.1.1 REQUIRED) > > set(pyside_tools_MAJOR_VERSION "0") > set(pyside_tools_MINOR_VERSION "2") -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From mardy at users.sourceforge.net Fri Nov 23 18:42:37 2012 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Fri, 23 Nov 2012 19:42:37 +0200 Subject: [PySide] Enums in Python wrapper for a Qt-base library Message-ID: <50AFB58D.90206@users.sourceforge.net> Hi all! I've one Qt-base library, let's call it libabc.so, and I want to make a PyABC python wrapper for it. All the libabc API is contained in a namespace, called "ABC". Now, when I generate the bindings, I'm using a typesystem file like this: =========================== =========================== I've set the 'generate="no"' attribute on the namespace, otherwise all classes are only accessible as PyABC.ABC.. This works well, except for the enums. For some reason, the enum values are accessible in three different ways: 1) PyABC.ABC.ImageType.Value1 2) PyABC.ImageType.Value1 3) PyABC.Value1 where the first one seems to be the canonical one; that is, if I run a python interpreter and import the PyABC module, and then type "PyABC.Value1" on the prompt, it types back "PyABC.ABC.ImageType.Value1". Is there a way to have the enum values being exported in the second form only (that is, PyABC.ImageType.Value1)? Or at least, is there a way to make the 3rd form unavailable, as it's just polluting the module namespace? TIA, Alberto -- http://blog.mardy.it <- geek in un lingua international! From techtonik at gmail.com Sat Nov 24 01:03:01 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Sat, 24 Nov 2012 03:03:01 +0300 Subject: [PySide] Regression with QGenericReturnArgument (with patch/workaround) In-Reply-To: <50ACC88E.4020604@willowgarage.com> References: <50ACC88E.4020604@willowgarage.com> Message-ID: IIRC the patches should go through - https://codereview.qt-project.org/ -- anatoly t. On Wed, Nov 21, 2012 at 3:26 PM, Dirk Thomas wrote: > I have sent a message to the mailing list [1] and filled an issue [2] > regarding a regression with QGenericReturnArgument months ago. > Since 1.1.0 headers containing QGenericReturnArgument parameters no longer > work. > It was working with 1.0.6 (other versions in between not checked). > > The reported issue has a simple-to-apply workaround. > Please take a closer look and apply this patch for the next patch release. > > - Dirk > > [1] http://lists.qt-project.org/pipermail/pyside/2012-June/000536.html > [2] https://bugreports.qt-project.org/browse/PYSIDE-76 > _______________________________________________ > 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 dthomas at willowgarage.com Mon Nov 26 12:25:55 2012 From: dthomas at willowgarage.com (Dirk Thomas) Date: Mon, 26 Nov 2012 12:25:55 +0100 Subject: [PySide] Regression with QGenericReturnArgument (with patch/workaround) In-Reply-To: References: <50ACC88E.4020604@willowgarage.com> Message-ID: <50B351C3.3010606@willowgarage.com> I thought filling a bug report with a test case and patch in JIRA is the official way. Could you please point me to some doc mentioning how to get the proposed patch into the mentioned codereview system? Thank you, - Dirk On 24.11.2012 01:03, anatoly techtonik wrote: > IIRC the patches should go through - https://codereview.qt-project.org/ > > -- > anatoly t. > > > On Wed, Nov 21, 2012 at 3:26 PM, Dirk Thomas > wrote: > > I have sent a message to the mailing list [1] and filled an issue [2] regarding a regression with QGenericReturnArgument months ago. > Since 1.1.0 headers containing QGenericReturnArgument parameters no longer work. > It was working with 1.0.6 (other versions in between not checked). > > The reported issue has a simple-to-apply workaround. > Please take a closer look and apply this patch for the next patch release. > > - Dirk > > [1] http://lists.qt-project.org/pipermail/pyside/2012-June/000536.html > [2] https://bugreports.qt-project.org/browse/PYSIDE-76 > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > > From techtonik at gmail.com Mon Nov 26 12:49:02 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Mon, 26 Nov 2012 14:49:02 +0300 Subject: [PySide] Regression with QGenericReturnArgument (with patch/workaround) In-Reply-To: <50B351C3.3010606@willowgarage.com> References: <50ACC88E.4020604@willowgarage.com> <50B351C3.3010606@willowgarage.com> Message-ID: On Mon, Nov 26, 2012 at 2:25 PM, Dirk Thomas wrote: > I thought filling a bug report with a test case and patch in JIRA is the > official way. > > Could you please point me to some doc mentioning how to get the proposed > patch into the mentioned codereview system? > PySide is now a Qt Project, so everything said here applies: http://qt-project.org/wiki/Code_Reviews However, a more direct pointer (?tutorial) based on your experience will be appreciated on http://qt-project.org/wiki/PySide page. -- anatoly t. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dthomas at willowgarage.com Mon Nov 26 14:22:01 2012 From: dthomas at willowgarage.com (Dirk Thomas) Date: Mon, 26 Nov 2012 14:22:01 +0100 Subject: [PySide] Regression with QGenericReturnArgument (with patch/workaround) In-Reply-To: References: <50ACC88E.4020604@willowgarage.com> <50B351C3.3010606@willowgarage.com> Message-ID: <50B36CF9.8010202@willowgarage.com> Thank you for pointing me to the right docs. With this help I got the patch into Gerrit. https://codereview.qt-project.org/#change,40645 Lets see what will happen from there... - Dirk On 26.11.2012 12:49, anatoly techtonik wrote: > On Mon, Nov 26, 2012 at 2:25 PM, Dirk Thomas > wrote: > > I thought filling a bug report with a test case and patch in JIRA is the official way. > > Could you please point me to some doc mentioning how to get the proposed patch into the mentioned codereview system? > > > PySide is now a Qt Project, so everything said here applies: > http://qt-project.org/wiki/Code_Reviews > > However, a more direct pointer (?tutorial) based on your experience will be appreciated on http://qt-project.org/wiki/PySide page. > -- > anatoly t. From jpe at wingware.com Mon Nov 26 19:49:37 2012 From: jpe at wingware.com (John Ehresman) Date: Mon, 26 Nov 2012 13:49:37 -0500 Subject: [PySide] Problems with QStyle deletion In-Reply-To: <50A57216.5090700@wingware.com> References: <50A57216.5090700@wingware.com> Message-ID: <50B3B9C1.80401@wingware.com> On 11/15/12 5:52 PM, John Ehresman wrote: > I'm trying to fix a bug that causes segfaults if QApplication.style() > and QApplication.setStyle() are used repeatedly. I think the issue is: > > 1) a PyObject* is created for the QStyle* returned by style() and its > shiboken parent is set to the global app which adds 1 to the refcount > > 2) the next call to setStyle delete's the C++ QStyle but the PyObject* > remains in the binding map > > 3) at some future point, another C++ object is created with the same > address as the first QStyle* and unpredictable errors occur if the new > C++ object is not a QStyle I've been looking further into this and am wondering why either the destroyed signal and/or QWeakPointer are not used. Is there a reason why they're not used? Thanks, John From vihorev at gmail.com Mon Nov 26 19:54:28 2012 From: vihorev at gmail.com (Alexey Vihorev) Date: Mon, 26 Nov 2012 20:54:28 +0200 Subject: [PySide] QObject.destroyed() is not emitted Message-ID: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> Hi! Got problems with the following code: from PySide import QtCore def onDestroy(*args): print('destroyed') obj = QtCore.QObject() obj.destroyed.connect(onDestroy) The onDestroy() method is not called, unless del(obj) is called explicitly. In PyQt4 it is called without del(obj). Is that a bug or intended behavior? I'm using Qt 4.8.2, PySide 1.1.2 32bit, Windows 7-64 Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khertan at khertan.net Tue Nov 27 18:56:42 2012 From: khertan at khertan.net (Benoit HERVIER) Date: Tue, 27 Nov 2012 17:56:42 +0000 Subject: [PySide] Security issue with <= 1.0.2-1maemo1+0m6 Message-ID: Hi, i m currently have try all workaround about a bug in version 1.0.2-1maemo1+0m6. i've found the bug report about it, but i m sure it was reported, was about qtextedit and qtextdocument which make python interpreter segfault. Anyway, this bug is fixed with more recent release, but i m in front of a problem : i can't update pyside as the target platform is harmattan, and the PySide packages are under protection of aegis, and Nokia will not push anymore update to Meego harmattan or maybe if we are lucky, just for security issues. So this why i ask here if there is any know security issues, so maybe this could force them to update it ... thanks in advance ... a devel feeling alone on a dead platform... -- Benoit HERVIER - http://khertan.net From khertan at khertan.net Tue Nov 27 18:56:42 2012 From: khertan at khertan.net (Benoit HERVIER) Date: Tue, 27 Nov 2012 17:56:42 +0000 Subject: [PySide] Security issue with <= 1.0.2-1maemo1+0m6 Message-ID: <1ll46n.me5rmv.2xwytm-qmf@mx.google.com> Hi, i m currently have try all workaround about a bug in version 1.0.2-1maemo1+0m6. i've found the bug report about it, but i m sure it was reported, was about qtextedit and qtextdocument which make python interpreter segfault. Anyway, this bug is fixed with more recent release, but i m in front of a problem : i can't update pyside as the target platform is harmattan, and the PySide packages are under protection of aegis, and Nokia will not push anymore update to Meego harmattan or maybe if we are lucky, just for security issues. So this why i ask here if there is any know security issues, so maybe this could force them to update it ... thanks in advance ... a devel feeling alone on a dead platform... -- Benoit HERVIER - http://khertan.net From hugo.lima at openbossa.org Tue Nov 27 19:10:36 2012 From: hugo.lima at openbossa.org (Hugo Parente Lima) Date: Tue, 27 Nov 2012 15:10:36 -0300 Subject: [PySide] Security issue with <= 1.0.2-1maemo1+0m6 In-Reply-To: References: Message-ID: <2555452.i5XpOYKHCJ@hugodesktop> On Tuesday, November 27, 2012 05:56:42 PM Benoit HERVIER wrote: > Hi, > > i m currently have try all workaround about a bug in version > 1.0.2-1maemo1+0m6. i've found the bug report about it, but i m sure it was > reported, was about qtextedit and qtextdocument which make python > interpreter segfault. > > Anyway, this bug is fixed with more recent release, but i m in front of a > problem : i can't update pyside as the target platform is harmattan, and > the PySide packages are under protection of aegis, and Nokia will not push > anymore update to Meego harmattan or maybe if we are lucky, just for > security issues. > > So this why i ask here if there is any know security issues, so maybe this > could force them to update it ... > > thanks in advance ... > a devel feeling alone on a dead platform... :-(, there's nothing we can do. > -- > Benoit HERVIER - http://khertan.net > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From Zhu.Zhong at alcatel-sbell.com.cn Wed Nov 28 09:40:17 2012 From: Zhu.Zhong at alcatel-sbell.com.cn (ZHONG Zhu) Date: Wed, 28 Nov 2012 08:40:17 +0000 Subject: [PySide] PySide_Binding_Generation_Tutorial In-Reply-To: <2555452.i5XpOYKHCJ@hugodesktop> References: <2555452.i5XpOYKHCJ@hugodesktop> Message-ID: I'm new to Pyside and I was trying to follow this tutorial to generate a binding but always have problem finish the last step http://qt-project.org/wiki/PySide_Binding_Generation_Tutorial%3A_Module_5_Building_the_generator There are always errors like below. Anyone can help me on this? I'm working on WindowsXP with Qt4.8.1, Python27 and PySide1.1.2(installed through a binary installer). Thank you in advance! g++ -Wl,-s -mthreads -shared -Wl,--out-implib,release\libfoo.a -o release\foo.dll release/foo_module_wrapper.o release/ ath_wrapper.o -L"d:\Qt\4.8.1\lib" -LD:/Python27/libs -LD:/Python27/Lib/site-packages/PySide D:/Python27/libs/python27. ib D:/Python27/Lib/site-packages/PySide/pyside-python2.7.lib D:/Python27/lib/site-packages/PySide/shiboken-python2.7.li -LD:/binding-tutorial/libfoo -lfoo -lQtGui4 -lQtCore4 Info: resolving vtable for Math by linking to __imp___ZTV4Math (auto-import) Creating library file: release\libfoo.a d:/qtsdk/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated ithout --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs. release/foo_module_wrapper.o:foo_module_wrapper.cpp:(.text+0x63): undefined reference to `Shiboken::Conversions::conver ibleDictTypes(SbkConverter*, bool, SbkConverter*, bool, _object*)' release/foo_module_wrapper.o:foo_module_wrapper.cpp:(.text+0x90): undefined reference to `Shiboken::Conversions::conver ibleSequenceTypes(SbkConverter*, _object*)' release/foo_module_wrapper.o:foo_module_wrapper.cpp:(.text+0xbd): undefined reference to `Shiboken::Conversions::conver ibleSequenceTypes(SbkConverter*, _object*)' release/foo_module_wrapper.o:foo_module_wrapper.cpp:(.text+0x149): undefined reference to `Shiboken::Conversions::copyT Python(SbkConverter*, void const*)' release/foo_module_wrapper.o:foo_module_wrapper.cpp:(.text+0x2e8): undefined reference to `Shiboken::Conversions::copyT Python(SbkConverter*, void const*)' release/foo_module_wrapper.o:foo_module_wrapper.cpp:(.text+0x3b9): undefined reference to `Shiboken::Conversions::pytho ToCppCopy(SbkConverter*, _object*, void*)' release/foo_module_wrapper.o:foo_module_wrapper.cpp:(.text+0x44d): undefined reference to `Shiboken::Module::import(cha From sdeibel at wingware.com Wed Nov 28 15:33:23 2012 From: sdeibel at wingware.com (Stephan Deibel) Date: Wed, 28 Nov 2012 09:33:23 -0500 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> Message-ID: <50B620B3.9050208@wingware.com> Alexey Vihorev wrote: > > Got problems with the following code: > > from PySide import QtCore > > def onDestroy(*args): > > print('destroyed') > > obj = QtCore.QObject() > > obj.destroyed.connect(onDestroy) > > The onDestroy() method is not called, unless del(obj) is called > explicitly. In PyQt4 it is called without del(obj). Is that a bug or > intended behavior? I’m using Qt 4.8.2, PySide 1.1.2 32bit, Windows 7-64 > Since no one responded I'll take a stab at this: I suspect the life cycle of the QObject under PySide is a little different and the instance will be deleted later during garbage collection and not immediately when it goes out of scope. I'm actually not sure why that is happening in PyQt (seems slightly surprising). In general if you want to make sure an instance is deleted at a particular moment in time, you need to delete it explicitly. By that, I mean calling some sort of delete method (in PySide I think it's shiboken.delete(obj) and not just "del obj". The latter just deletes your reference to the instance but doesn't destroy the instance until all other references are gone and it is garbage collected. Of course calling shiboken.delete(obj) will be a problem if you still have other references and try to use them! There is also obj.deleteLater() which marks an object for deletion but it's not deleted until the event loop is reached again. Depending on what you're doing this may be a safer way to delete it. At first I thought this might be a refcount bug in PySide. However, I'm thinking not since "del obj" just deletes your reference to it and if there were extra references hanging around (either on purpose or as a result of a refcount bug) then it would not be deleting the instance at all even after "del obj". I don't understand PySide internals that well so it's possible I'm missing some subtlety here. I'm going more on my knowledge of Python in general. - Stephan From felix.morency at gmail.com Wed Nov 28 15:37:18 2012 From: felix.morency at gmail.com (=?UTF-8?Q?F=C3=A9lix_C=2E_Morency?=) Date: Wed, 28 Nov 2012 09:37:18 -0500 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <50B620B3.9050208@wingware.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> Message-ID: Hi, I've seen this before. Try a throw instead of a print and see if its called. Also, try to del your object as Stephan mentioned. -F On Wed, Nov 28, 2012 at 9:33 AM, Stephan Deibel wrote: > Alexey Vihorev wrote: > > > > Got problems with the following code: > > > > from PySide import QtCore > > > > def onDestroy(*args): > > > > print('destroyed') > > > > obj = QtCore.QObject() > > > > obj.destroyed.connect(onDestroy) > > > > The onDestroy() method is not called, unless del(obj) is called > > explicitly. In PyQt4 it is called without del(obj). Is that a bug or > > intended behavior? I’m using Qt 4.8.2, PySide 1.1.2 32bit, Windows 7-64 > > > > Since no one responded I'll take a stab at this: > > I suspect the life cycle of the QObject under PySide is a little > different and the instance will be deleted later during garbage > collection and not immediately when it goes out of scope. I'm actually > not sure why that is happening in PyQt (seems slightly surprising). > > In general if you want to make sure an instance is deleted at a > particular moment in time, you need to delete it explicitly. By that, I > mean calling some sort of delete method (in PySide I think it's > shiboken.delete(obj) and not just "del obj". The latter just deletes > your reference to the instance but doesn't destroy the instance until > all other references are gone and it is garbage collected. Of course > calling shiboken.delete(obj) will be a problem if you still have other > references and try to use them! > > There is also obj.deleteLater() which marks an object for deletion but > it's not deleted until the event loop is reached again. Depending on > what you're doing this may be a safer way to delete it. > > At first I thought this might be a refcount bug in PySide. However, I'm > thinking not since "del obj" just deletes your reference to it and if > there were extra references hanging around (either on purpose or as a > result of a refcount bug) then it would not be deleting the instance at > all even after "del obj". > > I don't understand PySide internals that well so it's possible I'm > missing some subtlety here. I'm going more on my knowledge of Python in > general. > > - Stephan > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > -- -- Félix C. Morency, M.Sc. Plateforme d’analyse et de visualisation d’images Centre Hospitalier Universitaire de Sherbrooke Centre de recherche clinique Étienne-Le Bel Local Z5-3031 | 819.346.1110 ext 16634 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vihorev at gmail.com Wed Nov 28 21:24:55 2012 From: vihorev at gmail.com (Alexey Vihorev) Date: Wed, 28 Nov 2012 22:24:55 +0200 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <50B620B3.9050208@wingware.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> Message-ID: <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> Hi! Well, I understand that if what I need to do is achievable with explicit deletion, I should go for it :) The problem is that in my case the deletion of the object is triggered by deletion of another object - its parent. But I can't catch the deletion event - neither of the object nor its parent. That's the problem. The whole reason I started looking into that is that one of my objects needed to free some external resources when destroyed. -----Original Message----- From: Stephan Deibel [mailto:sdeibel at wingware.com] Sent: 28 ноября 2012 г. 16:33 To: Alexey Vihorev Cc: pyside at qt-project.org Subject: Re: [PySide] QObject.destroyed() is not emitted Alexey Vihorev wrote: > > Got problems with the following code: > > from PySide import QtCore > > def onDestroy(*args): > > print('destroyed') > > obj = QtCore.QObject() > > obj.destroyed.connect(onDestroy) > > The onDestroy() method is not called, unless del(obj) is called > explicitly. In PyQt4 it is called without del(obj). Is that a bug or > intended behavior? I'm using Qt 4.8.2, PySide 1.1.2 32bit, Windows > 7-64 > Since no one responded I'll take a stab at this: I suspect the life cycle of the QObject under PySide is a little different and the instance will be deleted later during garbage collection and not immediately when it goes out of scope. I'm actually not sure why that is happening in PyQt (seems slightly surprising). In general if you want to make sure an instance is deleted at a particular moment in time, you need to delete it explicitly. By that, I mean calling some sort of delete method (in PySide I think it's shiboken.delete(obj) and not just "del obj". The latter just deletes your reference to the instance but doesn't destroy the instance until all other references are gone and it is garbage collected. Of course calling shiboken.delete(obj) will be a problem if you still have other references and try to use them! There is also obj.deleteLater() which marks an object for deletion but it's not deleted until the event loop is reached again. Depending on what you're doing this may be a safer way to delete it. At first I thought this might be a refcount bug in PySide. However, I'm thinking not since "del obj" just deletes your reference to it and if there were extra references hanging around (either on purpose or as a result of a refcount bug) then it would not be deleting the instance at all even after "del obj". I don't understand PySide internals that well so it's possible I'm missing some subtlety here. I'm going more on my knowledge of Python in general. - Stephan From tismer at stackless.com Wed Nov 28 23:57:44 2012 From: tismer at stackless.com (Christian Tismer) Date: Wed, 28 Nov 2012 23:57:44 +0100 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> Message-ID: <50B696E8.6020102@stackless.com> Hi Alexey, I tried your example and added a parent. Right now it looks exactly as it should be: >>> def onDestroy(*args): ... print('destroyed') ... >>> obj = QtCore.QObject() >>> obj.destroyed.connect(onDestroy) True >>> par = QtCore.QObject() >>> obj.setParent(par) >>> del obj >>> del par destroyed >>> This is PySide on Mac OS X, >>> PySide.__version__ '1.1.2' >>> QtCore.__version__ '4.8.3' >>> Maybe you have some more references to the object? For simple refcount checking, you can use sys.getrefcount . >>> g=sys.getrefcount >>> g(obj) 2 Note that this prints 2 because of the reference from the call. So the object should go away when the one real reference goes away. Maybe you have a different problem, involving more objects? --------- By the way, PySide seems to be not happy with reference cycles, while pure python is ok with that: >>> obj = QtCore.QObject() >>> obj.setParent(obj) >>> g(obj) 2 Eeek, that should be 3. And if fact....... >>> del(obj) Segmentation fault: 11 ciao -- Chris On 11/28/12 9:24 PM, Alexey Vihorev wrote: > Hi! > Well, I understand that if what I need to do is achievable with explicit > deletion, I should go for it :) The problem is that in my case the deletion > of the object is triggered by deletion of another object - its parent. But I > can't catch the deletion event - neither of the object nor its parent. > That's the problem. The whole reason I started looking into that is that one > of my objects needed to free some external resources when destroyed. > > -----Original Message----- > From: Stephan Deibel [mailto:sdeibel at wingware.com] > Sent: 28 ноября 2012 г. 16:33 > To: Alexey Vihorev > Cc: pyside at qt-project.org > Subject: Re: [PySide] QObject.destroyed() is not emitted > > Alexey Vihorev wrote: >> Got problems with the following code: >> >> from PySide import QtCore >> >> def onDestroy(*args): >> >> print('destroyed') >> >> obj = QtCore.QObject() >> >> obj.destroyed.connect(onDestroy) >> >> The onDestroy() method is not called, unless del(obj) is called >> explicitly. In PyQt4 it is called without del(obj). Is that a bug or >> intended behavior? I'm using Qt 4.8.2, PySide 1.1.2 32bit, Windows >> 7-64 >> > Since no one responded I'll take a stab at this: > > I suspect the life cycle of the QObject under PySide is a little different > and the instance will be deleted later during garbage collection and not > immediately when it goes out of scope. I'm actually not sure why that is > happening in PyQt (seems slightly surprising). > > In general if you want to make sure an instance is deleted at a particular > moment in time, you need to delete it explicitly. By that, I mean calling > some sort of delete method (in PySide I think it's > shiboken.delete(obj) and not just "del obj". The latter just deletes your > reference to the instance but doesn't destroy the instance until all other > references are gone and it is garbage collected. Of course calling > shiboken.delete(obj) will be a problem if you still have other references > and try to use them! > > There is also obj.deleteLater() which marks an object for deletion but it's > not deleted until the event loop is reached again. Depending on what you're > doing this may be a safer way to delete it. > > At first I thought this might be a refcount bug in PySide. However, I'm > thinking not since "del obj" just deletes your reference to it and if there > were extra references hanging around (either on purpose or as a result of a > refcount bug) then it would not be deleting the instance at all even after > "del obj". > > I don't understand PySide internals that well so it's possible I'm missing > some subtlety here. I'm going more on my knowledge of Python in general. > > - Stephan > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From vihorev at gmail.com Thu Nov 29 04:26:47 2012 From: vihorev at gmail.com (Alexey Vihorev) Date: Thu, 29 Nov 2012 05:26:47 +0200 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <50B696E8.6020102@stackless.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> Message-ID: <000f01cdcde1$5dba2b70$192e8250$@gmail.com> Yes, I tried something like that: def onDestroy(*args): print('destroyed') obj = QtCore.QObject() obj.destroyed.connect(onDestroy) obj2 = QtCore.QObject(obj) obj2.destroyed.connect(onDestroy) del(obj) In this case onDestroy() is called twice, just as it should. But once again - omit the last line and nothing Is called. So for it to work explicit destruction must be called at the top of the chain. Which is problematic in my case. -----Original Message----- From: Christian Tismer [mailto:tismer at stackless.com] Sent: 29 ноября 2012 г. 0:58 To: Alexey Vihorev Cc: 'Stephan Deibel'; pyside at qt-project.org Subject: Re: [PySide] QObject.destroyed() is not emitted Hi Alexey, I tried your example and added a parent. Right now it looks exactly as it should be: >>> def onDestroy(*args): ... print('destroyed') ... >>> obj = QtCore.QObject() >>> obj.destroyed.connect(onDestroy) True >>> par = QtCore.QObject() >>> obj.setParent(par) >>> del obj >>> del par destroyed >>> This is PySide on Mac OS X, >>> PySide.__version__ '1.1.2' >>> QtCore.__version__ '4.8.3' >>> Maybe you have some more references to the object? For simple refcount checking, you can use sys.getrefcount . >>> g=sys.getrefcount >>> g(obj) 2 Note that this prints 2 because of the reference from the call. So the object should go away when the one real reference goes away. Maybe you have a different problem, involving more objects? --------- By the way, PySide seems to be not happy with reference cycles, while pure python is ok with that: >>> obj = QtCore.QObject() >>> obj.setParent(obj) >>> g(obj) 2 Eeek, that should be 3. And if fact....... >>> del(obj) Segmentation fault: 11 ciao -- Chris On 11/28/12 9:24 PM, Alexey Vihorev wrote: > Hi! > Well, I understand that if what I need to do is achievable with > explicit deletion, I should go for it :) The problem is that in my > case the deletion of the object is triggered by deletion of another > object - its parent. But I can't catch the deletion event - neither of the object nor its parent. > That's the problem. The whole reason I started looking into that is > that one of my objects needed to free some external resources when destroyed. > > -----Original Message----- > From: Stephan Deibel [mailto:sdeibel at wingware.com] > Sent: 28 ноября 2012 г. 16:33 > To: Alexey Vihorev > Cc: pyside at qt-project.org > Subject: Re: [PySide] QObject.destroyed() is not emitted > > Alexey Vihorev wrote: >> Got problems with the following code: >> >> from PySide import QtCore >> >> def onDestroy(*args): >> >> print('destroyed') >> >> obj = QtCore.QObject() >> >> obj.destroyed.connect(onDestroy) >> >> The onDestroy() method is not called, unless del(obj) is called >> explicitly. In PyQt4 it is called without del(obj). Is that a bug or >> intended behavior? I'm using Qt 4.8.2, PySide 1.1.2 32bit, Windows >> 7-64 >> > Since no one responded I'll take a stab at this: > > I suspect the life cycle of the QObject under PySide is a little > different and the instance will be deleted later during garbage > collection and not immediately when it goes out of scope. I'm actually > not sure why that is happening in PyQt (seems slightly surprising). > > In general if you want to make sure an instance is deleted at a > particular moment in time, you need to delete it explicitly. By that, > I mean calling some sort of delete method (in PySide I think it's > shiboken.delete(obj) and not just "del obj". The latter just deletes > your reference to the instance but doesn't destroy the instance until > all other references are gone and it is garbage collected. Of course > calling > shiboken.delete(obj) will be a problem if you still have other > references and try to use them! > > There is also obj.deleteLater() which marks an object for deletion but > it's not deleted until the event loop is reached again. Depending on > what you're doing this may be a safer way to delete it. > > At first I thought this might be a refcount bug in PySide. However, > I'm thinking not since "del obj" just deletes your reference to it and > if there were extra references hanging around (either on purpose or as > a result of a refcount bug) then it would not be deleting the instance > at all even after "del obj". > > I don't understand PySide internals that well so it's possible I'm > missing some subtlety here. I'm going more on my knowledge of Python in general. > > - Stephan > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From tismer at stackless.com Thu Nov 29 05:24:55 2012 From: tismer at stackless.com (Christian Tismer) Date: Thu, 29 Nov 2012 05:24:55 +0100 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <000f01cdcde1$5dba2b70$192e8250$@gmail.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> <000f01cdcde1$5dba2b70$192e8250$@gmail.com> Message-ID: <50B6E397.5070403@stackless.com> Alexey, there is not enough context to see your problem. The behavior in our similar examples is correct: Noting gets destroyed until we release the references from Python. As long as you have a reference, no destruction occurs. By the assignment obj = QtCore.Object(), you create a reference. You do not actively destroy the object by del ob but you just remove one reference. And because nothing else has a reference to it, _then_ the destruction takes place. The question is about the interaction with other objects. If everything is correct with PySide (which is certainly still not), then destruction should just work automatically when it's time. So please give us more of your code. We cannot see what the real problem is. cheers - chris On 29.11.12 04:26, Alexey Vihorev wrote: > Yes, I tried something like that: > > def onDestroy(*args): > print('destroyed') > > obj = QtCore.QObject() > obj.destroyed.connect(onDestroy) > > obj2 = QtCore.QObject(obj) > obj2.destroyed.connect(onDestroy) > > del(obj) > > In this case onDestroy() is called twice, just as it should. But once again > - omit the last line and nothing Is called. So for it to work explicit > destruction must be called at the top of the chain. Which is problematic in > my case. > > -----Original Message----- > From: Christian Tismer [mailto:tismer at stackless.com] > Sent: 29 ноября 2012 г. 0:58 > To: Alexey Vihorev > Cc: 'Stephan Deibel'; pyside at qt-project.org > Subject: Re: [PySide] QObject.destroyed() is not emitted > > Hi Alexey, > > I tried your example and added a parent. > Right now it looks exactly as it should be: > > >>> def onDestroy(*args): > ... print('destroyed') > ... > >>> obj = QtCore.QObject() > >>> obj.destroyed.connect(onDestroy) > True > >>> par = QtCore.QObject() > >>> obj.setParent(par) > >>> del obj > >>> del par > destroyed > >>> > > This is PySide on Mac OS X, > >>> PySide.__version__ > '1.1.2' > >>> QtCore.__version__ > '4.8.3' > >>> > > Maybe you have some more references to the object? > For simple refcount checking, you can use sys.getrefcount . > > >>> g=sys.getrefcount > >>> g(obj) > 2 > > Note that this prints 2 because of the reference from the call. So the > object should go away when the one real reference goes away. > Maybe you have a different problem, involving more objects? > > --------- > > By the way, PySide seems to be not happy with reference cycles, while pure > python is ok with that: > > >>> obj = QtCore.QObject() > >>> obj.setParent(obj) > >>> g(obj) > 2 > > Eeek, that should be 3. > And if fact....... > > >>> del(obj) > Segmentation fault: 11 > > ciao -- Chris > > > On 11/28/12 9:24 PM, Alexey Vihorev wrote: >> Hi! >> Well, I understand that if what I need to do is achievable with >> explicit deletion, I should go for it :) The problem is that in my >> case the deletion of the object is triggered by deletion of another >> object - its parent. But I can't catch the deletion event - neither of the > object nor its parent. >> That's the problem. The whole reason I started looking into that is >> that one of my objects needed to free some external resources when > destroyed. >> -----Original Message----- >> From: Stephan Deibel [mailto:sdeibel at wingware.com] >> Sent: 28 ноября 2012 г. 16:33 >> To: Alexey Vihorev >> Cc: pyside at qt-project.org >> Subject: Re: [PySide] QObject.destroyed() is not emitted >> >> Alexey Vihorev wrote: >>> Got problems with the following code: >>> >>> from PySide import QtCore >>> >>> def onDestroy(*args): >>> >>> print('destroyed') >>> >>> obj = QtCore.QObject() >>> >>> obj.destroyed.connect(onDestroy) >>> >>> The onDestroy() method is not called, unless del(obj) is called >>> explicitly. In PyQt4 it is called without del(obj). Is that a bug or >>> intended behavior? I'm using Qt 4.8.2, PySide 1.1.2 32bit, Windows >>> 7-64 >>> >> Since no one responded I'll take a stab at this: >> >> I suspect the life cycle of the QObject under PySide is a little >> different and the instance will be deleted later during garbage >> collection and not immediately when it goes out of scope. I'm actually >> not sure why that is happening in PyQt (seems slightly surprising). >> >> In general if you want to make sure an instance is deleted at a >> particular moment in time, you need to delete it explicitly. By that, >> I mean calling some sort of delete method (in PySide I think it's >> shiboken.delete(obj) and not just "del obj". The latter just deletes >> your reference to the instance but doesn't destroy the instance until >> all other references are gone and it is garbage collected. Of course >> calling >> shiboken.delete(obj) will be a problem if you still have other >> references and try to use them! >> >> There is also obj.deleteLater() which marks an object for deletion but >> it's not deleted until the event loop is reached again. Depending on >> what you're doing this may be a safer way to delete it. >> >> At first I thought this might be a refcount bug in PySide. However, >> I'm thinking not since "del obj" just deletes your reference to it and >> if there were extra references hanging around (either on purpose or as >> a result of a refcount bug) then it would not be deleting the instance >> at all even after "del obj". >> >> I don't understand PySide internals that well so it's possible I'm >> missing some subtlety here. I'm going more on my knowledge of Python in > general. >> - Stephan >> >> _______________________________________________ >> PySide mailing list >> PySide at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/pyside > -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From vihorev at gmail.com Thu Nov 29 13:05:14 2012 From: vihorev at gmail.com (Alexey Vihorev) Date: Thu, 29 Nov 2012 14:05:14 +0200 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <50B6E397.5070403@stackless.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> <000f01cdcde1$5dba2b70$192e8250$@gmail.com> <50B6E397.5070403@stackless.com> Message-ID: <000701cdce29$cb750fc0$625f2f40$@gmail.com> Ok, let's get less abstract. I got a QTableModel that has to free up some external resources upon its destruction (rollback/close a DB transaction). In this particular case It's parent is QMdiSubWindow with self.setAttribute(QtCore.Qt.WA_DeleteOnClose), but that is not necessary - it can be used inside complex widgets, etc. The code is trivial, but does not work: class MyModel(QAbstractTableModel): def onDestroy(self): #Do some housekeeping def __init__(self, entity_cls, parent=None, load=True, criteria=None): ... self.destroyed.connect(self.onDestroy) ... -----Original Message----- From: Christian Tismer [mailto:tismer at stackless.com] Sent: 29 ноября 2012 г. 6:25 To: Alexey Vihorev Cc: 'Stephan Deibel'; pyside at qt-project.org Subject: Re: [PySide] QObject.destroyed() is not emitted Alexey, there is not enough context to see your problem. The behavior in our similar examples is correct: Noting gets destroyed until we release the references from Python. As long as you have a reference, no destruction occurs. By the assignment obj = QtCore.Object(), you create a reference. You do not actively destroy the object by del ob but you just remove one reference. And because nothing else has a reference to it, _then_ the destruction takes place. The question is about the interaction with other objects. If everything is correct with PySide (which is certainly still not), then destruction should just work automatically when it's time. So please give us more of your code. We cannot see what the real problem is. cheers - chris On 29.11.12 04:26, Alexey Vihorev wrote: > Yes, I tried something like that: > > def onDestroy(*args): > print('destroyed') > > obj = QtCore.QObject() > obj.destroyed.connect(onDestroy) > > obj2 = QtCore.QObject(obj) > obj2.destroyed.connect(onDestroy) > > del(obj) > > In this case onDestroy() is called twice, just as it should. But once > again > - omit the last line and nothing Is called. So for it to work explicit > destruction must be called at the top of the chain. Which is > problematic in my case. > > -----Original Message----- > From: Christian Tismer [mailto:tismer at stackless.com] > Sent: 29 ноября 2012 г. 0:58 > To: Alexey Vihorev > Cc: 'Stephan Deibel'; pyside at qt-project.org > Subject: Re: [PySide] QObject.destroyed() is not emitted > > Hi Alexey, > > I tried your example and added a parent. > Right now it looks exactly as it should be: > > >>> def onDestroy(*args): > ... print('destroyed') > ... > >>> obj = QtCore.QObject() > >>> obj.destroyed.connect(onDestroy) True > >>> par = QtCore.QObject() > >>> obj.setParent(par) > >>> del obj > >>> del par > destroyed > >>> > > This is PySide on Mac OS X, > >>> PySide.__version__ > '1.1.2' > >>> QtCore.__version__ > '4.8.3' > >>> > > Maybe you have some more references to the object? > For simple refcount checking, you can use sys.getrefcount . > > >>> g=sys.getrefcount > >>> g(obj) > 2 > > Note that this prints 2 because of the reference from the call. So the > object should go away when the one real reference goes away. > Maybe you have a different problem, involving more objects? > > --------- > > By the way, PySide seems to be not happy with reference cycles, while > pure python is ok with that: > > >>> obj = QtCore.QObject() > >>> obj.setParent(obj) > >>> g(obj) > 2 > > Eeek, that should be 3. > And if fact....... > > >>> del(obj) > Segmentation fault: 11 > > ciao -- Chris > > > On 11/28/12 9:24 PM, Alexey Vihorev wrote: >> Hi! >> Well, I understand that if what I need to do is achievable with >> explicit deletion, I should go for it :) The problem is that in my >> case the deletion of the object is triggered by deletion of another >> object - its parent. But I can't catch the deletion event - neither >> of the > object nor its parent. >> That's the problem. The whole reason I started looking into that is >> that one of my objects needed to free some external resources when > destroyed. >> -----Original Message----- >> From: Stephan Deibel [mailto:sdeibel at wingware.com] >> Sent: 28 ноября 2012 г. 16:33 >> To: Alexey Vihorev >> Cc: pyside at qt-project.org >> Subject: Re: [PySide] QObject.destroyed() is not emitted >> >> Alexey Vihorev wrote: >>> Got problems with the following code: >>> >>> from PySide import QtCore >>> >>> def onDestroy(*args): >>> >>> print('destroyed') >>> >>> obj = QtCore.QObject() >>> >>> obj.destroyed.connect(onDestroy) >>> >>> The onDestroy() method is not called, unless del(obj) is called >>> explicitly. In PyQt4 it is called without del(obj). Is that a bug or >>> intended behavior? I'm using Qt 4.8.2, PySide 1.1.2 32bit, Windows >>> 7-64 >>> >> Since no one responded I'll take a stab at this: >> >> I suspect the life cycle of the QObject under PySide is a little >> different and the instance will be deleted later during garbage >> collection and not immediately when it goes out of scope. I'm >> actually not sure why that is happening in PyQt (seems slightly surprising). >> >> In general if you want to make sure an instance is deleted at a >> particular moment in time, you need to delete it explicitly. By that, >> I mean calling some sort of delete method (in PySide I think it's >> shiboken.delete(obj) and not just "del obj". The latter just deletes >> your reference to the instance but doesn't destroy the instance until >> all other references are gone and it is garbage collected. Of course >> calling >> shiboken.delete(obj) will be a problem if you still have other >> references and try to use them! >> >> There is also obj.deleteLater() which marks an object for deletion >> but it's not deleted until the event loop is reached again. Depending >> on what you're doing this may be a safer way to delete it. >> >> At first I thought this might be a refcount bug in PySide. However, >> I'm thinking not since "del obj" just deletes your reference to it >> and if there were extra references hanging around (either on purpose >> or as a result of a refcount bug) then it would not be deleting the >> instance at all even after "del obj". >> >> I don't understand PySide internals that well so it's possible I'm >> missing some subtlety here. I'm going more on my knowledge of Python >> in > general. >> - Stephan >> >> _______________________________________________ >> PySide mailing list >> PySide at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/pyside > -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From sdeibel at wingware.com Thu Nov 29 15:42:43 2012 From: sdeibel at wingware.com (Stephan Deibel) Date: Thu, 29 Nov 2012 09:42:43 -0500 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <000701cdce29$cb750fc0$625f2f40$@gmail.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> <000f01cdcde1$5dba2b70$192e8250$@gmail.com> <50B6E397.5070403@stackless.com> <000701cdce29$cb750fc0$625f2f40$@gmail.com> Message-ID: <50B77463.1030000@wingware.com> Alexey Vihorev wrote: > Ok, let's get less abstract. I got a QTableModel that has to free up some external resources upon its destruction (rollback/close a DB transaction). In this particular case It's parent is QMdiSubWindow with self.setAttribute(QtCore.Qt.WA_DeleteOnClose), but that is not necessary - it can be used inside complex widgets, etc. The code is trivial, but does not work: > > class MyModel(QAbstractTableModel): > > def onDestroy(self): > #Do some housekeeping > > def __init__(self, entity_cls, parent=None, load=True, criteria=None): > ... > self.destroyed.connect(self.onDestroy) > ... Whether or not onDestroy is called in this is entirely dependent on whether they are object references to your instance of MyModel somewhere else in your code. It may well be that the parent is holding onto a reference after it's closed for some reason (or some other code is), but it would be hard to verify this without a complete functional example (preferably something pared down as much as possible but still exhibiting the issue). - Stephan From tismer at stackless.com Thu Nov 29 15:54:00 2012 From: tismer at stackless.com (Christian Tismer) Date: Thu, 29 Nov 2012 15:54:00 +0100 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <000701cdce29$cb750fc0$625f2f40$@gmail.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> <000f01cdcde1$5dba2b70$192e8250$@gmail.com> <50B6E397.5070403@stackless.com> <000701cdce29$cb750fc0$625f2f40$@gmail.com> Message-ID: <50B77708.1020000@stackless.com> Hi Alexey, found it! :-) This is in fact a PySide quirk: Your deletion method is an attribute that lives inside the object to be deleted, and that is the problem: Destruction seems not to care about the order of destruction, and the __dict__ that also holds the onDestroy bound method gets destructed before it is called. I tried that for other kinds of objects, it is always the same. If you use a function from elsewhere, it works. I tried to put the onDestroy method into an external list, with no success, because that reference disables destruction. A general work-around could use a weakref, but for your case I think this simple solution is fine: from PySide.QtCore import QAbstractTableModel class MyModel(QAbstractTableModel): def __init__(self, *args): super(MyModel, self).__init__(*args) self.destroyed.connect(self.onDestroy) @staticmethod def onDestroy(): print('destroyed') m = MyModel() del m prints "destroyed" :=) cheers - chris On 11/29/12 1:05 PM, Alexey Vihorev wrote: > Ok, let's get less abstract. I got a QTableModel that has to free up some external resources upon its destruction (rollback/close a DB transaction). In this particular case It's parent is QMdiSubWindow with self.setAttribute(QtCore.Qt.WA_DeleteOnClose), but that is not necessary - it can be used inside complex widgets, etc. The code is trivial, but does not work: > > class MyModel(QAbstractTableModel): > > def onDestroy(self): > #Do some housekeeping > > def __init__(self, entity_cls, parent=None, load=True, criteria=None): > ... > self.destroyed.connect(self.onDestroy) > ... > > > > -----Original Message----- > From: Christian Tismer [mailto:tismer at stackless.com] > Sent: 29 ноября 2012 г. 6:25 > To: Alexey Vihorev > Cc: 'Stephan Deibel'; pyside at qt-project.org > Subject: Re: [PySide] QObject.destroyed() is not emitted > > Alexey, > > there is not enough context to see your problem. > > The behavior in our similar examples is correct: > > Noting gets destroyed until we release the references from Python. > As long as you have a reference, no destruction occurs. > > By the assignment > > obj = QtCore.Object(), > > you create a reference. You do not actively destroy the object by > > del ob > > but you just remove one reference. And because nothing else has a reference to it, _then_ the destruction takes place. > > The question is about the interaction with other objects. > If everything is correct with PySide (which is certainly still not), then destruction should just work automatically when it's time. > > So please give us more of your code. > We cannot see what the real problem is. > > cheers - chris > > On 29.11.12 04:26, Alexey Vihorev wrote: >> Yes, I tried something like that: >> >> def onDestroy(*args): >> print('destroyed') >> >> obj = QtCore.QObject() >> obj.destroyed.connect(onDestroy) >> >> obj2 = QtCore.QObject(obj) >> obj2.destroyed.connect(onDestroy) >> >> del(obj) >> >> In this case onDestroy() is called twice, just as it should. But once >> again >> - omit the last line and nothing Is called. So for it to work explicit >> destruction must be called at the top of the chain. Which is >> problematic in my case. >> >> -----Original Message----- >> From: Christian Tismer [mailto:tismer at stackless.com] >> Sent: 29 ноября 2012 г. 0:58 >> To: Alexey Vihorev >> Cc: 'Stephan Deibel'; pyside at qt-project.org >> Subject: Re: [PySide] QObject.destroyed() is not emitted >> >> Hi Alexey, >> >> I tried your example and added a parent. >> Right now it looks exactly as it should be: >> >> >>> def onDestroy(*args): >> ... print('destroyed') >> ... >> >>> obj = QtCore.QObject() >> >>> obj.destroyed.connect(onDestroy) True >> >>> par = QtCore.QObject() >> >>> obj.setParent(par) >> >>> del obj >> >>> del par >> destroyed >> >>> >> >> This is PySide on Mac OS X, >> >>> PySide.__version__ >> '1.1.2' >> >>> QtCore.__version__ >> '4.8.3' >> >>> >> >> Maybe you have some more references to the object? >> For simple refcount checking, you can use sys.getrefcount . >> >> >>> g=sys.getrefcount >> >>> g(obj) >> 2 >> >> Note that this prints 2 because of the reference from the call. So the >> object should go away when the one real reference goes away. >> Maybe you have a different problem, involving more objects? >> >> --------- >> >> By the way, PySide seems to be not happy with reference cycles, while >> pure python is ok with that: >> >> >>> obj = QtCore.QObject() >> >>> obj.setParent(obj) >> >>> g(obj) >> 2 >> >> Eeek, that should be 3. >> And if fact....... >> >> >>> del(obj) >> Segmentation fault: 11 >> >> ciao -- Chris >> >> >> On 11/28/12 9:24 PM, Alexey Vihorev wrote: >>> Hi! >>> Well, I understand that if what I need to do is achievable with >>> explicit deletion, I should go for it :) The problem is that in my >>> case the deletion of the object is triggered by deletion of another >>> object - its parent. But I can't catch the deletion event - neither >>> of the >> object nor its parent. >>> That's the problem. The whole reason I started looking into that is >>> that one of my objects needed to free some external resources when >> destroyed. >>> -----Original Message----- >>> From: Stephan Deibel [mailto:sdeibel at wingware.com] >>> Sent: 28 ноября 2012 г. 16:33 >>> To: Alexey Vihorev >>> Cc: pyside at qt-project.org >>> Subject: Re: [PySide] QObject.destroyed() is not emitted >>> >>> Alexey Vihorev wrote: >>>> Got problems with the following code: >>>> >>>> from PySide import QtCore >>>> >>>> def onDestroy(*args): >>>> >>>> print('destroyed') >>>> >>>> obj = QtCore.QObject() >>>> >>>> obj.destroyed.connect(onDestroy) >>>> >>>> The onDestroy() method is not called, unless del(obj) is called >>>> explicitly. In PyQt4 it is called without del(obj). Is that a bug or >>>> intended behavior? I'm using Qt 4.8.2, PySide 1.1.2 32bit, Windows >>>> 7-64 >>>> >>> Since no one responded I'll take a stab at this: >>> >>> I suspect the life cycle of the QObject under PySide is a little >>> different and the instance will be deleted later during garbage >>> collection and not immediately when it goes out of scope. I'm >>> actually not sure why that is happening in PyQt (seems slightly surprising). >>> >>> In general if you want to make sure an instance is deleted at a >>> particular moment in time, you need to delete it explicitly. By that, >>> I mean calling some sort of delete method (in PySide I think it's >>> shiboken.delete(obj) and not just "del obj". The latter just deletes >>> your reference to the instance but doesn't destroy the instance until >>> all other references are gone and it is garbage collected. Of course >>> calling >>> shiboken.delete(obj) will be a problem if you still have other >>> references and try to use them! >>> >>> There is also obj.deleteLater() which marks an object for deletion >>> but it's not deleted until the event loop is reached again. Depending >>> on what you're doing this may be a safer way to delete it. >>> >>> At first I thought this might be a refcount bug in PySide. However, >>> I'm thinking not since "del obj" just deletes your reference to it >>> and if there were extra references hanging around (either on purpose >>> or as a result of a refcount bug) then it would not be deleting the >>> instance at all even after "del obj". >>> >>> I don't understand PySide internals that well so it's possible I'm >>> missing some subtlety here. I'm going more on my knowledge of Python >>> in >> general. >>> - Stephan >>> >>> _______________________________________________ >>> PySide mailing list >>> PySide at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/pyside > -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From vihorev at gmail.com Thu Nov 29 16:48:21 2012 From: vihorev at gmail.com (Alexey Vihorev) Date: Thu, 29 Nov 2012 17:48:21 +0200 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <50B77708.1020000@stackless.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> <000f01cdcde1$5dba2b70$192e8250$@gmail.com> <50B6E397.5070403@stackless.com> <000701cdce29$cb750fc0$625f2f40$@gmail.com> <50B77708.1020000@stackless.com> Message-ID: <000801cdce48$f767e200$e637a600$@gmail.com> Hi, Christian! Thanks, nice find, but... I hit the next hurdle trying to go this way. The signal QObject.destroyed(obj) is passing no arguments (probably because obj is already destroyed), so my static method has nothing to work on. Which kind of devaluates the whole idea, IMHO. And in PyQt4 it *does* pass the object. Even more: in PyQt4 there is no need for static method approach, as it works perfectly with instance methods: from PyQt4 import QtGui,QtCore class MyModel(QtCore.QAbstractTableModel): def beforeDestruction(self, *arg): print(arg) if __name__ == '__main__': import sys app = QtGui.QApplication(sys.argv) window = QtGui.QWidget() window.setAttribute(QtCore.Qt.WA_DeleteOnClose) model = MyModel(window) model.destroyed.connect(model.beforeDestruction) window.show() app.exec_() -----Original Message----- From: Christian Tismer [mailto:tismer at stackless.com] Sent: 29 ноября 2012 г. 16:54 To: Alexey Vihorev Cc: 'Stephan Deibel'; pyside at qt-project.org Subject: Re: [PySide] QObject.destroyed() is not emitted Hi Alexey, found it! :-) This is in fact a PySide quirk: Your deletion method is an attribute that lives inside the object to be deleted, and that is the problem: Destruction seems not to care about the order of destruction, and the __dict__ that also holds the onDestroy bound method gets destructed before it is called. I tried that for other kinds of objects, it is always the same. If you use a function from elsewhere, it works. I tried to put the onDestroy method into an external list, with no success, because that reference disables destruction. A general work-around could use a weakref, but for your case I think this simple solution is fine: from PySide.QtCore import QAbstractTableModel class MyModel(QAbstractTableModel): def __init__(self, *args): super(MyModel, self).__init__(*args) self.destroyed.connect(self.onDestroy) @staticmethod def onDestroy(): print('destroyed') m = MyModel() del m prints "destroyed" :=) cheers - chris On 11/29/12 1:05 PM, Alexey Vihorev wrote: > Ok, let's get less abstract. I got a QTableModel that has to free up some external resources upon its destruction (rollback/close a DB transaction). In this particular case It's parent is QMdiSubWindow with self.setAttribute(QtCore.Qt.WA_DeleteOnClose), but that is not necessary - it can be used inside complex widgets, etc. The code is trivial, but does not work: > > class MyModel(QAbstractTableModel): > > def onDestroy(self): > #Do some housekeeping > > def __init__(self, entity_cls, parent=None, load=True, criteria=None): > ... > self.destroyed.connect(self.onDestroy) > ... > > > > -----Original Message----- > From: Christian Tismer [mailto:tismer at stackless.com] > Sent: 29 ноября 2012 г. 6:25 > To: Alexey Vihorev > Cc: 'Stephan Deibel'; pyside at qt-project.org > Subject: Re: [PySide] QObject.destroyed() is not emitted > > Alexey, > > there is not enough context to see your problem. > > The behavior in our similar examples is correct: > > Noting gets destroyed until we release the references from Python. > As long as you have a reference, no destruction occurs. > > By the assignment > > obj = QtCore.Object(), > > you create a reference. You do not actively destroy the object by > > del ob > > but you just remove one reference. And because nothing else has a reference to it, _then_ the destruction takes place. > > The question is about the interaction with other objects. > If everything is correct with PySide (which is certainly still not), then destruction should just work automatically when it's time. > > So please give us more of your code. > We cannot see what the real problem is. > > cheers - chris > > On 29.11.12 04:26, Alexey Vihorev wrote: >> Yes, I tried something like that: >> >> def onDestroy(*args): >> print('destroyed') >> >> obj = QtCore.QObject() >> obj.destroyed.connect(onDestroy) >> >> obj2 = QtCore.QObject(obj) >> obj2.destroyed.connect(onDestroy) >> >> del(obj) >> >> In this case onDestroy() is called twice, just as it should. But once >> again >> - omit the last line and nothing Is called. So for it to work >> explicit destruction must be called at the top of the chain. Which is >> problematic in my case. >> >> -----Original Message----- >> From: Christian Tismer [mailto:tismer at stackless.com] >> Sent: 29 ноября 2012 г. 0:58 >> To: Alexey Vihorev >> Cc: 'Stephan Deibel'; pyside at qt-project.org >> Subject: Re: [PySide] QObject.destroyed() is not emitted >> >> Hi Alexey, >> >> I tried your example and added a parent. >> Right now it looks exactly as it should be: >> >> >>> def onDestroy(*args): >> ... print('destroyed') >> ... >> >>> obj = QtCore.QObject() >> >>> obj.destroyed.connect(onDestroy) True >> >>> par = QtCore.QObject() >> >>> obj.setParent(par) >> >>> del obj >> >>> del par >> destroyed >> >>> >> >> This is PySide on Mac OS X, >> >>> PySide.__version__ >> '1.1.2' >> >>> QtCore.__version__ >> '4.8.3' >> >>> >> >> Maybe you have some more references to the object? >> For simple refcount checking, you can use sys.getrefcount . >> >> >>> g=sys.getrefcount >> >>> g(obj) >> 2 >> >> Note that this prints 2 because of the reference from the call. So >> the object should go away when the one real reference goes away. >> Maybe you have a different problem, involving more objects? >> >> --------- >> >> By the way, PySide seems to be not happy with reference cycles, while >> pure python is ok with that: >> >> >>> obj = QtCore.QObject() >> >>> obj.setParent(obj) >> >>> g(obj) >> 2 >> >> Eeek, that should be 3. >> And if fact....... >> >> >>> del(obj) >> Segmentation fault: 11 >> >> ciao -- Chris >> >> >> On 11/28/12 9:24 PM, Alexey Vihorev wrote: >>> Hi! >>> Well, I understand that if what I need to do is achievable with >>> explicit deletion, I should go for it :) The problem is that in my >>> case the deletion of the object is triggered by deletion of another >>> object - its parent. But I can't catch the deletion event - neither >>> of the >> object nor its parent. >>> That's the problem. The whole reason I started looking into that is >>> that one of my objects needed to free some external resources when >> destroyed. >>> -----Original Message----- >>> From: Stephan Deibel [mailto:sdeibel at wingware.com] >>> Sent: 28 ноября 2012 г. 16:33 >>> To: Alexey Vihorev >>> Cc: pyside at qt-project.org >>> Subject: Re: [PySide] QObject.destroyed() is not emitted >>> >>> Alexey Vihorev wrote: >>>> Got problems with the following code: >>>> >>>> from PySide import QtCore >>>> >>>> def onDestroy(*args): >>>> >>>> print('destroyed') >>>> >>>> obj = QtCore.QObject() >>>> >>>> obj.destroyed.connect(onDestroy) >>>> >>>> The onDestroy() method is not called, unless del(obj) is called >>>> explicitly. In PyQt4 it is called without del(obj). Is that a bug >>>> or intended behavior? I'm using Qt 4.8.2, PySide 1.1.2 32bit, >>>> Windows >>>> 7-64 >>>> >>> Since no one responded I'll take a stab at this: >>> >>> I suspect the life cycle of the QObject under PySide is a little >>> different and the instance will be deleted later during garbage >>> collection and not immediately when it goes out of scope. I'm >>> actually not sure why that is happening in PyQt (seems slightly surprising). >>> >>> In general if you want to make sure an instance is deleted at a >>> particular moment in time, you need to delete it explicitly. By >>> that, I mean calling some sort of delete method (in PySide I think >>> it's >>> shiboken.delete(obj) and not just "del obj". The latter just deletes >>> your reference to the instance but doesn't destroy the instance >>> until all other references are gone and it is garbage collected. Of >>> course calling >>> shiboken.delete(obj) will be a problem if you still have other >>> references and try to use them! >>> >>> There is also obj.deleteLater() which marks an object for deletion >>> but it's not deleted until the event loop is reached again. >>> Depending on what you're doing this may be a safer way to delete it. >>> >>> At first I thought this might be a refcount bug in PySide. However, >>> I'm thinking not since "del obj" just deletes your reference to it >>> and if there were extra references hanging around (either on purpose >>> or as a result of a refcount bug) then it would not be deleting the >>> instance at all even after "del obj". >>> >>> I don't understand PySide internals that well so it's possible I'm >>> missing some subtlety here. I'm going more on my knowledge of Python >>> in >> general. >>> - Stephan >>> >>> _______________________________________________ >>> PySide mailing list >>> PySide at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/pyside > -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From sdeibel at wingware.com Thu Nov 29 18:37:47 2012 From: sdeibel at wingware.com (Stephan Deibel) Date: Thu, 29 Nov 2012 12:37:47 -0500 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <000801cdce48$f767e200$e637a600$@gmail.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> <000f01cdcde1$5dba2b70$192e8250$@gmail.com> <50B6E397.5070403@stackless.com> <000701cdce29$cb750fc0$625f2f40$@gmail.com> <50B77708.1020000@stackless.com> <000801cdce48$f767e200$e637a600$@gmail.com> Message-ID: <50B79D6B.90701@wingware.com> Alexey Vihorev wrote: > Thanks, nice find, but... I hit the next hurdle trying to go this way. The signal QObject.destroyed(obj) is passing no arguments (probably because obj is already destroyed), so my static method has nothing to work on. Which kind of devaluates the whole idea, IMHO. And in PyQt4 it*does* pass the object. Even more: in PyQt4 there is no need for static method approach, as it works perfectly with instance methods: Yea, you would have to bind the necessary data to the callback like this: def on_destroy(val1=self.whatever, val2=self.something): print 'destroyed' self.destroyed.connect(on_destroy) Whether this is possible or useful in your case is of course going to depend on the details of the code. Having 'destroyed' be emitted before the object is destroyed and getting the object reference as an arg makes more sense to me. That is what PyQt seems to do and it is what QObject does under Qt using C++, so I'd call this a bug in PySide. I've added https://bugreports.qt-project.org/browse/PYSIDE-129 - Stephan From vihorev at gmail.com Thu Nov 29 18:53:20 2012 From: vihorev at gmail.com (Alexey Vihorev) Date: Thu, 29 Nov 2012 19:53:20 +0200 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <50B79D6B.90701@wingware.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> <000f01cdcde1$5dba2b70$192e8250$@gmail.com> <50B6E397.5070403@stackless.com> <000701cdce29$cb750fc0$625f2f40$@gmail.com> <50B77708.1020000@stackless.com> <000801cdce48$f767e200$e637a600$@gmail.com> <50B79D6B.90701@wingware.com> Message-ID: <000901cdce5a$6cb126a0$461373e0$@gmail.com> Thanks! Now I've only got to wait until it's fixed :) BTW, a little off topic: what is PySide development status currently? Are there people paid to work on this, or it's purely community supported? -----Original Message----- From: Stephan Deibel [mailto:sdeibel at wingware.com] Sent: 29 ноября 2012 г. 19:38 To: Alexey Vihorev Cc: 'Christian Tismer'; pyside at qt-project.org Subject: Re: [PySide] QObject.destroyed() is not emitted Alexey Vihorev wrote: > Thanks, nice find, but... I hit the next hurdle trying to go this way. The signal QObject.destroyed(obj) is passing no arguments (probably because obj is already destroyed), so my static method has nothing to work on. Which kind of devaluates the whole idea, IMHO. And in PyQt4 it*does* pass the object. Even more: in PyQt4 there is no need for static method approach, as it works perfectly with instance methods: Yea, you would have to bind the necessary data to the callback like this: def on_destroy(val1=self.whatever, val2=self.something): print 'destroyed' self.destroyed.connect(on_destroy) Whether this is possible or useful in your case is of course going to depend on the details of the code. Having 'destroyed' be emitted before the object is destroyed and getting the object reference as an arg makes more sense to me. That is what PyQt seems to do and it is what QObject does under Qt using C++, so I'd call this a bug in PySide. I've added https://bugreports.qt-project.org/browse/PYSIDE-129 - Stephan From sdeibel at wingware.com Thu Nov 29 19:10:41 2012 From: sdeibel at wingware.com (Stephan Deibel) Date: Thu, 29 Nov 2012 13:10:41 -0500 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <000901cdce5a$6cb126a0$461373e0$@gmail.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> <000f01cdcde1$5dba2b70$192e8250$@gmail.com> <50B6E397.5070403@stackless.com> <000701cdce29$cb750fc0$625f2f40$@gmail.com> <50B77708.1020000@stackless.com> <000801cdce48$f767e200$e637a600$@gmail.com> <50B79D6B.90701@wingware.com> <000901cdce5a$6cb126a0$461373e0$@gmail.com> Message-ID: <50B7A521.4000208@wingware.com> Alexey Vihorev wrote: > Thanks! Now I've only got to wait until it's fixed:) > BTW, a little off topic: what is PySide development status currently? Are there people paid to work on this, or it's purely community supported? It's community-supported now but was initially created by paid developers at Nokia. I think the original developers are still around but probably pretty busy with other things. It would be great to see some more people from the community working on bug fixes. I think PySide is still somewhat in the process of making the transition to being maintained by its users. - Stephan From hugo.lima at openbossa.org Thu Nov 29 19:55:38 2012 From: hugo.lima at openbossa.org (Hugo Parente Lima) Date: Thu, 29 Nov 2012 15:55:38 -0300 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <50B7A521.4000208@wingware.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <000901cdce5a$6cb126a0$461373e0$@gmail.com> <50B7A521.4000208@wingware.com> Message-ID: <1648242.S8DW1gBXjX@hugodesktop> On Thursday, November 29, 2012 01:10:41 PM Stephan Deibel wrote: > Alexey Vihorev wrote: > > Thanks! Now I've only got to wait until it's fixed:) > > BTW, a little off topic: what is PySide development status currently? Are > > there people paid to work on this, or it's purely community supported? > It's community-supported now but was initially created by paid > developers at Nokia. I think the original developers are still around > but probably pretty busy with other things. It would be great to see > some more people from the community working on bug fixes. I think > PySide is still somewhat in the process of making the transition to > being maintained by its users. Hi Nowadays no one is paid to work on PySide, I'm the current maintainer of PySide but I'm no longer fixing bugs or coding anything, I just review patches and do releases when we have a significant amount of changes. I would like to step down as PySide maintainer as soon somebody raise the hand to be the new maintainer, but nobody seems to want this :-/. > - Stephan > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From tismer at stackless.com Thu Nov 29 19:57:02 2012 From: tismer at stackless.com (Christian Tismer) Date: Thu, 29 Nov 2012 19:57:02 +0100 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <50B79D6B.90701@wingware.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> <000f01cdcde1$5dba2b70$192e8250$@gmail.com> <50B6E397.5070403@stackless.com> <000701cdce29$cb750fc0$625f2f40$@gmail.com> <50B77708.1020000@stackless.com> <000801cdce48$f767e200$e637a600$@gmail.com> <50B79D6B.90701@wingware.com> Message-ID: <50B7AFFE.7050305@stackless.com> Hi, On 11/29/12 6:37 PM, Stephan Deibel wrote: > Alexey Vihorev wrote: >> Thanks, nice find, but... I hit the next hurdle trying to go this >> way. The signal QObject.destroyed(obj) is passing no arguments >> (probably because obj is already destroyed), so my static method has >> nothing to work on. Which kind of devaluates the whole idea, IMHO. >> And in PyQt4 it*does* pass the object. Even more: in PyQt4 there is >> no need for static method approach, as it works perfectly with >> instance methods: > > Yea, you would have to bind the necessary data to the callback like this: > > def on_destroy(val1=self.whatever, val2=self.something): > print 'destroyed' > self.destroyed.connect(on_destroy) Here is a not really nice hack, but it works, based on Stefan's bug tracker code: The idea is to simply capture the __dict__ of the object and to abuse it as the dict of a helper class. This way, although the object goes away, it __dict__ survives, and we can work on it after deletion. from PySide.QtCore import QAbstractTableModel class MyModel(QAbstractTableModel): def __init__(self, *args): super(MyModel, self).__init__(*args) # This one does not work because the instance is destroyed already # so the method call does not happen self.destroyed.connect(self.onDestroy) # This does work because the instance doesn't have to exist anymore def on_destroy(): print "destroyed signal: function" self.destroyed.connect(on_destroy) self.important = 42 def onDestroy(self): print('destroyed signal: method') def do_something(self): self.important += 1 m = MyModel() class Helper(object): def __init__(self, inst): self.__dict__ = inst.__dict__ h = Helper(m) m.do_something() m.important del m print(h.important) print("Done") ----------------------- output: >>> m.do_something() >>> m.important 43 >>> >>> del m destroyed signal: function >>> print(h.important) 43 >>> >>> print("Done") Done -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From tismer at stackless.com Thu Nov 29 21:10:49 2012 From: tismer at stackless.com (Christian Tismer) Date: Thu, 29 Nov 2012 21:10:49 +0100 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <50B7AFFE.7050305@stackless.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> <000f01cdcde1$5dba2b70$192e8250$@gmail.com> <50B6E397.5070403@stackless.com> <000701cdce29$cb750fc0$625f2f40$@gmail.com> <50B77708.1020000@stackless.com> <000801cdce48$f767e200$e637a600$@gmail.com> <50B79D6B.90701@wingware.com> <50B7AFFE.7050305@stackless.com> Message-ID: <50B7C149.6020502@stackless.com> Hi again, after some thought, I believe I can write a little helper function that would be added to a class with a wrapper that looks like so when called: from pyside_fix import fix_destroy class MyModel(QAbstractTableModel): ... @fix_destroy def onDestroy(self): print('destroyed signal:', self.important) This function would create such a helper class that allows access to the dying object (while being a fake class), bind the instance __dict__ to a function default, turn onDestroy into something different which still has a fake self with correct attributes etc. etc. and behaves mostly "right". This is meant as a helper until PySide gets really fixed. Should I do that? cheers -- chris On 11/29/12 7:57 PM, Christian Tismer wrote: > Hi, > > On 11/29/12 6:37 PM, Stephan Deibel wrote: >> Alexey Vihorev wrote: >>> Thanks, nice find, but... I hit the next hurdle trying to go this >>> way. The signal QObject.destroyed(obj) is passing no arguments >>> (probably because obj is already destroyed), so my static method has >>> nothing to work on. Which kind of devaluates the whole idea, IMHO. >>> And in PyQt4 it*does* pass the object. Even more: in PyQt4 there is >>> no need for static method approach, as it works perfectly with >>> instance methods: >> Yea, you would have to bind the necessary data to the callback like this: >> >> def on_destroy(val1=self.whatever, val2=self.something): >> print 'destroyed' >> self.destroyed.connect(on_destroy) > Here is a not really nice hack, but it works, based on Stefan's > bug tracker code: > > The idea is to simply capture the __dict__ of the object and to abuse it > as the dict of a helper class. This way, although the object goes away, > it __dict__ survives, and we can work on it after deletion. > > > from PySide.QtCore import QAbstractTableModel > > class MyModel(QAbstractTableModel): > def __init__(self, *args): > super(MyModel, self).__init__(*args) > > # This one does not work because the instance is destroyed already > # so the method call does not happen > self.destroyed.connect(self.onDestroy) > > # This does work because the instance doesn't have to exist anymore > def on_destroy(): > print "destroyed signal: function" > self.destroyed.connect(on_destroy) > > self.important = 42 > > def onDestroy(self): > print('destroyed signal: method') > > def do_something(self): > self.important += 1 > > m = MyModel() > > class Helper(object): > def __init__(self, inst): > self.__dict__ = inst.__dict__ > > h = Helper(m) > > m.do_something() > m.important > > del m > print(h.important) > > print("Done") > > > ----------------------- output: > > >>> m.do_something() > >>> m.important > 43 > >>> > >>> del m > destroyed signal: function > >>> print(h.important) > 43 > >>> > >>> print("Done") > Done > > -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From nmelchior at seegrid.com Thu Nov 29 22:06:14 2012 From: nmelchior at seegrid.com (Nik Melchior) Date: Thu, 29 Nov 2012 16:06:14 -0500 Subject: [PySide] Problems with QStyle deletion In-Reply-To: <50B3B9C1.80401@wingware.com> References: <50A57216.5090700@wingware.com> <50B3B9C1.80401@wingware.com> Message-ID: <20121129210613.GA9824@a367.seegrid.com> On Mon, Nov 26, 2012 at 01:49:37PM -0500, John Ehresman wrote: > On 11/15/12 5:52 PM, John Ehresman wrote: > > I'm trying to fix a bug that causes segfaults if QApplication.style() and > > QApplication.setStyle() are used repeatedly. I think the issue is: John, My application has random crashes due to QStyle objects as well. I had some trouble tracking down the problem, and I originally thought it was related to a bug that reported QNetworkReply objects being randomly returned. I added my analysis to PySide bug #16, but I haven't seen any activity there. https://bugreports.qt-project.org/browse/PYSIDE-16 The workaround that I posted suppresses the most frequent occurrence of the bug, but it occasionally appears in other parts of our code, and I have to insert additional checks to prevent segfaults. Very annoying. -- Nik Email Confidentiality Notice The information contained in this transmission is confidential, proprietary or privileged and may be subject to protection under the law. This message is intended for the sole use of the individual or entity to whom it's addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited and may subject you to criminal or civil penalties. If you received this transmission in error, please contact the sender immediately by replying to this email and delete the material from any computer. From tismer at stackless.com Thu Nov 29 23:40:11 2012 From: tismer at stackless.com (Christian Tismer) Date: Thu, 29 Nov 2012 23:40:11 +0100 Subject: [PySide] Bug is worse (was: QObject.destroyed() is not emitted) In-Reply-To: <50B79D6B.90701@wingware.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> <000f01cdcde1$5dba2b70$192e8250$@gmail.com> <50B6E397.5070403@stackless.com> <000701cdce29$cb750fc0$625f2f40$@gmail.com> <50B77708.1020000@stackless.com> <000801cdce48$f767e200$e637a600$@gmail.com> <50B79D6B.90701@wingware.com> Message-ID: <50B7E44B.1080803@stackless.com> Hi friends, On 11/29/12 6:37 PM, Stephan Deibel wrote: > Alexey Vihorev wrote: >> Thanks, nice find, but... I hit the next hurdle trying to go this >> way. The signal QObject.destroyed(obj) is passing no arguments >> (probably because obj is already destroyed), so my static method has >> nothing to work on. Which kind of devaluates the whole idea, IMHO. >> And in PyQt4 it*does* pass the object. Even more: in PyQt4 there is >> no need for static method approach, as it works perfectly with >> instance methods: > > Yea, you would have to bind the necessary data to the callback like this: > > def on_destroy(val1=self.whatever, val2=self.something): > print 'destroyed' > self.destroyed.connect(on_destroy) > > Whether this is possible or useful in your case is of course going to > depend on the details of the code. > > Having 'destroyed' be emitted before the object is destroyed and > getting the object reference as an arg makes more sense to me. That is > what PyQt seems to do and it is what QObject does under Qt using C++, > so I'd call this a bug in PySide. I've added > https://bugreports.qt-project.org/browse/PYSIDE-129 This bug is only half of the story: We had that simple @staticmethod work-around. But actually, the main reason seems to be that PySide suffers any reference cycle. The tiny example again breaks as soon as I add a property: {code} from PySide.QtCore import QAbstractTableModel, QObject class MyModel(QAbstractTableModel): def __init__(self, *args): super(MyModel, self).__init__(*args) self.destroyed.connect(self.onDestroy) @staticmethod def onDestroy(): print('destroyed') @property def hugo(self): return 42 m = MyModel() del m {code} Remove the @property, and it works, again. Rule of thumb: If you need anything like a property, use a normal Python class and put your Qt object into it as an attribute. Otherwise your program will tend to grow in memory ;-) Stefan, I added this code to your bug report. cheers - chris -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ From nathanjsmith at gmail.com Fri Nov 30 03:43:51 2012 From: nathanjsmith at gmail.com (Nathan Smith) Date: Thu, 29 Nov 2012 20:43:51 -0600 Subject: [PySide] Bug is worse (was: QObject.destroyed() is not emitted) In-Reply-To: <50B7E44B.1080803@stackless.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> <000f01cdcde1$5dba2b70$192e8250$@gmail.com> <50B6E397.5070403@stackless.com> <000701cdce29$cb750fc0$625f2f40$@gmail.com> <50B77708.1020000@stackless.com> <000801cdce48$f767e200$e637a600$@gmail.com> <50B79D6B.90701@wingware.com> <50B7E44B.1080803@stackless.com> Message-ID: I am very interested in this because I have a PySide application where my widgets don't die gracefully (and destroyed isn't signalling their death). I use properties heavily in my code, so I was excited when I saw your email thinking they were the culprit. However, I just tried your example using Python 2.7.1 and PySide 1.1.1, and I can't reproduce the problem. My table prints "destroyed" immediately when I call del m. Are you sure that "property" creates a reference? I did verify in my environment that onDestroy must be static to function correctly. On Thu, Nov 29, 2012 at 4:40 PM, Christian Tismer wrote: > Hi friends, > > On 11/29/12 6:37 PM, Stephan Deibel wrote: > > Alexey Vihorev wrote: > >> Thanks, nice find, but... I hit the next hurdle trying to go this > >> way. The signal QObject.destroyed(obj) is passing no arguments > >> (probably because obj is already destroyed), so my static method has > >> nothing to work on. Which kind of devaluates the whole idea, IMHO. > >> And in PyQt4 it*does* pass the object. Even more: in PyQt4 there is > >> no need for static method approach, as it works perfectly with > >> instance methods: > > > > Yea, you would have to bind the necessary data to the callback like this: > > > > def on_destroy(val1=self.whatever, val2=self.something): > > print 'destroyed' > > self.destroyed.connect(on_destroy) > > > > Whether this is possible or useful in your case is of course going to > > depend on the details of the code. > > > > Having 'destroyed' be emitted before the object is destroyed and > > getting the object reference as an arg makes more sense to me. That is > > what PyQt seems to do and it is what QObject does under Qt using C++, > > so I'd call this a bug in PySide. I've added > > https://bugreports.qt-project.org/browse/PYSIDE-129 > > This bug is only half of the story: > > We had that simple @staticmethod work-around. > But actually, the main reason seems to be that PySide suffers > any reference cycle. > > The tiny example again breaks as soon as I add a property: > > {code} > from PySide.QtCore import QAbstractTableModel, QObject > > class MyModel(QAbstractTableModel): > def __init__(self, *args): > super(MyModel, self).__init__(*args) > self.destroyed.connect(self.onDestroy) > > @staticmethod > def onDestroy(): > print('destroyed') > > @property > def hugo(self): > return 42 > > m = MyModel() > del m > {code} > > Remove the @property, and it works, again. > > Rule of thumb: > If you need anything like a property, use a normal Python class > and put your Qt object into it as an attribute. Otherwise your > program will tend to grow in memory ;-) > > Stefan, I added this code to your bug report. > > cheers - chris > > -- > Christian Tismer :^) > Software Consulting : Have a break! Take a ride on Python's > Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ > 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de > phone +49 173 24 18 776 fax +49 (30) 700143-0023 > PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 > whom do you want to sponsor today? http://www.stackless.com/ > > _______________________________________________ > 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 sdeibel at wingware.com Fri Nov 30 04:38:30 2012 From: sdeibel at wingware.com (Stephan Deibel) Date: Thu, 29 Nov 2012 22:38:30 -0500 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <1648242.S8DW1gBXjX@hugodesktop> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <000901cdce5a$6cb126a0$461373e0$@gmail.com> <50B7A521.4000208@wingware.com> <1648242.S8DW1gBXjX@hugodesktop> Message-ID: <50B82A36.4010605@wingware.com> Hugo Parente Lima wrote: > Nowadays no one is paid to work on PySide, I'm the current maintainer of > PySide but I'm no longer fixing bugs or coding anything, I just review patches > and do releases when we have a significant amount of changes. > > I would like to step down as PySide maintainer as soon somebody raise the hand > to be the new maintainer, but nobody seems to want this :-/. I suspect there are not many people out there that understand PySide internals well enough yet to feel confident about reviewing patches. :-( But hopefully this will change over time. If you have any time to comment briefly on things like http://lists.qt-project.org/pipermail/pyside/2012-November/000805.html and http://lists.qt-project.org/pipermail/pyside/2012-November/000822.html it might help clear up what I'm currently seeing as the worst remaining bug (or class of bug). Anyway, thanks for all your work on PySide! - Stephan From tismer at stackless.com Fri Nov 30 09:57:53 2012 From: tismer at stackless.com (Christian Tismer) Date: Fri, 30 Nov 2012 09:57:53 +0100 Subject: [PySide] Bug is worse - please ignore In-Reply-To: References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <50B620B3.9050208@wingware.com> <001b01cdcda6$6e8a8750$4b9f95f0$@gmail.com> <50B696E8.6020102@stackless.com> <000f01cdcde1$5dba2b70$192e8250$@gmail.com> <50B6E397.5070403@stackless.com> <000701cdce29$cb750fc0$625f2f40$@gmail.com> <50B77708.1020000@stackless.com> <000801cdce48$f767e200$e637a600$@gmail.com> <50B79D6B.90701@wingware.com> <50B7E44B.1080803@stackless.com> Message-ID: <50B87511.3090605@stackless.com> Nathan, I tried my example again today and have to admit that I can't reproduce the problem, myself. I had too many windows open last night and was misled. properties are ok, they don't create a reference (sigh, good) and I was messing up, because of my reduced vision. Sorry about this. cheers - chris On 30.11.12 03:43, Nathan Smith wrote: > I am very interested in this because I have a PySide application where > my widgets don't die gracefully (and destroyed isn't signalling their > death). I use properties heavily in my code, so I was excited when I > saw your email thinking they were the culprit. However, I just tried > your example using Python 2.7.1 and PySide 1.1.1, and I can't > reproduce the problem. My table prints "destroyed" immediately when I > call del m. Are you sure that "property" creates a reference? > > I did verify in my environment that onDestroy must be static to > function correctly. > > > On Thu, Nov 29, 2012 at 4:40 PM, Christian Tismer > > wrote: > > Hi friends, > > On 11/29/12 6:37 PM, Stephan Deibel wrote: > > Alexey Vihorev wrote: > >> Thanks, nice find, but... I hit the next hurdle trying to go this > >> way. The signal QObject.destroyed(obj) is passing no arguments > >> (probably because obj is already destroyed), so my static > method has > >> nothing to work on. Which kind of devaluates the whole idea, IMHO. > >> And in PyQt4 it*does* pass the object. Even more: in PyQt4 there is > >> no need for static method approach, as it works perfectly with > >> instance methods: > > > > Yea, you would have to bind the necessary data to the callback > like this: > > > > def on_destroy(val1=self.whatever, val2=self.something): > > print 'destroyed' > > self.destroyed.connect(on_destroy) > > > > Whether this is possible or useful in your case is of course > going to > > depend on the details of the code. > > > > Having 'destroyed' be emitted before the object is destroyed and > > getting the object reference as an arg makes more sense to me. > That is > > what PyQt seems to do and it is what QObject does under Qt using > C++, > > so I'd call this a bug in PySide. I've added > > https://bugreports.qt-project.org/browse/PYSIDE-129 > > This bug is only half of the story: > > We had that simple @staticmethod work-around. > But actually, the main reason seems to be that PySide suffers > any reference cycle. > > The tiny example again breaks as soon as I add a property: > > {code} > from PySide.QtCore import QAbstractTableModel, QObject > > class MyModel(QAbstractTableModel): > def __init__(self, *args): > super(MyModel, self).__init__(*args) > self.destroyed.connect(self.onDestroy) > > @staticmethod > def onDestroy(): > print('destroyed') > > @property > def hugo(self): > return 42 > > m = MyModel() > del m > {code} > > Remove the @property, and it works, again. > > Rule of thumb: > If you need anything like a property, use a normal Python class > and put your Qt object into it as an attribute. Otherwise your > program will tend to grow in memory ;-) > > Stefan, I added this code to your bug report. > > cheers - chris > > -- > Christian Tismer :^) > > Software Consulting : Have a break! Take a ride on > Python's > Karl-Liebknecht-Str. 121 : *Starship* > http://starship.python.net/ > 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de > phone +49 173 24 18 776 fax +49 > (30) 700143-0023 > PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 > BF04 > whom do you want to sponsor today? http://www.stackless.com/ > > _______________________________________________ > PySide mailing list > PySide at qt-project.org > http://lists.qt-project.org/mailman/listinfo/pyside > > -- Christian Tismer :^) Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpe at wingware.com Fri Nov 30 15:55:01 2012 From: jpe at wingware.com (John Ehresman) Date: Fri, 30 Nov 2012 09:55:01 -0500 Subject: [PySide] Problems with QStyle deletion In-Reply-To: <20121129210613.GA9824@a367.seegrid.com> References: <50A57216.5090700@wingware.com> <50B3B9C1.80401@wingware.com> <20121129210613.GA9824@a367.seegrid.com> Message-ID: <50B8C8C5.2090305@wingware.com> On 11/29/12 4:06 PM, Nik Melchior wrote: > On Mon, Nov 26, 2012 at 01:49:37PM -0500, John Ehresman wrote: >> On 11/15/12 5:52 PM, John Ehresman wrote: >>> I'm trying to fix a bug that causes segfaults if QApplication.style() and >>> QApplication.setStyle() are used repeatedly. I think the issue is: > > John, > > My application has random crashes due to QStyle objects as well. I had some > trouble tracking down the problem, and I originally thought it was related to > a bug that reported QNetworkReply objects being randomly returned. I added my > analysis to PySide bug #16, but I haven't seen any activity there. I think this a symptom of the same object lifecycle bug -- PySide doesn't always detect when a C++ object is no longer valid and when that happens a bad entry gets left in the hash table mapping C++ object addresses to Python wrapper objects. When another C++ object is created at the same address, PySide will find the bad entry in the hash table and reuse the old wrapper. A fix went into shiboken in June that fixes a few cases that can lead to this with event objects, but I don't know if there's been a release since then. Your bug with eventFilters sounds a lot like a bug I was seeing and the shiboken fix did seem to address them. I also think this problem might be solved more generically; I have a fix for QObject derived classes that I think might work. Other classes will need a different approach, but I do think something can be done for them. Cheers, John From hugo.lima at openbossa.org Fri Nov 30 18:33:41 2012 From: hugo.lima at openbossa.org (Hugo Parente Lima) Date: Fri, 30 Nov 2012 14:33:41 -0300 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <50B82A36.4010605@wingware.com> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <1648242.S8DW1gBXjX@hugodesktop> <50B82A36.4010605@wingware.com> Message-ID: <2087358.PEaWTMaoOh@hugodesktop> On Thursday, November 29, 2012 10:38:30 PM Stephan Deibel wrote: > Hugo Parente Lima wrote: > > Nowadays no one is paid to work on PySide, I'm the current maintainer of > > PySide but I'm no longer fixing bugs or coding anything, I just review > > patches and do releases when we have a significant amount of changes. > > > > I would like to step down as PySide maintainer as soon somebody raise the > > hand to be the new maintainer, but nobody seems to want this :-/. > > I suspect there are not many people out there that understand PySide > internals well enough yet to feel confident about reviewing patches. > > :-( But hopefully this will change over time. > > If you have any time to comment briefly on things like > http://lists.qt-project.org/pipermail/pyside/2012-November/000805.html > and > http://lists.qt-project.org/pipermail/pyside/2012-November/000822.html > it might help clear up what I'm currently seeing as the worst remaining > bug (or class of bug). I didn't answer those question because they need some investigations to check what's really happening and I don't have time or the will to do that at the moment :-/ This problem may be fixed just on typesystem, or maybe not, as I said, it needs further investigation, I don't have the answer right now. > Anyway, thanks for all your work on PySide! > > - Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From sdeibel at wingware.com Fri Nov 30 18:48:08 2012 From: sdeibel at wingware.com (Stephan Deibel) Date: Fri, 30 Nov 2012 12:48:08 -0500 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <2087358.PEaWTMaoOh@hugodesktop> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <1648242.S8DW1gBXjX@hugodesktop> <50B82A36.4010605@wingware.com> <2087358.PEaWTMaoOh@hugodesktop> Message-ID: <50B8F158.3020909@wingware.com> Hugo Parente Lima wrote: > I didn't answer those question because they need some investigations to check > what's really happening and I don't have time or the will to do that at the > moment :-/ > > This problem may be fixed just on typesystem, or maybe not, as I said, it needs > further investigation, I don't have the answer right now. OK, thanks. That alone is useful info! - Stephan From techtonik at gmail.com Fri Nov 30 22:08:37 2012 From: techtonik at gmail.com (anatoly techtonik) Date: Sat, 1 Dec 2012 00:08:37 +0300 Subject: [PySide] QObject.destroyed() is not emitted In-Reply-To: <2087358.PEaWTMaoOh@hugodesktop> References: <000901cdcc07$770e0fa0$652a2ee0$@gmail.com> <1648242.S8DW1gBXjX@hugodesktop> <50B82A36.4010605@wingware.com> <2087358.PEaWTMaoOh@hugodesktop> Message-ID: On Fri, Nov 30, 2012 at 8:33 PM, Hugo Parente Lima wrote: > On Thursday, November 29, 2012 10:38:30 PM Stephan Deibel wrote: > > Hugo Parente Lima wrote: > > > Nowadays no one is paid to work on PySide, I'm the current maintainer > of > > > PySide but I'm no longer fixing bugs or coding anything, I just review > > > patches and do releases when we have a significant amount of changes. > > > > > > I would like to step down as PySide maintainer as soon somebody raise > the > > > hand to be the new maintainer, but nobody seems to want this :-/. > > > > I suspect there are not many people out there that understand PySide > > internals well enough yet to feel confident about reviewing patches. > > > > :-( But hopefully this will change over time. > > > > If you have any time to comment briefly on things like > > http://lists.qt-project.org/pipermail/pyside/2012-November/000805.html > > and > > http://lists.qt-project.org/pipermail/pyside/2012-November/000822.html > > it might help clear up what I'm currently seeing as the worst remaining > > bug (or class of bug). > > I didn't answer those question because they need some investigations to > check > what's really happening and I don't have time or the will to do that at the > moment :-/ > > This problem may be fixed just on typesystem, or maybe not, as I said, it > needs > further investigation, I don't have the answer right now. Maybe when you have more time it is possible to write a little howto/tutorial to see how to investigate the code? Maybe other can do this too (or at least implement instruments to increase visibility). -- anatoly t. -------------- next part -------------- An HTML attachment was scrubbed... URL: