colorbleed Posted September 29, 2016 Report Share Posted September 29, 2016 Hey, We're looking to get some better integrations with ftrack into our own offline interfaces of our pipeline. At this moment we're working off of a great foundation in the studio with an explorer (browser), asset loader, app launcher and lots of other tools. The intentions now are to mix these up with ftrack, like pull thumbnails from ftrack and push information to ftrack upon publishes, etc. As such I'm wondering what way we should go about this. Widgets Would we be designing our own Widgets using the API completely from scratch? Or can we use widgets from connect in our own interfaces? Are the widgets in connect intended to be used that way? Things that would potentially make it easy to display thumbnails of an asset (or other information)? Connect Would the integrations require a running connect? Or when would we use it specifically? Integrating ftrack into our tools What's the best way to go about this? Any tips from the community are also very welcome! It would be great to have informational up-to-date widgets that are all built to be smoothly cached internally. Yet at this stage it's hard to see if I'm building from the ground up or if there are elements I can connect together to get up and running faster (and even share back?) Link to comment Share on other sites More sharing options...
Mattias Lagergren Posted September 30, 2016 Report Share Posted September 30, 2016 Hey, thank you for posting this on the forum - it will be interesting to hear what the community has to say! First of all I'd like to mention that we are working on revamped integrations and we intend to introduce new tools and widgets that are open sourced and shared with the Community. The current tools ftrack-connect-nuke, ftrack-connect-maya, etc., relies on widgets and panels from the ftrack-connect repository, https://bitbucket.org/ftrack/ftrack-connect. Some of the code that you find in ftrack-connect may be deprecated or removed when the new tools are out (the history and repository will still be there so you can always fork or use the older code base if needed). The new tools will also be built on the new ftrack-python-api, whereas the current integrations that uses ftrack-connect widgets are built with the legacy api. Using the new ftrack-python-api should do a lot for the performance of the new integrations. It also means that locations should be written in the new ftrack-python-api, but we will provide a compatibility layer to allow legacy locations to work with the new ftrack-python-api to make the transition smoother. 12 hours ago, colorbleed said: Widgets Would we be designing our own Widgets using the API completely from scratch? Or can we use widgets from connect in our own interfaces? Are the widgets in connect intended to be used that way? Things that would potentially make it easy to display thumbnails of an asset (or other information)? There are some ui widgets in the ftrack-connect repository that you could be using: https://bitbucket.org/ftrack/ftrack-connect/src/a59f367b2ce0c09f21eed66cae75fdd32c89cce8/source/ftrack_connect/ui/widget/?at=master They are however ~poorly documented and not something that we guarantee will remain the same. Quote Connect Would the integrations require a running connect? Or when would we use it specifically? It is not necessary to run Connect if you have your own app launcher and do not want to use it. The ftrack connect (package) that we provide on our website contains an app launcher, actions and also bundles our integrations. Link to comment Share on other sites More sharing options...
colorbleed Posted September 30, 2016 Author Report Share Posted September 30, 2016 Thanks for the elaborate reply. Quote The current tools ftrack-connect-nuke, ftrack-connect-maya, etc., relies on widgets and panels from the ftrack-connect repository, https://bitbucket.org/ftrack/ftrack-connect. Some of the code that you find in ftrack-connect may be deprecated or removed when the new tools are out (the history and repository will still be there so you can always fork or use the older code base if needed). The new tools will also be built on the new ftrack-python-api, whereas the current integrations that uses ftrack-connect widgets are built with the legacy api. Using the new ftrack-python-api should do a lot for the performance of the new integrations. It also means that locations should be written in the new ftrack-python-api, but we will provide a compatibility layer to allow legacy locations to work with the new ftrack-python-api to make the transition smoother. I think this is the biggest thing that has held me back from tackling this before when the new api was just released. Is there an ETA for this rebuild? At this stage it's hard to identify what will maintain backwards compatibility and as such how much rework I'll have to do over time. For now I'll likely work out some widgets (minor features) of my own and jump on the connect train when it's revamped. Link to comment Share on other sites More sharing options...
Konstantin Maslyuk Posted October 6, 2016 Report Share Posted October 6, 2016 Hi, we managed to reuse Connect Publisher widget and add some logic over it using Qt in 3dsmax, dynamicaly overload asset types, and statically fork Import Asset dialog. It is nothing can stop you from typing in python "from ftrack_connect.ui.widget import Publisher" (not sure that it is correct) create an instance of it and play with it. We found only that without Connect running it doesn't trigger media encoding after publishing. You have to dig into common.zip and library.zip (on Windows) python module libraries from ftrack-connect-package to get how it all actually works. It is all incorrect deal but it is only way as current isn't flex enought. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.