Search the Community
Showing results for tags 'application'.
Found 2 results
-
Hi I'm developing currently in nuke, but my question extends to all connect supported applications. Is there anyway I can trigger a change in current context in respect to the ftrack apps such as "Working Task". We are currently implementing our own system for loading and publishing files, but we felt a few of the options in the ftrack menu were perfectly fine for our needs and we don't need to re implement them. However since our system allows us to change context without relaunching the application, I wondered how I might get the ftrack options to reflect this change in context. thanks Phil
-
Hi I'm trying to build tools that work around the context given in a certain application, such as nuke. The Issue that I have is that the current connect launch application actions don't provide a consistent context environment. For example nuke and maya, provides FTRACK_TASKID, FTRACK_SHOTID among other keys (I would consider not context based). But Nuke Studio doesn't provide any keys that are context based. It seems connect actions are designed to only provide the information that they feel is applicable to the ftrack tools running in the application, and with no consideration for requirements of other tools being written by 3rd parties. It would be nice if for example there was a "FTRACK_ENTITY" = "[TYPE];[ID]" sort of environment variable in every connect application, so that who ever is producing tools, could use it how they wish, and always be reliant on that variable existing. This would then free us up to make tools that weren't reliant on a Shot based work flow for example it could be any custom entity type then instead. I'm new to ftrack and come from a shotgun pipeline. I appreciate I don't have a full understanding of how things should work in ftrack, but I'm used to being able to launch an application in what ever context and then having my tools run off that. I also realise that I could write\modify the existing actions provided by ftrack, but that's not desirable due to updates and deployment of the code. Could this sort of thing be implemented or is there a different more preferred approach which I'm unaware of? Thanks Phil
