Ok, tested again, same result. The code gets called fine outside of nuke, but the signals do not trigger when running inside of Nuke. This might be related to my other thread (because it is related to pyqt's destructor methods), so I'll try to get a supporte PyQt install first and test again.
On Mon, Sep 30, 2013 at 10:28 PM, Jose Fernandez de Castro <[email protected]> wrote: > I think I did try something like what you mentioned, but I will give > it another go tomorrow. > > On Mon, Sep 30, 2013 at 10:28 PM, Jose Fernandez de Castro > <[email protected]> wrote: >> Sorry, I do have access to the source code, what I mean about the top >> level widget, is the actual Nuke window. >> >> On Mon, Sep 30, 2013 at 9:36 PM, Nathan Rusch <[email protected]> >> wrote: >>> Well, the only reason I ask if you have access to the source is because if >>> you do, you shouldn't have any trouble getting the top-level window or >>> widget... However, doing it that way means that any time someone closes a >>> tab with a docked GUI instance in it, your cleanup handler will be called, >>> which sounds like it isn't quite what you're after; QApplication.aboutToQuit >>> seems more appropriate. >>> >>> Are you already calling >>> `QtGui.qApp.aboutToQuit.connect(self.cleanupHandler)` or what have you in >>> your application's __init__ without success? >>> >>> >>> -Nathan >>> >>> >>> -----Original Message----- From: Jose Fernandez de Castro >>> Sent: Monday, September 30, 2013 9:21 PM >>> >>> To: Nuke Python discussion >>> Subject: Re: [Nuke-python] pyqt inside a python panel doesn't get close >>> signal >>> >>> It's a pretty big application with lots of calls to in house house >>> API's, so I can't post it as is, I'll see if I can simplify it to >>> something that makes sense. Just out or curiosity though, do you have >>> an example on how you are connecting those signals? Didn't save the >>> code that I tested, but was basically getting the triggers for both >>> signals 'destroyed' and 'aboutToQuit' when running the application >>> standalone in a terminal, but not as a panel inside of nuke. >>> >>> On Mon, Sep 30, 2013 at 8:35 PM, Nathan Rusch <[email protected]> >>> wrote: >>>> >>>> Sorry, I overlooked your last response. I'm confused though... do you not >>>> have the source code to this application/GUI tool? >>>> >>>> >>>> -Nathan >>>> >>>> >>>> -----Original Message----- From: Jose Fernandez de Castro >>>> Sent: Wednesday, September 18, 2013 6:15 PM >>>> >>>> To: Nuke Python discussion >>>> Subject: Re: [Nuke-python] pyqt inside a python panel doesn't get close >>>> signal >>>> >>>> Can't seem to get this to work, I've tried connecting both the >>>> 'destroyed' and 'aboutToQuit' signal and they do work outside of nuke, >>>> but not when running inside. How are you getting the 'top level' >>>> widget? >>>> >>>> On Wed, Sep 18, 2013 at 10:46 AM, Nathan Rusch <[email protected]> >>>> wrote: >>>>> >>>>> >>>>> OK, so the only real problem at this point is cleaning up when Nuke >>>>> quits. >>>>> In that case, I would first try refactoring your cleanup code out of the >>>>> closeEvent method and connecting it to one of: >>>>> >>>>> - The .destroyed signal of your UI's top-level widget (this will do >>>>> double-duty by also handling the case where a user closes the pane >>>>> without >>>>> closing Nuke). >>>>> - QCoreApplication.aboutToQuit >>>>> >>>>> If you used the latter, you would also obviously want to call the cleanup >>>>> method from your closeEvent as well to handle cases where the panel is >>>>> closed but Nuke is left open. >>>>> >>>>> >>>>> >>>>> -Nathan >>>>> >>>>> >>>>> -----Original Message----- From: Jose Fernandez de Castro >>>>> Sent: Tuesday, September 17, 2013 11:41 PM >>>>> >>>>> To: Nuke Python discussion >>>>> Subject: Re: [Nuke-python] pyqt inside a python panel doesn't get close >>>>> signal >>>>> >>>>> I have a closeEvent, which basically clears shared memory keys. The >>>>> shared memory keys are there to coordinate action between multiple >>>>> instances of the pyqt dialog/application running standalone or >>>>> embedded in other nuke sessions. Inside of nuke, it is running only as >>>>> a docked QWidget panel, and I want the cleanup to run on each closing >>>>> of nuke. However, the closeEvent does not seem to run upon just >>>>> closing the nuke session. I might end up implementing it with an >>>>> OnScriptClose callback if all else fails, but I just wanted to know if >>>>> there is a better way... >>>>> >>>>> On Tue, Sep 17, 2013 at 11:03 PM, Nathan Rusch <[email protected]> >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> I don't recall seeing this thread around, but unless I'm overlooking >>>>>> something, this shouldn't be a particularly hard problem to solve. >>>>>> >>>>>> What are you actually connecting to your cleanup handler slot? And when >>>>>> are >>>>>> you expecting the application to be cleaned up? When a dockable panel is >>>>>> destroyed? When the user clicks a certain button? Is this a problem in >>>>>> both >>>>>> modal and non-modal panel instances? The more information you can >>>>>> provide, >>>>>> the better. >>>>>> >>>>>> -Nathan >>>>>> >>>>>> >>>>>> -----Original Message----- From: Jose Fernandez de Castro >>>>>> Sent: Tuesday, September 17, 2013 8:26 PM >>>>>> To: Nuke Python discussion >>>>>> Subject: Re: [Nuke-python] pyqt inside a python panel doesn't get close >>>>>> signal >>>>>> >>>>>> >>>>>> Having this exact same problem at the moment, has anyone found any >>>>>> other solution? >>>>>> >>>>>> On Wed, Jan 18, 2012 at 1:31 PM, Micah Henrie <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I ended up creating a OnScriptClose callback to kill threads/save >>>>>>> settings >>>>>>> etc but it would be nice if the close signal was sent by nuke when it >>>>>>> shut >>>>>>> down. >>>>>>> >>>>>>> micah >>>>>>> >>>>>>> ________________________________ >>>>>>> From: "Dennis Martin" <[email protected]> >>>>>>> To: "Nuke Python discussion" <[email protected]> >>>>>>> Sent: Wednesday, January 18, 2012 1:02:02 PM >>>>>>> Subject: [Nuke-python] pyqt inside a python panel doesn't get close >>>>>>> signal >>>>>>> >>>>>>> >>>>>>> I have a large pyqt program that is multi-threaded that I am trying to >>>>>>> run >>>>>>> as a python panel. On closing this program, all the threads it created >>>>>>> need >>>>>>> to be killed. I handle this in the standalone version with: >>>>>>> self.connect(self, SIGNAL('triggered()'), self.closeEvent) >>>>>>> >>>>>>> Where closeEvent simply kills all my threads. >>>>>>> >>>>>>> This works fine when I run the program standalone or launched from a >>>>>>> menu >>>>>>> inside Nuke. The problem is when I make this into a python panel the >>>>>>> pyqt >>>>>>> instance no longer gets any signals when the panel is closed. >>>>>>> >>>>>>> I have used registerWidgetAsPanel to load the program as a panel: >>>>>>> nukescripts.registerWidgetAsPanel('eep_assetBrowser.MyWindow', 'Asset >>>>>>> Browser', 'com.eep.testWindow',create = True) >>>>>>> >>>>>>> So the question is how can I get the python panel to send a signal to >>>>>>> the >>>>>>> pyqt instance when it is closed? >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dennis A Martin >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Nuke-python mailing list >>>>>>> [email protected], http://forums.thefoundry.co.uk/ >>>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Nuke-python mailing list >>>>>>> [email protected], http://forums.thefoundry.co.uk/ >>>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jose Fernandez de Castro >>>>>> _______________________________________________ >>>>>> Nuke-python mailing list >>>>>> [email protected], http://forums.thefoundry.co.uk/ >>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>>>>> _______________________________________________ >>>>>> Nuke-python mailing list >>>>>> [email protected], http://forums.thefoundry.co.uk/ >>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Jose Fernandez de Castro >>>>> _______________________________________________ >>>>> Nuke-python mailing list >>>>> [email protected], http://forums.thefoundry.co.uk/ >>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>>>> _______________________________________________ >>>>> Nuke-python mailing list >>>>> [email protected], http://forums.thefoundry.co.uk/ >>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Jose Fernandez de Castro >>>> _______________________________________________ >>>> Nuke-python mailing list >>>> [email protected], http://forums.thefoundry.co.uk/ >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>>> _______________________________________________ >>>> Nuke-python mailing list >>>> [email protected], http://forums.thefoundry.co.uk/ >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>> >>> >>> >>> >>> -- >>> Jose Fernandez de Castro >>> _______________________________________________ >>> Nuke-python mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>> _______________________________________________ >>> Nuke-python mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> >> >> -- >> Jose Fernandez de Castro > > > > -- > Jose Fernandez de Castro -- Jose Fernandez de Castro _______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
