This feature allows users to display the image created by a particular task directly from the Tractor Dashboard interface by selecting "Preview Output Image" from the context menu (right-mouse). The images can be displayed directly by the browser itself, or in some cases through an external application running on the user's local desktop system. In either case, some site configuration is required.
Summary -- to enable a site-specific policy regarding image preview, administrators should review and likely modify the default preview handlers in the config file "trSiteDashboardFunctions.js" -- look for the callback function named "trSiteOpenPreviewLink".
There are a few system considerations to keep in mind when thinking about image previews through Tractor Dashboard:
There are two basic approaches to displaying images through the web-browser-based Tractor Dashboard. The simplest and safest one is for your web brower itself to fetch the images itself, directly from a web server on your network, like any other image on the web. The other approach is to install a custom image viewing plug-in on each user's desktop (or other web-browsing device), and then direct the plug-in to read load the image using its own custom mechanism for finding and displaying the pixels.
You can cause network mounts to appear "virtually" in the tractor-engine web document root by adding entries to the SiteURLMap configuration table, located in tractor.config. Each pair of paths in the table represents a mapping of reference relative to the engine's document root, to a location elsewhere on the filesystem. Frequently the added mappings take a simple "duplicate" form:
which maps http requests for images in "/tractor/net/assets/previews" to the filesystem location "/net/assets/previews".
A familiar example of such a thing is a web page containing a "mailto" URI like "mailto:firstname.lastname@example.org" in a link. When someone clicks on that link the browser has a special handler for the "mailto" scheme, which usually involves asking the underlying operating system to launch the user's favorite mail application.
Other built-in or 3rd-party browser extensions can also be invoked using this URI scheme mechanism. Tractor simply invokes the browser's "open" method on the URI supplied in the job's chaser command and assumes that the site administrators have coordinated both the job script generation and the available browser plug-ins to cause the desired application invocation on the user's desktop. These sorts of plug-ins can do many arbitrary things including reading local files on the browser's host, which of course can be very useful, and easily abused.
So with the URI handler approach, preview renders could write temporary images somewhere on the user's local desktop, for example, and the dashboard + plug-in combination could cause a full-function native display application to launch and display the image directly on the desktop. Globablly shared files are not necessarily required in this case, although the launched app could certainly use them if they are available. The disadvantages of the plug-in approach is that you will need a browser-specific version of the plug-in compiled for each workstation platform or other device on which you will be viewing the Tractor Dashboard web page. Also, if you are trying to preview a rendering while away from your desk, the local plug-in on your device must be able to access the output image by itself somehow, wherever it may be on the web.