Just gave this a try as well, since the whole hideEvent / closeEvent has bitten me recently as well.
One thing I noticed is that hideEvent() gets called frequently while you drag your panel to a different pane, for example. So you want to be careful not to destroy anything during that event. As for the original question, though, I came up with this (not sure how bulletproof this will be, though) http://pastebin.com/Fqjyt1HX Instead of using the objectName, it just tries to match up the type of the current widget. I figure this should be safer, as you never know if other widgets will have the same name. On Wed, Oct 23, 2013 at 10:58 PM, Ben Dickson <[email protected]>wrote: > Hm, this is not easy.. > > https://gist.github.com/dbr/**7131354<https://gist.github.com/dbr/7131354>is > as far as I could get, > > ..but two problems: > > If you close the widget, you are left with an empty panel with no widgets. > I couldn't find a way to access the PythonPanel in order to close it > (closest I found was nuke.thisPane() or nuke.thisNode(), but nope) > > Second problem is you need to set _testwidget_instance=None when the panel > is closed, but as discussed in the the "pyqt inside a python panel doesn't > get close signal" thread above, hideEvent works but closeEvent is never > called > > > Writing your tool as a nukescripts.PythonPanel subclass might give enough > flexibility, your PySide UI would be added as a PyCustom_Knob (as done in > the panels.py code) > > > On 24/10/13 14:14, Frank Rueter wrote: > >> hm, every time I call a registered panel the first time, I find two >> objects with the respective ID e.g.: >> >> <PySide.QtGui.QWidget object at 0x31c95f0> <type 'PySide.QtGui.QWidget'> >> >> <__main__.TestWidget object at 0x31c9128> <class '__main__.TestWidget'> >> >> >> If other instances are open, I am getting more QWidgets listed, e.g.: >> >> <__main__.TestWidget object at 0x2338128> <class '__main__.TestWidget'> >> >> <PySide.QtGui.QWidget object at 0x233ec20> <type 'PySide.QtGui.QWidget'> >> <PySide.QtGui.QWidget object at 0x2341f80> <type 'PySide.QtGui.QWidget'> >> >> >> How can I now check which ones to close, because two of these belong to >> the panel I need to keep?! >> >> >> Here is my test code which might be flawed: >> >> http://pastebin.com/bp7w1BnP >> >> >> >> I might not be seeing the trees for the woods here... >> >> >> >> >> On 24/10/13 15:12, Frank Rueter wrote: >> >>> Cool, thanks Johan. That looks much simpler. Will give it a go as well... >>> >>> On 24/10/13 15:10, Johan Aberg wrote: >>> >>>> >>>> If you make sure your widgets are using setObjectName(), you could >>>> possibly look up the widgets by name like so to make sure only on >>>> instance is running: >>>> >>>> for widget in QtGui.QApplication.allWidgets(**) >>>> name = widget.objectName() >>>> if 'myWidgetName' in name: >>>> print name, type(widget) >>>> >>>> >>>> I think the registered panel will be of class<class >>>> 'PyQt4.QtGui.QDialog'> >>>> >>>> and the widget the PyCustom_Knob is pointing to<class >>>> 'PyQt4.QtGui.QWidget'> >>>> >>>> >>>> As far as I can see, the panel and widget object will be destroyed >>>> when the panel is closed. >>>> >>>> >>>> Johan >>>> >>>> On 24/10/13 13:40, Frank Rueter wrote: >>>> >>>>> Hi all, >>>>> >>>>> >>>>> has anybody had success with enforcing only one instance of a PySide >>>>> widget when it's registered as a panel? >>>>> >>>>> My app writes data to disk upon certain events and loads that data >>>>> again through the widget's constructor. So I need to make sure that >>>>> only one instance is open at any given time, otherwise I'm running >>>>> the risk of losing/corrupting that data. >>>>> >>>>> Any ideas? >>>>> >>>>> Cheers, >>>>> frank >>>>> ______________________________**_________________ >>>>> Nuke-python mailing list >>>>> Nuke-python@support.**thefoundry.co.uk<[email protected]>, >>>>> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> >>>>> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/** >>>>> nuke-python<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> >>>>> >>>> >>>> >>> >>> >>> ______________________________**_________________ >>> Nuke-python mailing list >>> Nuke-python@support.**thefoundry.co.uk<[email protected]> >>> ,http://**forums.thefoundry.co.uk/ <http://forums.thefoundry.co.uk/> >>> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-python<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> >>> >> >> >> >> ______________________________**_________________ >> Nuke-python mailing list >> Nuke-python@support.**thefoundry.co.uk<[email protected]>, >> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-python<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python> >> > > -- > ben dickson > 2D TD | [email protected] > rising sun pictures | www.rsp.com.au > > ______________________________**_________________ > Nuke-python mailing list > Nuke-python@support.**thefoundry.co.uk<[email protected]>, > http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> > http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-python<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
