Is there any online documentation or information on creating and deploying a custom Toolkit app when using the tk-config-basic setup? The online documentation for Adding an App on the SG Developers site is built around using the tk-config-default2 setup. The files and folders it outlines to edit do not exist in the basic setup.
Thanks for posting it here.
Our out-of-the-box integrations(the
tk-config-basic setup) are designed to run without the need to set up or modify any configuration files. When you use our out-of-the-box integrations, there’s nothing to administer, but Toolkit uses an implied Pipeline Configuration under the hood.
If you would like to take over the config and add a custom Toolkit app, you have to set up the advanced config ( meaning using the
tk-config-default2 setup) first and then do your customization from there.
We are not able to use the tk-config-default2 setup as we have no “top-level root folder for production data” as required in the core/roots.yml file. We use the tk-config-basic setup because it allows us to use Toolkit without the requirements of a LocalStorage root file location.
I have managed to get the application to load into Toolkit, but I am having problems finding an example app in the GitHub repo that does not use a dialog.py. Do you know of any apps I can take a look at that do not use a UI? The only way I am able to get it to work is to hack it using the tk-multi-starterapp. But, after my script runs the starterapp dialog window comes up. I am trying to get my app to run with no dialog window.
Here is the YouTube video I found that helped me get tk-config-basic working: https://youtu.be/5nRZ5GgcOnk
Well, I managed to get my app running with one last issue that I cannot get worked out. My app does not have a UI for input, but instead it does have a QFileDialog which allows the user to choose a folder location. Everything runs as expected, but when the script finishes running there is a “Python” process hanging around. I have a feeling it is because of the “parent” of the QFileDialog, but I do not know how to fix it. I tried using ‘self’ but that gives an error that
My code is:
QtGui.QFileDialog.getExistingDirectory(QtGui.QApplication.activeWindow(), "Root Dir", self.cwd, QtGui.QFileDialog.ShowDirsOnly | QtGui.QFileDialog.DontResolveSymlinks)
TypeError: 'PySide.QtGui.QFileDialog.getExistingDirectory' called with wrong argument types:
PySide.QtGui.QFileDialog.getExistingDirectory(SetRootDirApp, str, str, Options)
PySide.QtGui.QFileDialog.getExistingDirectory(PySide.QtGui.QWidget = None, unicode = QString(), unicode = QString(), PySide.QtGui.QFileDialog.Options = QFileDialog.ShowDirsOnly)
I have setup a GitHub repo with a very simple app to reproduce the problem:
You should be able to load this into your Toolkit dev repo and get the same results. When you run the app, it will open a file browser window. When you select a folder and accept, it will simply log the folder to the console output. But, there will also be a fantom Python application hanging around after it is closed. Anyone know how to get rid of/prevent that? Does it have anything to do with the QFileDialog parent?
How are you running the app?
A Toolkit engine wouldn’t usually start a new python process when launching an app, so I’m curious about what the steps you are taking to get this are.
One small tip I have when looking at your code is, you can call
self.logger instead of creating a logger object at the top of the script, though this won’t alter the behavior you are seeing in anyway.
The exact steps I am taking are:
- Launch SG Desktop
- Select a Project
- Click the “Folder Picker” button to run the App
- Select any folder and click [Choose]
Hello extra Python!
I managed to get the extra Python to close by adding
QtGui.QApplication.exit() to the end of my script!
Hmm, that shouldn’t be happening, I can’t replicate it on my side with your code.
Does it happen when you launch the Publish app from Desktop as well?
When you select a project in Shotgun Desktop, it will spawn off a new python process in which it will bootstrap the project config, and then report back to the main SG Desktop process.
All apps you launch on the project from within SG Desktop should be running within this spawned python process and not launching a new one.
QtGui.QApplication.exit() would mean it would kill the Qt Application for all future app launches unless you back out of the project and then jump back in again. I tested here and that breaks all future runs of any app within the project.
Yes, it happens when I launch the Publish app. It also happens when I launch the Toolkit Demo app. Looks like it is happening when I launch any app in Toolkit including DCCs.
That explains why I had to exit and re-enter the project between runs. I also tested this and the extra Python process is only visible on my Mac. When I run this on a Windows 10 machine it does not reproduce this issue.
I think the issue is with the “parent” of the QtGui. If I use
QtGui.QApplication.activeWindow() it works, but leaves behind a Python instance. If I use
self, it crashes because that is trying to set the parent to be the Class (SetRootDirApp). Which is not a QtGui class it is an Application. So, I guess I am just not sure what to set as the parent for
Thanks @mharris. I think the behavior you are seeing is expected and nothing to be concerned about, and nothing to do with your coding, but I’d like to confirm:
As I mentioned, a separate Python process will be spawned when you select the project, and on Mac it will show up on the launch bar:
Are you saying that you get an additional one after launching your app, so you actually see two showing up down there?
Does jumping out of the project close the python process? (It might take a few seconds for that to happen after leaving it.)
If not please can you confirm the version of Shotgun Desktop you are running by screen grabbing thee about box?
I guess that I never noticed that Python process when entering a Project in Toolkit. Yes, that was the one I was seeing and Project exit/enter kills and spawns another Python process.
Thank you for salvaging what little hair I have left…