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 <nathan_ru...@hotmail.com> 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 <nathan_ru...@hotmail.com>
> 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 <mhen...@laika.com> 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" <vbshoo...@gmail.com>
>>> To: "Nuke Python discussion" <nuke-python@support.thefoundry.co.uk>
>>> 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
>>> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>>>
>>>
>>> _______________________________________________
>>> Nuke-python mailing list
>>> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>>>
>>
>>
>>
>> --
>> Jose Fernandez de Castro
>> _______________________________________________
>> Nuke-python mailing list
>> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>> _______________________________________________
>> Nuke-python mailing list
>> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
>
>
>
>
> --
> Jose Fernandez de Castro
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
--
Jose Fernandez de Castro
_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
