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

Reply via email to