How do I find out where a workspaceControl is docked in Maya 2018 Update 1?

[Anonymous]

Hey Folks!

I've been working on converting our old dockControl-based tool to function as a workspaceControl but have hit a wall in keeping track of how the user last used it, specifically being able to re-dock it to where the user last docked it.  It's being remembered and functioning fine if it's stored in the workspace layout, but only when switching to that workspace.

I know we can use dockToControl/dockToPanel/dockToMainWindow flags to dock the window and I can tell it's floating by querying floating flag.  How do I find out the dock data to use the dockTo flags?  Or is there another way to find and set where it's docked?

I'd hate to have to enforce our artists to have to conform to a single dock for the tools altogether, but it's approaching fast as the only practical option.  Anyone know how to use reflection with workspaceControl-generated docked windows?

I'm working in Maya 2018.1 and working with pymel mostly.

I appreciate any help or insight you may provide.

Hi @Anonymous your title 'How do I find out where a workspaceControl is docked?' was edited for clarity by @sean.heasley

[sean.heasley]

Hi @Anonymous

I'm not a programming expert so I'm a bit confused by your issue. Are you trying to set the tool so its docked to a specific location regardless of the current workspace?

Or is the issue that it is docking, but it's going to one place and you want to be able to change where its docked to?

When you get a chance, please update me with any new information or possibly a video of your issue and/or what you want to do!

If you need a video capturing program, Screencast is a great option that we use here at Autodesk

Let me know if anything changes!

[sean.heasley]

Hi @Anonymous

I'm just checking in to see if your still having this issue with the workspaceControl. When you get a chance, can you please update me with any new information or possibly a video of your issue and/or what you want to do!

If you need a video capturing program, Screencast is a great option that we use here at Autodesk

If you figured out the issue on your own, please post here and explain what steps you took so other users can see and learn from your solution!

[Anonymous]

Sorry for not getting back sooner, Canadian Thanksgiving took me away from computers for a few days.

I'm trying to set up for our artists to be able to set where our company tool set can be placed in their workflow that works best for them as it's not always required to be running.  To add it to tabbed panels, we have to use workspaceControl, but any initial calling of the tool causes it to be spawned as a floating window unless I explicitly tell it where to dock in the command.

How do I get it to react like Maya's system tools (where if I dock the "Tool Settings" panel on the right side and close it, it comes back on the right.  Likewise on the left or floating)

The minimal example works, somehow, but I can't find how I also mirror it's functionality.

My call:

self._win = pm.workspaceControl(dockName, retain=False, uiScript="import BBIToolbox\nBBIToolbox.curUI.BuildUI()", minimumWidth=250, closeCommand="import BBIToolbox\nBBIToolbox.CleanupUI()")

I used to have a "float=isFloating" flag with isFloating set to the stored last value.

[sean.heasley]

Hi @Anonymous

Glad to see you back and hope you had a nice holiday!

I've been doing some digging and I found this thread which might be of some help!

It looks like if you want the control to be in the same tab bar as the Channel Box and Attribute Editor for example, you have to use the –tabToControl flag.

string $channelsLayersDockControl = getUIComponentDockControl(“Channel Box / Layer Editor”, false);

workspaceControl –e –tabToControl $channelsLayersDockControl -1 yourWorkspaceControl;

I believe with this the tool should dock normally and stay docked but please let me know if it doesn't work and we can look into this further!

If one or more of these posts helped answer your question, please click Accept as Solution on the posts that helped you so others in the community can find them easily.

Kudos are greatly appreciated. Everyone likes a thumbs up!

[sean.heasley]

Hi @Anonymous

I'm just checking in again to see if you need more help with the workspace docking code. Did the link to the thread and code I provided yesterday help at all with docking your custom tool?

If so, please click Accept as Solution on the posts that helped you so others in the community can find them easily.

[Anonymous]

Thanks sean.heasly, I've been able to dock it to the available panels, but I have no way of evaluating what it's already docked to when quitting to save for future sessions.

It turns out the workspaceControl doesn't like to be told where to go and will remember where on its own unless you try to set any of them, but I get a wonderful error of it not recognizing the module it's contained in for some reason...  more work ahead.

[sandeep.nagireddy]

Hello,

Looks like you want to restore your custom workspace control to it’s previous position. You could do so with “-restore” flag.

cmds.workspaceControl(workspaceControlName, e=True, restore=True)  

When a workspace control is closed, it’s state is saved internally. This state will be used when you invoke the above flag.

Notice that this state is workspace specific and in each workspace it opens in a floating panel for the  first time unless specified to dock somewhere.

It would still open floating if Maya can’t find it’s state.

Hope this helps,

Sandeep

[sean.heasley]

Hi @Anonymous

I'm just checking in to see if you need more help with this. Did the you get a chance to try the steps @sandeep.nagireddy provided?

If your issue is resolved, please click Accept as Solution on the posts that helped you so others in the community can find them easily.

[Anonymous]

Here's some minimal code that seems to illustrate my failed attempt to work with workspaceControl:

# Save as BBTest.py in your Maya script path
import pymel.core as pm

WorkspaceName = 'WorkspaceWinBoo'

class BBTest(object):
    def StartUI(self):
        if pm.workspaceControl( WorkspaceName, query=True, exists=True) is False:
            pm.workspaceControl( WorkspaceName, uiScript = 'from BBTest import curUI\ncurUI.buildUI()', closeCommand='from BBTest import curUI\ncurUI.CloseUI()')
        else:
            pm.workspaceControl( WorkspaceName, edit=True, restore=True)
        
    def CloseUI(self):
        if pm.workspaceControl( WorkspaceName, query=True, exists=True):
            pm.workspaceControl( WorkspaceName, edit=True, close=True )
    
    
    def buildUI(self):
        WinLayout = pm.columnLayout( adjustableColumn=True )
        pm.button( label='Do Nothing' )
        pm.button( label='Close', command=pm.Callback(self.CloseUI) )

curUI = BBTest()

Run this:

import BBTest
BBTest.curUI.StartUI()

to start the ui or bring it up if it's hidden/buried somewhere.

I've tried altering the workspaceControl creation to use "retain=True" and "retain=False" with no real difference in it's failure.

So this (on my machine) will generate a UI panel that you can resize and dock, but when closed, it will not remember where it was.

As a side note, I've noticed that you can't easily change the creating workspaceControl's uiScript and have it retain it if you have "Autosave workspace on exit" turned on.  AFter the first quit, it will retain the old method and any further instantiations will try to use the old uiScript and not the new one.  I've only been able to fix it by manually editing the .json for the workspace and remove the entry for the workspaceControl.

I hope this helps to illustrate the problem.  If not, play with it, try quitting with the tool opened and docked (which will retain the dock for only the first run for me)

[sandeep.nagireddy]

Hi Kelly,

Please use the below example which is a custom worspace control made use of Maya mixin class.

You'll find comments where appropriate and let us know if this solved your problem.

# Copyright 2017 Autodesk, Inc. All rights reserved.
#
# Use of this software is subject to the terms of the Autodesk license
# agreement provided at the time of installation or download, or which
# otherwise accompanies this software in either electronic or hard copy form.

from maya.app.general.mayaMixin import MayaQWidgetDockableMixin
from maya import OpenMayaUI as omui
from PySide2.QtCore import *
from PySide2.QtGui import *
from PySide2.QtWidgets import *
customMixinWindow = None

''' MayaQWidgetDockableMixin is not a workspace control in itself, it is added
as a child to a created workspace control. See help(MayaQWidgetDockableMixin)
for more details. The following class is a simple widget with a layout and a push button.
'''
class DockableWidget(MayaQWidgetDockableMixin, QWidget):
def __init__(self, parent=None):
super(DockableWidget, self).__init__(parent=parent)
self.button1 = QPushButton()
self.button1.setText('PushMe')

layout = QVBoxLayout()
layout.addWidget(self.button1)
self.setLayout(layout)
self.setWindowTitle('Custom Maya Mixin Workspace Control')

''' A workspace control is created by calling show() on the DockableWidget class.
This control is only created once if the retain property is set to true, which
is the default. The uiScript argument passed to the show() method will be
invoked every time this control is opened/restored. It is recommended to add
the proper import statement in the uiScript argument.

For example, in renderSetup.py file the UIScript for renderSetupWindow is
"uiScript='import maya.app.renderSetup.views.renderSetup as renderSetup\nrenderSetup.createUI(restore=True)'"

The following method needs to be invoked in order to create the workspace control for the example above.
If the control is being restored, then Maya will call the method by passing restore=True
'''
def DockableWidgetUIScript(restore=False):
global customMixinWindow

''' When the control is restoring, the workspace control has already been created and
all that needs to be done is restoring its UI.
'''
if restore == True:
# Grab the created workspace control with the following.
restoredControl = omui.MQtUtil.getCurrentParent()

if customMixinWindow is None:
# Create a custom mixin widget for the first time
customMixinWindow = DockableWidget()
customMixinWindow.setObjectName('customMayaMixinWindow')

if restore == True:
# Add custom mixin widget to the workspace control
mixinPtr = omui.MQtUtil.findControl(customMixinWindow.objectName())
omui.MQtUtil.addWidgetToMayaLayout(long(mixinPtr), long(restoredControl))
else:
# Create a workspace control for the mixin widget by passing all the needed parameters. See workspaceControl command documentation for all available flags.
customMixinWindow.show(dockable=True, height=600, width=480, uiScript='DockableWidgetUIScript(restore=True)')

return customMixinWindow

''' Using the workspaceControl Maya command to query/edit flags about the created
workspace control can be achieved this way:
maya.cmds.workspaceControl('customMayaMixinWindowWorkspaceControl', q=True, visible=True)
maya.cmds.workspaceControl('customMayaMixinWindowWorkspaceControl', e=True, visible=False)

Note that Maya automatically appends the "WorkspaceControl" string to the
workspace control child object name. In this example it is the child widget name (customMayaMixinWindow)
'''

def main():
ui = DockableWidgetUIScript()
return ui

if __name__ == '__main__':
main()

Thanks,

Sandeep

[Anonymous · Accepted solution]

So I've finally tracked it down.  There are two issues at work here, one is if you define a closeCommand flag, it will no longer save workspaceControl state anymore.  Second issue is if you have autosave workspaces turned on (all are on by default), it will remember the last command altogether and not take any more changes to the command, even if you completely restart Maya.

The first issue makes sense, I just need to know what command I can call to force the saving of the workspaceControl from my closeCommand.

The second issue is a lot more nefarious as it makes it very challenging to change your instantiation call for workspaceControl at a later time without deleting the older instantiations from the workspaces it was contained in.  That in itself breaks any functional usage in a team-wide deployment as if there are ever any changes on scripts pushed out to the users, it will also have to wipe their workspace .json files of all references to that workspace to actually take the changes.

I'll close this issue on this note, but am relegated to not updating our control to workspaceControl as it's unreliable for a team-wide deployment of an actively developing tool.

Thanks Sean and Sandeep for your help.