Whoops, hit send too early. As for the problem that Ben mentioned of being left with an empty panel if you close your widget, I "naively" tried to iteratively look for the widget's parent until you find a QtGui.QStackedWidget, which seems to consistently lead to the widget holding the Panel's tabs (but again, I don't know if this is always the case. Just got lucky trying)
>From there, I call removeWidget() to remove the most immediate child, which seems to remove the panel's tab as well. Also, incidentally, while looking at the documentation for QtGui.QStackedWidget.removeWidget(), I found the following: QtGui.QStackedWidget.removeWidget(*w*) <https://deptinfo-ensip.univ-poitiers.fr/ENS/pyside-docs/PySide/QtGui/QStackedWidget.html#PySide.QtGui.PySide.QtGui.QStackedWidget.removeWidget> Parameters:*w* – PySide.QtGui.QWidget<https://deptinfo-ensip.univ-poitiers.fr/ENS/pyside-docs/PySide/QtGui/QWidget.html#PySide.QtGui.QWidget> Removes widget from the PySide.QtGui.QStackedWidget<https://deptinfo-ensip.univ-poitiers.fr/ENS/pyside-docs/PySide/QtGui/QStackedWidget.html#PySide.QtGui.QStackedWidget> . i.e., widget is *not* deleted but simply removed from the stacked layout, causing it to be hidden. Which might explain why closing a panel triggers a hideEvent() on all its widgets, but not a closeEvent() On Thu, Oct 24, 2013 at 12:12 AM, Ivan Busquets <ivanbusqu...@gmail.com>wrote: > 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 <ben.dick...@rsp.com.au>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<Nuke-python@support.thefoundry.co.uk>, >>>>>> 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<Nuke-python@support.thefoundry.co.uk> >>>> ,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<Nuke-python@support.thefoundry.co.uk>, >>> 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 | ben.dick...@rsp.com.au >> rising sun pictures | www.rsp.com.au >> >> ______________________________**_________________ >> Nuke-python mailing list >> Nuke-python@support.**thefoundry.co.uk<Nuke-python@support.thefoundry.co.uk>, >> 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, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
