Totally!
On 8 October 2014 10:39, Fredrik Averpil wrote:
> Yes, totally agreed on such a practice.
>
> On Wed, Oct 8, 2014 at 10:57 AM, Justin Israel
> wrote:
>
>> Totally reasonable. What the application does at that point makes sense.
>> At least it wont make assumptions about how it is launc
Yes, totally agreed on such a practice.
On Wed, Oct 8, 2014 at 10:57 AM, Justin Israel
wrote:
> Totally reasonable. What the application does at that point makes sense.
> At least it wont make assumptions about how it is launched. You could
> always supply the parent (activeWindow()) via the men
Totally reasonable. What the application does at that point makes sense. At
least it wont make assumptions about how it is launched. You could always
supply the parent (activeWindow()) via the menu-specific code as opposed to
the core application code. That would mean your menu launches it one way,
Hm. That makes sense. I might revise that code, but any modal dialogs that
open up from it, I probably won't change.
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails
I agree. Just because you happen to launch it from a menu now, doesn't mean
someone won't try and use it via another approach. It may not always be
best to design the tool to expect that it will be launched through a
specific mechanism.
On Wed, Oct 8, 2014 at 9:26 PM, Marcus Ottosson
wrote:
> I
I know for a fact that this application I’m developing can only be launched
from the Maya/Nuke file menus (or the Maya shelf) by the user.
Until someone would like to extend your tool and try to script it. :) I’d
be careful, this is how tight-coupling is born.
On 8 October 2014 09:08, Fredrik A
I second that you should ask the API if you are not 100% certain from where
you are launching the UI. I know for a fact that this application I’m
developing can only be launched from the Maya/Nuke file menus (or the Maya
shelf) by the user. So in this case, it works fine to set the parent of my
UI
That’s a good point. I suppose the API is less likely to change, than the
objectName of the Maya window, which might even have that name set by
coincidence as many of Maya’s other widgets don’t have *any* namy, as can
be seen by the allWidgets() command.
On 6 October 2014 20:42, Justin Israel w
I wouldn't say its a performance thing. It's more just about whether you
want to discover the Maya main window yourself, or be told by the API
exactly where it is. If the objectName will never change, then you will end
up with the same result. If they say in the docs "'MayaWindow' will always
be th
QApplication.topLevelWidgets()
Perfect, looks great to me. Why go through a PySide/PyQt-dependent extra
layer of shiboken/sip wrapping when you could do this? And don’t tell me
it’s for performance, as this is a one-off. ;)
After all, looping through allWidgets() takes ~0.018 seconds.
start = ti
I'm not sure I would consider activeWindow() the "holy grail" since it has
circumstances where it will not return the Maya main window, depending on
how your tool was launched. If it happens to be launched when the main
window does not have focus, or if any other tools are running in top level
wind
That’s brilliant, Fredrik.
I did some tests and it looks like it’s returning the currently active
window (duh!), which in the case of running from the Script Editor is the
Script Editor window. Not sure it has any repercussions and shouldn’t be an
issue when *not* running from the Script Editor.
> Then it looks like you just stumbled upon a holy grail. :) Fetching this
> handle has always been a PITA and this looks simple and logical. Will be
> trying this out next. Thanks!
>
Nice, let me know how it works. I have only used this with QMainWindow and
QDialog. I don't think it will work with
It was something I came by over at stackoverflow… works great for me in
both Maya and Nuke (PySide), returns the active Maya window.
http://qt-project.org/doc/qt-4.8/qapplication.html#activeWindow
Then it looks like you just stumbled upon a holy grail. :) Fetching this
handle has always been a PIT
The difference here is that exec_(), as mentioned by Justin, will block
> until the window closes. Can be useful if you expect results from a window,
> such as in a save-dialog returning a path. However I think exec_ is only
> available on QDialog subclasses.
>
Ah yes. In my particular case, I don’
The difference here is that exec_(), as mentioned by Justin, will block
until the window closes. Can be useful if you expect results from a window,
such as in a save-dialog returning a path. However I think exec_ is only
available on QDialog subclasses.
What’s that QtGui.QApplication.activeWindow(
Guys, I was wrong (again). You can set a QMainWindow to modal using
setWindowModality(). The code below works for me in Maya:
class MyApp(QtGui.QMainWindow):
def __init__(self, parent=None):
super(MyApp, self).__init__(parent)
self.centralWidget = QtGui.QWidget(self)
s
You're welcome, Fredrik. :) Glad you got it sorted.
On 6 October 2014 12:05, Fredrik Averpil wrote:
> Thanks guys,
>
> So I think my main problem was I was inheriting QtGui.QMainWindow and not
> QtGui.QWidget or QtGui.QDialog. It seems you cannot load a QMainWindow as a
> modal window.
>
> I rea
Thanks guys,
So I think my main problem was I was inheriting QtGui.QMainWindow and not
QtGui.QWidget or QtGui.QDialog. It seems you cannot load a QMainWindow as a
modal window.
I really never quite grasped the concept of a modal window before, so
thanks for that link Marcus.
Regards,
Fredrik
--
I use this:
"""This Is A Template Of PySide Programs In Maya"""
from PySide.QtCore import *from PySide.QtGui import *
from maya import OpenMayaUIfrom maya import cmds
import shiboken
class Window(QDialog):
"""docstring for Window"""
def __init__(self, *args, **kwargs):
super(Windo
You can either set the modality setting as Marcus mentioned, or you can use
exec_() instead of show() which automatically does a modal window and also
blocks on the call until it is accepted or rejected.
On 6/10/2014 10:46 PM, "Marcus Ottosson" wrote:
> Hi Fredrik,
>
> This behaviour is called “
Hi Fredrik,
This behaviour is called “modality”. Have a look here:
- http://qt-project.org/doc/qt-4.8/qwidget.html#windowModality-prop
Best,
Marcus
On 6 October 2014 10:36, Fredrik Averpil wrote:
> Hi,
>
> You know how the save dialog locks up the Maya UI and only allows you to
> interac
Hi,
You know how the save dialog locks up the Maya UI and only allows you to
interact with the save dialog… do you know how can this be achieved when
loading up a custom PySide window?
I’m doing this at the moment, which makes sure that the custom ui stays on
top of Maya, but it doesn’t lock up t
23 matches
Mail list logo
