I put together this concept for the architecture of our proposed TACTIC client application, KitCAT:
The idea is to make the use of the collaboration features provided by TACTIC as smoothly integrated as possible into the artists’ creative applications, while maintaining one common interface for the KitCAT features, and only having to maintain one GUI application. Ideally, the artist will feel as if they are remaining in their application of choice, without the disrupting their “flow”.
The idea is that the program will include the KitCAT client application, but also a series of plugins for various common creative applications. The diagram shows three important apps that it should be possible to fully support this way: Blender (3D modeling and animation program), Ardour (digital audio workstation), and Krita (digital painting and drawing application). Programs that aren’t supported directly can still be supported through the file-based support, which can be included in the KitCAT application itself.
Python plugin scripting is brand-new in Krita with version 4, and it really is what will make this feasible. Gimp and Inkscape also have plugin scripting environments that we can probably adapt. Where the “KitCAT” launcher goes in the application interface is going to be somewhat dependent on the limitations of the plugin environment provided. In Inkscape, for example, it will pretty much have to appear on the “Extensions” menu. However, Blender and Krita provide completely scriptable UIs, so we can choose this to suit our needs. My current thought is that KitCAT should have a tab in the 3D View “Tools” panel in Blender. In single-windowed applications, a drop-down “KitCAT” menu will probably be good.
The plugins will be used to place “KitCAT” buttons or menus into the creative application itself. These may support a few quick tasks inside the plugin, but for most purposes, the plugin’s job will simply be to collect context and either launch or focus the KitCAT application window with the context loaded. The “context” is the metadata about the document being worked on: its name, technical parameters, and any other details that can be determined from the application. This will then be passed to the KitCAT application, which will collect the repository information relating to the object: whether it is checked into the DAMS, whether it is synchronized with it, any notes, tickets, or deadlines associated with it, and where it is along its workflow. The application can then bring up an interface, like the mock-ups we’ve shown before:
Since the Qt interface allows the use of color themes for the GUI, it should even be possible to choose a theme to match the application from which the window was launched, for a greater feeling of integration with it (although this is really just window-dressing).
Interprocess Communication
This all hinges pretty heavily on establishing interprocess communication between the plugins and a separate Python application for KitCAT itself. This may prove tricky, but it does seem to be possible for Blender and Krita, which have fairly complete Python standard libraries available. It looks like the best option for this will be a low-level sockets interface with (probably) JSON as the data exchange protocol. This appears to be supported on all major platforms and probably most scripting languages, so it should provide enough flexibility to cope with plugin limitations.
Special cases include:
- Launching the application (and loading the plugin) from the KitCAT application window.
- Launching the KitCAT application window from inside the creative application (if it isn’t already open).
- Connecting to the KitCAT application.
- Changing context intelligently
I’m uncertain whether there will be a problem of how to leave child processes open if the parent closes down (that will happen if the application is closed while KitCAT is still open, for example).
Specific Application Scripting Notes
- Blender has a very complete Blender Python API.
- Krita has a brand-new LibKis/SIP Based Python API.
- Ardour has a Lua Scripting Environment. I don’t know too much about it, but the documentation makes it sound like this is feasible — the only major concern I see is that there may be some sandboxing of Ardour plugins, which might make it hard to do the interprocess communications part (but at least Lua does seem to have support for this).
- Inkscape has a document-filtering scripting system which is almost like a Unix pipe, so it’s basically the same as supporting the SVG file format and will need to be integrated on the “Extensions” menu. There are also some Python modules for Inkscape extensions.
- Gimp Python Scripting seems to be very complete with access to the GTK GUI, though I don’t have much experience with it.
- There is experimental support for Audacity Plugins in C++, but this may be prohibitively difficult in the near term, so file-based support may be all we can do for now.
- Sadly, Kdenlive doesn’t seem to have much scripting support (other than video effects?), so this will have to remain file-based as well (using the Kdenlive project files).
This is not a really high priority project yet, but I’m continuing to research the design when I get a bit of time to work on it.
