Toolkit context menu items

Hello,

Is it possible, if so how, to add items to the Toolkit list in the entity right-click context menus?

Screen Shot 2020-04-29 at 11.53.08 AM copy

I tried adding {"type": "context_menu"} to the register_command on the engine, but that put my app in the Toolkit menu next to “Reload and Restart” and “Shotgun Python Console”. Is there a way to get it to the context menus for a given entity?

2 Likes

You are probably thinking of Action Menu Items

2 Likes

No, these are Toolkit items which show up in the context menu along side of the list AMIs. The little grey/green icon is the Toolkit icon and is written by SG without the need for any AMI service setup.

1 Like

Those context items are shown based on the settings of the shotgun engine for that entity.
You can add apps in shotgun.yml and any commands they have should show up.

I have had issues where those menus are cached and adding new commands to apps doesn’t cause the menu to rebuild itself.

2 Likes

Oh, that’s pretty cool, did not realize these come from the engine commands.

Is how to add/update these context menu items anywhere in the SG documentation?

1 Like

We don’t call them out specifically in the docs, as @jhultgre mentions, its just a case of adding the app to the tk-shotgun engine, like you would add it to the tk-desktop engine or any other engine.

However I’ll mention this to the team to see if there is a suitable place to mention this in our docs.

2 Likes

Cool! Do you happen to have an example of how/if I would be able to do this using the tk-config-basic setup?

1 Like

Sure!
So the tk-shotgun engine is added to all the root environment ymls for example:

and these point to:

And that is where the apps are being defined in the tk-shotgun engine.
So you just need to add your app definition/settings to that file and it should show up.

3 Likes

Thanks @philip.scadding, I can see what @jhultgre was saying about load reliability. I tried to add an App that we are hosting as an sg_uploaded_app on our SG site. It did not show up right away so I took that one out and tried adding one hosted locally using a dev descriptor. Then the first one with the ToolkitApp showed up, and it was not even in the config anymore. So, I cleared the browsing data and tried to load the SG pythonconsole from the app_store and all that managed to do was crash my Toolkit. LoL I have a feeling it is just a syntax issue with my descriptors.

1 Like

Yeah that is something that is on the list to document better as well.
That behaviour is expected though.
Basically on page load, it loads the cached items so that is it quick, and then sets about updating the cache if needed. So basically you need a double reload to see the changes.

It is a bit frustrating when testing things out, but its the trade off to allow quicker generation of menu items for the end user.

Hi @philip.scadding,

I managed to get the Toolkit App to show up in the right-click context menu for a Version:

But, I am not 100% confident when I make changes, that the updates are actually making it into what the action is running in the Shotgun web app. After getting this menu to show up on Version entities, I decided to change the init_app method, just to validate if this is what was controlling the entity_type. I changed this to “Playlist” and saved my file.

After several times refreshing the Desktop app and web browser, it is still showing up under Versions. I even tried deleting the ~/Library/Caches/Shotgun folder to completely reset Desktop, but that did not work. Is there a guranteed way to verify that I am actually getting the most recent code with updates and relaunch and not some cached version of the Toolkit app?

When I close the app and refresh the browser, the right-click menu displays the message Toolkit : Retrieving Actions... (click for details) for 5-10 minutes, or more. That makes the development time very painful. Especially when I am not 100% it’s even getting my new code…

When I execute the code I am getting this message in the output window:

import_framework could not determine the calling module layout! You can only use this method on items imported using the import_module() method!

But, I am not even importing any frameworks. I was at one time, when the menu item first showed up in the menu. But, I have removed the lines that setup the shotgunutils and qtwidgets frameworks:

# the frameworks required to run this app
frameworks:
    - {"name": "tk-framework-shotgunutils", "version": "v5.x.x"}
    - {"name": "tk-framework-qtwidgets", "version": "v2.x.x"}

Here is my current info.yml file:

# expected fields in the configuration file for this app
configuration:

    deny_permissions:
        type: list
        values: {type: shotgun_permission_group}
        allows_empty: True
        description: "An optional parameter which lets you limit the visibility of this app. 
                     If you for example put in ['Artist'] as the value for this parameter, 
                     any user belonging to the shotgun permissions group Artist will not be 
                     able to see or execute the App."
        
    deny_platforms:
        type: list
        values: {type: str}
        allows_empty: True
        description: "An optional parameter which lets you turn off this app on certain platforms. 
                     If you don't want it to appear on the Shotgun Pipeline Toolkit action menu for 
                     a platform, just include it in the the deny_platforms list. Valid values are 
                     Windows, Mac and Linux."    
        


# the Shotgun fields that this app needs in order to operate correctly
requires_shotgun_fields:

# More verbose description of this item 
display_name: "Download Image Files"
description: "Application to download Version images."

# Required minimum versions for this item to run
requires_shotgun_version:
requires_core_version: "v0.13.0"
requires_engine_version: "v0.1.0"

# the engines that this app can operate in:
supported_engines: [tk-shotgun]

Which is essentially just a direct copy of the info.yml from tk-shotgun-folders.

2 Likes

To help clear this up a bit, whilst the browser integration does cache the actions, it doesn’t cache the app specifically, so it should reload the changes each time you run it (if your app is setup with a dev/path descriptor). I think the problem you have here is a configuration issue, so it’s not showing up where you expect it to. I have a feeling there was an issue with adding it to Playlists specifically, I’ll ask someone to confirm. But remember it is the environment files that determine which environments your app shows up in.

In the cases where the app is showing, but running old code, it seems to me that it is probably pointing to a different version of your app than the one you are modifying, are you testing and modifying the correct config?

Yeah, that is too long. Unfortunately the more configurations you have the slower it will be. Try to limit the number of active configs on the project for you personally so that you can get better refresh times. The other thing to consider is where your user cache is stored, is it on the machine’s local hard drive? For other performance tips you can check out this doc though unfortunately, I didn’t have time to do one on browser integration specifically, that would be useful.

1 Like

Ah regarding Playlists, it was a bit different, it was discussed here:

1 Like

Hi @philip.scadding,

I changed to where I only have 2 site configs to my name. The Primary and my local dev sandbox. That got the Toolkit : Retrieving... time down to just under 4 min. Most users will only have Primary, so I guess that would be lessened for them.

I am not married to having my app show up in Playlists, that is just the first one I tried to get it to test not showing in Versions anymore. This particular app should eventually only land in Versions. But, I am not clear on what exactly is controlling that. I have the following line as part of my init_app() function in the app.py file:

"entity_types": ["Version"],

I changed that to Shot, Asset, Task, etc. But, that made no difference. Is that the wrong place to control this? I also removed that line, yet the app still showed up in all entity types that have the Enable Pipeline Toolkit/File Publishes on this entity box checked. Which file should I be adding something if I want it to only show up under Versions, but not all entities? I have added these lines to the env/includes/shotgun/all.yml file:

dvs-shotgun-download_versions:
  location:
    type: dev
    path: ~/pipeline/toolkit/apps/dvs-shotgun-download_versions

But, I do not see anything which controls which entity it should appear for in Shotgun. There does not appear to be a version.yml or a shot.yml or a asset.yml file in the tk-config-basic.

Thanks for the link on working with Custom Entities, as that will be the next step for a future app working on one of our customs.

1 Like

This is my env/includes/shotgun/all.yml file:

Do I have this (lines 37-40) setup correctly or should there be something added to the includes section up top (lines 15-19)? The last error I got when I ran my app was an error about not being able to find my engine download_versions. Here is my entire app.py script:

So, I tried updating line 37 of the all.yml file (see above) to simply read download_versions: and now the entire thing no longer shows up in any right-click action menu, where it was previously working. So, I changed it back to dvs-shotgun-download_versions:. After several rounds of closing Desktop, deleting the local cache folder, re-starting the browser, etc. I still cannot get the action item to show up in any of the right-click menus.

My neighbors are about to become the proud new owners of a 27" Apply cinema display in their front yard!

2 Likes

Hey @mharris

I’m sorry you’re having a tough time there, its late here and we a company wide holiday tomorrow.
I can help you look into it on Monday. It probably makes sense to open a support ticket and send us your logs so we can see whats going on, and a copy of your config.

After a quick glance at what you’ve provided I would say your shotgun/all.yml looks fine, but have you modified your pick_environment.py core hook in your config, so that it points at the correct environment file when the entity is Version?

1 Like

Hi @philip.scadding,

Monday would be fine. I have not modified the pick_environment.py file as I was not aware that I needed to do that. What modifications should I make to that file? Mine is currently exactly what is in the GitHub repo that you linked.

I know you said it was on the backlog to update the docs, but it would really be helpful if there was either a guide or a YouTube video on how to go about adding action items to the context menu in the Shotgun web browser.

3 Likes

OK I’ve taken a closer look at what is happening here.

So I don’t think that the pick_environment.py hook does need to be modified in this situation.
As you said it is exactly the same as the one in my link, which means it will be returning site when passed a Version entity. So assuming your site.yml is unchanged it will be pointing at the shotgun/all.yml, then all should be good there.

One thing you could do to ensure you’re in the right place, is to comment out the tk-multi-launchapp, double reload the page and then check to see if all the software entity launchers have disappeared.

I think what we need to see is your tk-desktop.log and tk-shotgun.log where debug has been enabled and the loading of actions reproduced. I’m expecting that there is an error in there somewhere. Could you please create a support ticket and attach those for us?

2 Likes

Ticket created: https://support.shotgunsoftware.com/hc/en-us/requests/113011

For this I commented out the tk-multi-launchapp block in the env/includes/shotgun/all.yml file and double re-freshed the page in the SG web interface. The action menu item is no longer even showing up for me:

2 Likes