interestingly it often seems to find a previous instance on the first
call, then after that it always finds two instanced.
not always though - weird
but it does seem to work so far...
On 24/10/13 20:19, Ivan Busquets wrote:
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/)
Parameters: *w* -- PySide.QtGui.QWidget
<https://deptinfo-ensip.univ-poitiers.fr/ENS/pyside-docs/PySide/QtGui/QWidget.html#PySide.QtGui.QWidget>
Removeswidgetfrom thePySide.QtGui.QStackedWidget
<https://deptinfo-ensip.univ-poitiers.fr/ENS/pyside-docs/PySide/QtGui/QStackedWidget.html#PySide.QtGui.QStackedWidget>.
i.e.,widgetis/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 <mailto: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 <mailto:ben.dick...@rsp.com.au>> wrote:
Hm, this is not easy..
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
<mailto: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
<mailto: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
<mailto:Nuke-python@support.thefoundry.co.uk>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
--
ben dickson
2D TD | ben.dick...@rsp.com.au <mailto:ben.dick...@rsp.com.au>
rising sun pictures | www.rsp.com.au <http://www.rsp.com.au>
_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk
<mailto: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
_______________________________________________
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
