(v13) Timeline context

This page applies to Harlequin v13.1r0 and later; both Harlequin Core and Harlequin MultiRIP

Another feature of timelines is that you can register or pin things onto a timeline.

When a timeline is created, as well as specifying the extent, the units and the title of the timeline, a context pointer is also provided. This context has a wide range of uses. In the case of the RIP core, when creating the core job timeline it attaches a reference to the internal core job structure. What this means is that for every handler that gets called with an event on that timeline it immediately has access to the contextual information for that timeline. It is possible to attach any number of separate pieces of information to a timeline, and third parties can attach there own information to timelines. For example, third party code that wants to keep track of things happening with page interpretation could use a handler that gets called when the interpret page timeline is started. It could then, for example, create its own structures, allocate memory and store some data.

Rather than having to keep track of that timeline and its memory structures, it can simply attach those structures to that timeline and then forget about it. The next time there is an event for that timeline it can use the “get context” call (SwTimelineGetContext) , from the timeline system to get its context back. This means that it doesn't have to do any of its own context management, and that disparate systems can share the same workspace and information without actually having any connection between them.

Because this is built on the Events system, it doesn't matter whether handlers are in the core, in the skin or in a plugin, they all get called in the appropriate order whenever there is an event generated by the timeline system.