diff --git a/doc/design/application/Config.txt b/doc/design/application/Config.txt index 9f01793e6..e30cb4a85 100644 --- a/doc/design/application/Config.txt +++ b/doc/design/application/Config.txt @@ -6,7 +6,7 @@ Lumiera Design: Application and Session Configuration The Lumiera application uses two quite different sources for configuration - individual __settings values__ can be loaded from an application- and user configuration in the conventional way -- various facilities, especially in the Proc-Layer, base the actual behavour on __queries__, which are +- various facilities, especially in the Steam-Layer, base the actual behavour on __queries__, which are to be resolve employing a rules based system '(planned)'. Configuration rules will be provided by the application (defaults), a session template and rules stored in the actual session. diff --git a/doc/design/architecture/TimeQuant.txt b/doc/design/architecture/TimeQuant.txt index 8b55cd2aa..320531981 100644 --- a/doc/design/architecture/TimeQuant.txt +++ b/doc/design/architecture/TimeQuant.txt @@ -188,7 +188,7 @@ context an object is encountered in. This solution might be too general and heavy weight at times though. Thus, for important special cases, the accessors should return tagged values, preferably even with differing static type. Time codes can be integrated this way, but most notably the *frame numbers* used -for addressing throughout the backend, can be implemented as such specifically +for addressing throughout the vault, can be implemented as such specifically typed tagged values; the tag here denotes the quantiser and thus the underlying grid -- it should be implemented as hash-ID for smooth integration with code written in plain C. diff --git a/doc/design/architecture/playRender.txt b/doc/design/architecture/playRender.txt index ffc12d42f..0f9060de5 100644 --- a/doc/design/architecture/playRender.txt +++ b/doc/design/architecture/playRender.txt @@ -149,7 +149,7 @@ instance, several life switching and reconfiguration operations might happen at the _model port_ (the place where data is retrieved from calculation), the output characteristics (framerate, direction) and the delivery goals (playback position, loop playing, scrubbing) all may be changed during playback -- we need a way for the player to ``cancel'' and -reconfigure the backend services. +reconfigure the vault layer services. Frame quantisation ^^^^^^^^^^^^^^^^^^ @@ -165,9 +165,9 @@ Thus, there are three fundamental guidelines when it comes to rounding: These may guide the process of finding the right place for the Quantiser(s) to apply. We need some information flows to be joined in order to be able to do the quantisation, which leaves us with just a few possible junction points -where to place quantisation: the backend, the GUI, the player and the session. +where to place quantisation: the Vault, the GUI, the player and the session. -- putting it into the backend seems to be the most reasonable at first sight: +- putting it into the vault layer seems to be the most reasonable at first sight: we can ``do away'' with nasty things soon, especially if they are technicalities, ``get a clean state soon'' -- and hasn't frame quantisation something to do with media data, which is handled in the backend? @@ -177,7 +177,7 @@ cleanliness, well, sigh! Doing rounding soon will leave us with a huge amount of degraded information flows throughout the whole system; as a consequence, the general rule is to do it as late as possible. Uncrippled information is an enablement. And last but not least: the frame quantisation is connected -to the _output_ format -- and the backend is likely within the whole +to the _output_ format -- and the vault layer is likely within the whole application the subsystem most remote and unaware of output requirements. - rounding/quantising in the GUI is extremely common within media applications; diff --git a/doc/design/backend/index.txt b/doc/design/backend/index.txt index 9e8c3826c..4ad72ac4e 100644 --- a/doc/design/backend/index.txt +++ b/doc/design/backend/index.txt @@ -1,5 +1,5 @@ -Design Documents: Backend -========================= +Design Documents: Vault +======================= What follows is a summary of Lumiera's *Data Handling Backend* @@ -11,17 +11,17 @@ data access. Within Lumiera, there are two main kinds of data handling: especially logging, replaying and ``Undo'' of all ongoing modifications.. * Media data is handled _frame wise_ -- as described below. -The backend uses *memory mapping* to make data available to the program. +The vault layer (backend) uses *memory mapping* to make data available to the program. This is somewhat different to the more common open/read/write/close file access, while giving superior performance and much better memory utilization. -The data backend must be able to handle more data than will fit into the memory +The Vault-Layer must be able to handle more data than will fit into the memory or even address space on 32 bit architectures. Moreover, a project might access more files -than the OS can keep open simultaneously, thus the for _Files used by the Backend,_ it needs a +than the OS can keep open simultaneously, thus the for _Files used by the Vault,_ it needs a *FilehandleCache* to manage file handle dynamically. Which parts of a file are actually mapped to physical RAM is managed by the kernel; it keeps a *FileMapCache* to manage the *FileMaps* we've set up. -In the End, the application itself only requests *Data Frames* from the Backend. +In the End, the application itself only requests *Data Frames* from the Vault. To minimize latency and optimize CPU utilization we have a *Prefetch thread* which operates a *Scheduler* to render and cache frames which are _expected to be consumed soon_. The intention @@ -62,7 +62,7 @@ low level File Descriptor and access Frames ~~~~~~ -+Frames+ are the smallest datablocks handled by the Backend. The application tells the Backend to make ++Frames+ are the smallest datablocks handled by the Vault. The application tells the Vault Layer to make Files available and from then on just requests Frames. Actually, those Frames are (references to) blocks of continuous memory. They can be anything depending on the usage of the File (Video frames, encoder frames, blocks of sound samples). Frames are referenced by a smart-pointer like object which manages the lifetime @@ -81,7 +81,7 @@ weak:: try to transform a weak reference into a readonly or readwrite reference -Frames can be addressed uniquely whenever a frame is not available. The backend can't serve a cached +Frames can be addressed uniquely whenever a frame is not available. The vault can't serve a cached version of the frame, a (probably recursive) rendering request will be issued. Prefetching @@ -92,9 +92,9 @@ There are 2 important points when we want to access data with low latency: The data which is backed in files has to be paged in and available when needed. The +Prefetch+ Thread manages page hinting to the kernel (posix_madvise()..) . Intermediate Frames must eventually be rendered to the cache. - The Backend will send +Renderjobs+ to the +Scheduler+. + The Vault Layer will send +Renderjobs+ to the +Scheduler+. -Whenever something queries a +Frame+ from the backend it provides hints about what it is doing. +Whenever something queries a +Frame+ from the vault it provides hints about what it is doing. These hints contain: * Timing constraints @@ -104,7 +104,7 @@ These hints contain: * action (Playing forward, playing backward, tweaking, playback speed, recursive rendering of dependent frames) .Notes -* The Backend will try to render related frames in groups. +* The Vault Layer will try to render related frames in groups. * This means that following frames are scheduled with lower priority. * Whenever the program really requests them the priority will be adjusted. diff --git a/doc/design/engine/PlayModes.txt b/doc/design/engine/PlayModes.txt index 815900d28..d616aff9e 100644 --- a/doc/design/engine/PlayModes.txt +++ b/doc/design/engine/PlayModes.txt @@ -39,7 +39,7 @@ triggering small atomic chunks of work in a ``just in time'' manner -- there is and built-in buffering beyond the low-level double buffering mechanisms utilised by most output facilities. Generally speaking, we prefer precise beforehand planning and discarding of untimely results over demand-driven and possibly blocking operations. Yet the buffer -management and frame cache provided by the backend for storing and passing of intermediary +management and frame cache provided by the vault for storing and passing of intermediary and final results allows for a certain amount of leeway. diff --git a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt b/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt index 8ff98e4dc..95491c40a 100644 --- a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt +++ b/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt @@ -250,8 +250,8 @@ type we get), or an custom condition or tag. Thus, generally the price to pay would be a more elaborate track head area, which actually is a collection of advice. Besides, of course it causes a lot -more work in the Proc Layer (which obviously I am willing to take or already try -to implement). And, finally, one price to pay is a steeper learning curve for +more work in the ``Proc Layer'' (which obviously I am willing to take or already +try to implement). And, finally, one price to pay is a steeper learning curve for anyone accustomed to the conventional approach. @@ -364,7 +364,7 @@ produce a strip of images taken from the footage, or just a single image (pivot image), or a colouring derived from motion detection etc. This way, all clip displays could be made to fit the same space in the GUI. -Regarding transitions, the Proc-Layer (with the use of the type information) has +Regarding transitions, the Steam-Layer (with the use of the type information) has to find out if an transition is applicable to a given pair of clips. If it is not, it will be flagged as error. Besides, we need an editor for tweaking the transition curve. Now we could consider differentiating this transition curve @@ -397,7 +397,7 @@ natively, without the need of a special "multicam-feature". Some thoughts: When a clip contains multiple media streams, we build an pipe for every stream actually sent to some output. Now the question is, what happens when attaching an effect (either attaching it directly to the clip, or placing the effect on a -track/trackgroup in a timerange touching this clip). Basically, Proc-Layer will +track/trackgroup in a timerange touching this clip). Basically, Steam-Layer will be able to determine if an effect is applicable at all. It won't try to wire in an sound effect into a video pipe. It won't wire an stereo reverb into a mono sound pipe. Thus, I would propose a pragmatic approach to this problem: Let the @@ -416,5 +416,5 @@ This page sumarises the state of the GUI Discussion in early 2009 + Since end of 2009, Gui development is mostly stalled (Joel left the project due to other obligations). Meanwhile we had a bit of discussion here and there, and personally I got a somewhat clearer understanding of what the Model in -Proc-Layer can / will provide. But basically that's along the lines of what +Steam-Layer can / will provide. But basically that's along the lines of what I wrote in my last comment at the bottom of this page diff --git a/doc/devel/rfc/ArchitectureOverview.txt b/doc/devel/rfc/ArchitectureOverview.txt index 116703b57..db930b6bc 100644 --- a/doc/devel/rfc/ArchitectureOverview.txt +++ b/doc/devel/rfc/ArchitectureOverview.txt @@ -20,11 +20,12 @@ link:http://www.lumiera.org/gitweb?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi. Description ~~~~~~~~~~~ - * the Application has three Layers: Backend, Proc and GUI + * the Application has three Layers: Vault, Steam and Stage.footnote:[at the + time of this writing, those three layers were named ``Backend'', ``Proc'' and ``GUI''] * the Application shall be completely functional without GUI (script-driven) * all IO, media data fetching, processing and bookkeeping falls within the - realm of the Backend - * all media object manipulation, deciding and configuration is the Proc + realm of the Vault Layer + * all media object manipulation, deciding and configuration is the Steam Layer's job * extensible by plugins on all levels, highly configurable, but not totally componentized (micro kernel) architecture diff --git a/doc/devel/rfc/DesignRenderNodesInterface.txt b/doc/devel/rfc/DesignRenderNodesInterface.txt index 201c34a72..5c59871bd 100644 --- a/doc/devel/rfc/DesignRenderNodesInterface.txt +++ b/doc/devel/rfc/DesignRenderNodesInterface.txt @@ -9,7 +9,7 @@ Design the Render Nodes interface --------------------------------- In the current design, the low-level model is comprised of "Render Nodes"; -Proc-Layer and Backend carry out some colaboration based on this node network. +Stean-Layer and Vault carry out some colaboration based on this node network. + Three different interfaces can be identified * the node wiring interface @@ -19,8 +19,8 @@ Three different interfaces can be identified Description ~~~~~~~~~~~ -Render Nodes are created and wired by the Builder in the Proc-Layer. On the -other hand, the rendering process is controlled by the backend, which also +Render Nodes are created and wired by the Builder in the Steam-Layer. On the +other hand, the rendering process is controlled by the vault layer, which also provides the implementation for the individual data processing tasks. To create a result, output nodes are ''pulled'' via the invocation interface, resulting in the affected nodes to recursively pull their predecessor(s). In the course @@ -28,8 +28,8 @@ of this call sequence, the nodes activate their processing function to work on a given set of buffers. Moreover, we plan to use the render network also for gathering statistics. -'''Note''': Render Node is an internal interface used by Proc-Layer and - activated by the Backend. Plugins are planned to be added via Adapter nodes. +'''Note''': Render Node is an internal interface used by Steam-Layer and + activated by the Vault. Plugins are planned to be added via Adapter nodes. Thus the Render Node interface needs ''not'' to be exported. @@ -73,8 +73,8 @@ the processing interface the individual nodes are configured to call a plain-C {{{process()}}} function and provide an array of buffer pointers to be used within this function. For the purpose of invoking actual data processing, it is irrelevant if this -function is implemented somewhere in the backend or provided by a plugin. At -this point, no type- and other meta-information is passed, rather the +function is implemented somewhere in the vault layer or provided by a plugin. +At this point, no type- and other meta-information is passed, rather the processing function is supposed to do The Right Thing ^TM^ @@ -84,7 +84,7 @@ Tasks * What services do we expect from Render Nodes. What do we plan to do with a render node? * What different kinds (if any) of Render Nodes can be foreseen? - * order the required functionality by Proc / Backend. Find out specific + * order the required functionality by Steam / Vault. Find out specific implementation constraints. * work out a design based on this informations @@ -102,10 +102,9 @@ The purpose of this Design Entry is to give a summary; the questions and the details of carrying out the operations are much more involved. + Please see the -http://www.lumiera.org/wiki/renderengine.html#Rendering[Proc-Layer impl -documentation (TiddlyWiki)] and the -http://www.lumiera.org/gitweb?p=lumiera/ichthyo;a=blob;f=src/proc/engine/procnod -.hpp;h=9cf3a2ea8c33091d0ee992ec0fc8f37bb5874d34;hb=refs/heads/proc[Source Code] +http://www.lumiera.org/wiki/renderengine.html#Rendering[Development internal doc (TiddlyWiki)] +and the +http://www.lumiera.org/gitweb?p=lumiera/ichthyo;a=blob;f=src/proc/engine/procnod.hpp;h=9cf3a2ea8c33091d0ee992ec0fc8f37bb5874d34;hb=refs/heads/proc[Source Code] for details (and/or contact Ichthyo for in-depth discussion of those technical details) diff --git a/doc/devel/rfc/EDLsAreMetaClips.txt b/doc/devel/rfc/EDLsAreMetaClips.txt index 9f474f124..3c58a3b29 100644 --- a/doc/devel/rfc/EDLsAreMetaClips.txt +++ b/doc/devel/rfc/EDLsAreMetaClips.txt @@ -105,7 +105,7 @@ Comments for sure. We always used the term '''meta-clip''' for this feature, thus I edited the headline (I hope you don't mind). * Regarding the implementation, I choose a slightly different approach for the - proc layer (actually, it's not yet there, but planned right from start, as I + ``proc layer'' (actually, it's not yet there, but planned right from start, as I consider this meta-clip feature to be of uttermost importance): I'd prefer to add it at the level of the media source which is used by a clip. The rationale is, that at the level of the clip, there is no (or almost no) @@ -139,7 +139,7 @@ Comments This is a real threat (see Cinelerra), but not limited to meta-clips. It is especially important, as you can expect users to work for months or years with a single session. Thus the integrity of the session is a value to be - protected. That's the rationale why I put up the constraint in the proc + protected. That's the rationale why I put up the constraint in the steam layer that all important objects can only be created or re-created by some specialized factory, which in turn has the responsibility of never creating a corrupted object. diff --git a/doc/devel/rfc/EngineInterfaceOverview.txt b/doc/devel/rfc/EngineInterfaceOverview.txt index e9e931661..8dd20378e 100644 --- a/doc/devel/rfc/EngineInterfaceOverview.txt +++ b/doc/devel/rfc/EngineInterfaceOverview.txt @@ -41,7 +41,7 @@ Render Process ~~~~~~~~~~~~~~ The render process brackets an ongoing calculation as a whole. It is not to be confused with a operating system process or thread; rather it is a point of -reference for the relevant entities in the GUI and Proc-Layer in need to +reference for the relevant entities in the GUI and Steam-Layer in need to connect to such a "rendering", and it holds the specific definitions for this calculation series. A render process _corresponds to a single data stream_ to be rendered. Thus, when the play diff --git a/doc/devel/rfc/FeatureBundle_PluggableModules.txt b/doc/devel/rfc/FeatureBundle_PluggableModules.txt index 06b9fe814..39958ca0d 100644 --- a/doc/devel/rfc/FeatureBundle_PluggableModules.txt +++ b/doc/devel/rfc/FeatureBundle_PluggableModules.txt @@ -112,7 +112,7 @@ individual Extension point to define when a Feature Bundle is fully usable, partially usable or to be rejected. For example, an "Effect" Feature Bundle may be partially usable, even if we can't load any "ProcFunction" for -the current platform, but it will be unusable (rejected) if the proc layer +the current platform, but it will be unusable (rejected) if the steam layer can't access the properties describing the media stream type this effect is supposed to handle. diff --git a/doc/devel/rfc/LumieraForwardIterator.txt b/doc/devel/rfc/LumieraForwardIterator.txt index d52554b7d..c61d71353 100644 --- a/doc/devel/rfc/LumieraForwardIterator.txt +++ b/doc/devel/rfc/LumieraForwardIterator.txt @@ -115,7 +115,7 @@ APIs should be written such as not tie them to the current implementation. Exposing iterators is known to create a strong incentive in this direction and thus furthers the creation of clean APIs. -Especially in Proc-Layer we utilise already several iterator implementations, +Especially in Steam-Layer we utilise already several iterator implementations, but without an uniform concept, these remain just slightly disguised implementation types of a specific container. Moreover, the STL defines various and very elaborate iterator concepts. Ichthyo considers most of these an diff --git a/doc/devel/rfc/MarbleMode.txt b/doc/devel/rfc/MarbleMode.txt index 3190df3bb..1a7be25c4 100644 --- a/doc/devel/rfc/MarbleMode.txt +++ b/doc/devel/rfc/MarbleMode.txt @@ -101,7 +101,7 @@ Tasks * make locked-together transports work * in the GUI (transport controls) * for coordinating the corresponding playback/render schedules (playback - controller, which is located in the backend according to our current + controller, which is located in the core according to our current planning) diff --git a/doc/devel/rfc/ProcBuilder.txt b/doc/devel/rfc/ProcBuilder.txt index 6762c98ed..ea8492220 100644 --- a/doc/devel/rfc/ProcBuilder.txt +++ b/doc/devel/rfc/ProcBuilder.txt @@ -1,5 +1,5 @@ -Design Process: Builder within the Proc-Layer -============================================= +Design Process: Builder within the Steam-Layer +============================================== [grid="all"] `------------`----------------------- @@ -8,15 +8,15 @@ Design Process: Builder within the Proc-Layer *Proposed by* link:Ichthyostega[] ------------------------------------- -Builder within the Proc-Layer ------------------------------ -One of the core ideas of the Proc-Layer (as being implemented since summer '07 +Builder within the Steam-Layer +------------------------------ +One of the core ideas of the Steam-Layer (as being implemented since summer '07 by Ichthyo) is the use of the Builder-pattern to achieve a separation between high-level view and low-level view. Description ~~~~~~~~~~~ -The Proc-Layer differentiates into a high-level view, which models the +The Steam-Layer differentiates into a high-level view, which models the properties of the problem domain (manipulating media objects), and a low-level model, which is a network of render nodes and will be optimized for processing efficiency. diff --git a/doc/devel/rfc/ProcHighLevelModel.txt b/doc/devel/rfc/ProcHighLevelModel.txt index 958ef95b3..e1da79534 100644 --- a/doc/devel/rfc/ProcHighLevelModel.txt +++ b/doc/devel/rfc/ProcHighLevelModel.txt @@ -6,14 +6,14 @@ ------------------------------------- -High-level model in the Proc-Layer ----------------------------------- +High-level model in the Steam-Layer +----------------------------------- The purpose of this link:DesignProcess[] entry is to collect together informations regarding the design and structure of the high-level model of -Lumiera's Proc-Layer. Most of the information presented here is already written +Lumiera's Steam-Layer. Most of the information presented here is already written down somewhere, in the -http://www.lumiera.org/wiki/renderengine.html#SessionOverview[Proc-Layer +http://www.lumiera.org/wiki/renderengine.html#SessionOverview[Development TiddlyWiki] and in source code comments. This summer, we had quite some discussions regarding meta-clips, a *container* concept and the arrangement of tracks, which further helped to shape the model as presented here. @@ -195,7 +195,7 @@ Pros Cons ^^^^ - * very tightly coupled to the general design of the Proc-Layer. Doesn't make + * very tightly coupled to the general design of the Steam-Layer. Doesn't make much sense without a Builder and a Rules-based configuration * not all semantic constraints are enforced structurally. Rather, it is assumed that the builder will follow certain patterns and ignore non diff --git a/doc/devel/rfc/ProcPlacementMetaphor.txt b/doc/devel/rfc/ProcPlacementMetaphor.txt index d25bc8c77..3f6ab4d4a 100644 --- a/doc/devel/rfc/ProcPlacementMetaphor.txt +++ b/doc/devel/rfc/ProcPlacementMetaphor.txt @@ -6,16 +6,16 @@ ------------------------------------- -Placement Metaphor used within the high-level view of Proc-Layer ----------------------------------------------------------------- +Placement Metaphor used within the high-level view of Steam-Layer +----------------------------------------------------------------- besides the [wiki:self:../ProcBuilder Builder], one of the core ideas of the -Proc-Layer (as being currently implemented by Ichthyo) is to utilize +``Proc-Layer'' (as being currently implemented by Ichthyo) is to utilize _Placement_ as a single central metaphor for object association, location and configuration within the high-level model. The intention is to prefer _rules_ over fixed _values._ Instead of ``having'' a property for this and that, we query for information when it is needed. -The proposed use of *Placement* within the proc layer spans several, +The proposed use of *Placement* within the steam layer spans several, closely related ideas: * use the placement as a universal means to stick the "media objects" together diff --git a/doc/devel/rfc/Roadmap-first.txt b/doc/devel/rfc/Roadmap-first.txt index 9ef045134..419d591a8 100644 --- a/doc/devel/rfc/Roadmap-first.txt +++ b/doc/devel/rfc/Roadmap-first.txt @@ -32,8 +32,8 @@ designed, the most important interfaces between the parts of the application exist in a first usable version, and all the facilities on the rendering code path are provided at least in a dummy version and are '''capable of cooperating to create output'''. Based on Lumiera's design, this also means that the basic -frame cache in the backend is working. And it means that a media asset and a -clip can be added to the internal session representation, which is then handed +frame cache in the vault layer is working. And it means that a media asset and +a clip can be added to the internal session representation, which is then handed over to the builder. Probably it's a good idea to include basic playback/display of the rendered frames within the GUI while they are created. diff --git a/doc/devel/rfc/SchedulerRequirements.txt b/doc/devel/rfc/SchedulerRequirements.txt index 239bd52d6..3f12c91c4 100644 --- a/doc/devel/rfc/SchedulerRequirements.txt +++ b/doc/devel/rfc/SchedulerRequirements.txt @@ -159,13 +159,13 @@ Rationale --------- //rationale: Give a concise summary why it should be done *this* way: We use a scheduler to gain flexibility in controlling various aspects of computation and I/O usage. -Moreover, we turn the scheduler into an interface between Backend and Proc-Layer; while the exact +Moreover, we turn the scheduler into an interface between the Vault and Steam-Layer; while the exact outfitting of the individual jobs highly depends on internals of the Session and Engine models, the properties of _actual job execution_, closely related to system programming are akin -to the Backend. The actual requirements outlined in this RfC are derived from the internals +to the Vault. The actual requirements outlined in this RfC are derived from the internals of the player implementation, while _the way_ these requirements are defined, and especially the aspects _omitted_ from specification are derived from knowledge regarding the possible -scheduler and backend implementation. +scheduler and vault layer implementation. //Conclusion diff --git a/doc/devel/rfc/StreamTypeSystem.txt b/doc/devel/rfc/StreamTypeSystem.txt index 12323606f..16347bcc0 100644 --- a/doc/devel/rfc/StreamTypeSystem.txt +++ b/doc/devel/rfc/StreamTypeSystem.txt @@ -14,7 +14,7 @@ Stream Type System ******************************************************************************** .Abstract -Especially in the Proc-Layer, within the Builder and at the interface to the +Especially in the Steam-Layer, within the Builder and at the interface to the Engine we need sort of a framework to deal with different »kinds« of media streams. + This is the foundation to be able to define what can be connected and to @@ -98,9 +98,9 @@ _library_ routines, which also yield a _type classification system_ suitable for their intended use. Most notably, for raw sound and video data we use the http://gmerlin.sourceforge.net/[GAVL] library, which defines a fairly complete classification system for buffers and streams. For the relevant operations in -the Proc-Layer, we access each such library by means of a Façade; it may sound +the Steam-Layer, we access each such library by means of a Façade; it may sound surprising, but actually we just need to access a very limited set of -operations, like allocating a buffer. _Within_ the Proc-Layer, the actual +operations, like allocating a buffer. _Within_ the Steam-Layer, the actual implementation type is mostly opaque; all we need to know is if we can connect two streams and get an conversion plugin. @@ -220,7 +220,7 @@ Comments -------- //comments: append below As usual, see the -http://www.lumiera.org/wiki/renderengine.html#StreamType[Proc-Layer impl doku] +http://www.lumiera.org/wiki/renderengine.html#StreamType[Development internal doc] for more information and implementation details. Practical implementation related note: I found I was blocked by this one in @@ -249,7 +249,7 @@ number, plus adding the capabilitiy of per frame metadata. This indices get abstracted by "indexing engines" it will be possible to have different kinds of indices over one file (for example, one enumerating single frames, one enumerating keyframes or gops). Such a indexing engine would be also the place -to attach per media metadata. From the proc layer it can then look like `struct +to attach per media metadata. From the steam layer it can then look like `struct frameinfo* get_frame(unsigned num)` where `struct frameinfo` (not yet defined) is something like `{ void* data; size_t size; struct metadata* meta; ...}` + -- link:ct[] 2008-10-06 diff --git a/doc/devel/rfc/TimelineSequenceOutput.txt b/doc/devel/rfc/TimelineSequenceOutput.txt index fe34edc7d..ec8b36b57 100644 --- a/doc/devel/rfc/TimelineSequenceOutput.txt +++ b/doc/devel/rfc/TimelineSequenceOutput.txt @@ -79,7 +79,7 @@ PlayController:: coordinating playback, cueing and rewinding of a _PlayheadCursor_ (or multiple in case there are multiple views and or monitors), and at the same time directing a render process to deliver the media data needed for playback. Actually, the implementation of the - PlayController(s) is assumed to live in the backend. + PlayController(s) is assumed to live in the application core. RenderTask:: basically a !PlayController, but collecting output directly, without moving a !PlayheadCursor (maybe a progress indicator) and @@ -148,7 +148,7 @@ image:{imgd}/ProjectTimelineSequenceUML.png[UML: Relation of Project, Timeline, Tasks ^^^^^ - * Interfaces on the GUI and Proc level need to be fully specified. + * Interfaces on the Stage and Steam level need to be fully specified. Especially, "Timeline" is now promoted to be a new top-level entity within the Session * communication between the PlayController(s) and the GUI need to be worked diff --git a/doc/technical/backend/index.txt b/doc/technical/backend/index.txt index 4e7c2bda9..c5b1241ee 100644 --- a/doc/technical/backend/index.txt +++ b/doc/technical/backend/index.txt @@ -1,7 +1,7 @@ -Technical Documentation: Backend -================================ +Technical Documentation: Vault +============================== -Here we collect bits of technical documentation for the Backend. +Here we collect bits of technical documentation for the Vault-Layer. For now, we have: diff --git a/doc/technical/code/linkingStructure.txt b/doc/technical/code/linkingStructure.txt index 0d4937bf4..ac42bcc53 100644 --- a/doc/technical/code/linkingStructure.txt +++ b/doc/technical/code/linkingStructure.txt @@ -245,12 +245,12 @@ to comply to that contract superficially. Dealing with the entities involved in effectively involves the internal functions of both sides. Which is in contradiction to a ``clean'' layer hierarchy. -For a more tangible example, lets assume our backend has to do some work on behalf of the GUI; -so the backend offers a contract to outline the properties of stuff it can work on. In compliance -with this contract, the GUI hands over some data entities to the backend to work on -- but by their -very nature, these data entities are and always remain GUI entities. When the backend invokes compliant +For a more tangible example, lets assume our vault layer has to do some work on behalf of the GUI; +so the vault offers a contract to outline the properties of stuff it can work on. In compliance +with this contract, the GUI hands over some data entities to the vault to work on -- but by their +very nature, these data entities are and always remain GUI entities. When the vault invokes compliant operations on these entities, it effectively invokes functionality implemented in the GUI. Which -makes the backend _binary dependent on the GUI_. +makes the vault layer _binary dependent on the GUI_. While this problem can not be resolved in principle, there are ways to work around it, to the degree necessary to get hierarchically ordered binary dependencies -- which is what we need to make a lower @@ -519,19 +519,19 @@ Relative dependency location ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Locating binary dependencies relative to the executable (as described above) gets complicated when several of _our own dynamically linked modules_ depend on each other transitively. For example, a plug-in might -depend on `liblumierabackend.so`, which in turn depends on `liblumierasupport.so`. Now, when we link +depend on `liblumieravault.so`, which in turn depends on `liblumierasupport.so`. Now, when we link `--as-needed`, the linker will add the direct dependency, but omit the transitive dependency on the support library. Which means, at runtime, that we'd need to find the support library _when we are -about to load the backend library_. With the typical, external libraries already installed to the +about to load the vault layer library_. With the typical, external libraries already installed to the system this works, since the linker has built-in ``magic'' knowledge about the standard installation locations of system libraries. Not so for our own loadable components -- recall, the idea was to provide a self-contained directory tree, which can be relocated in the file system as appropriate, without the need to ``install'' the package officially. The GNU dynamic linker can handle this requirement, though, if we supply an additional, relative search information _with the library pulling in the transitive -dependency_. In our example, `liblumierabackend.so` needs an additional search path to locate -`liblumierasupport.so` _relative_ to the backend lib (and not relative to the executable). For this -reason, our build system by default supplies such a search hint with every Lumiera lib or dynamic -module -- assuming that our own shared libraries are installed into a subdirectory `modules` below +dependency_. In our example, `liblumieravault.so` needs an additional search path to locate +`liblumierasupport.so` _relative_ to the vault layer lib (and not relative to the executable). +For this reason, our build system by default supplies such a search hint with every Lumiera lib or +dynamic module -- assuming that our own shared libraries are installed into a subdirectory `modules` below the location of the executable; other dynamic modules (plug-ins) may be placed in sibling directories. So, to summarise, our build defines the following `RPATH` and `RUNPATH` specs: diff --git a/doc/technical/gui/CodePolicy.txt b/doc/technical/gui/CodePolicy.txt index dbf547ad9..4627509c2 100644 --- a/doc/technical/gui/CodePolicy.txt +++ b/doc/technical/gui/CodePolicy.txt @@ -20,7 +20,7 @@ It is strictly prohibited to spawn other threads from within the event loop. We hold up a strict distinction between the _UI mechanics_ and the _core editing concerns_. The latter _must not be implemented within the UI-Layer._ Rather, you need to send an `act(CommandID)` message over the UI-Bus, which causes the corresponding -Proc-Layer command script to be dispatched within the Session thread. It is good +Steam-Layer command script to be dispatched within the Session thread. It is good practice to give an immediate visual clue regarding the fact of sending such a command (e.g. pressing a button). But be prepared that the actual feedback of invoking a command happens asynchronously. @@ -32,7 +32,7 @@ into the widgets. However, some widgets or controllers are special, insofar they correspond to and reflect some entities within the _Session model._ These special entities must be implemented as subclasses of `gui::model::Tangible`. These are always connected to the UI-Bus, and they are populated and mutated by receiving -diff messages pushed up from the Proc-Layer. +diff messages pushed up from the Steam-Layer. There is an _inner circle_ of UI backbone services. These are all mutually dependent on each other and their start-up sequence is intricate. Implement global and cross-cutting diff --git a/doc/technical/gui/GuiConnect.txt b/doc/technical/gui/GuiConnect.txt index 84458a8fc..9f0263c29 100644 --- a/doc/technical/gui/GuiConnect.txt +++ b/doc/technical/gui/GuiConnect.txt @@ -33,7 +33,7 @@ interface to collaborate. We may escape from that dichotomy when we cease to _rely on data as the fundamental substrate of our system._ To collaborate, both parts still need to share a structure, yet it suffices for this structure to be a _common -understanding:_ both the UI-Layer and the Proc-Layer need to share a common understanding how the parts of a editing +understanding:_ both the UI-Layer and the Steam-Layer need to share a common understanding how the parts of a editing session can be arranged. Yet they do not need to share a _common data representation_ of the session. The consequence is that both sides, ``the core'' and ``the UI'' remain autonomous within their realm. For some concerns, namely _the core concerns,_ that is editing, arranging, processing, the core is in charge and has absolute authority. @@ -46,17 +46,17 @@ The UI reflects these changes into _its own understanding and representation,_ w widgets. When the user interacts with these structures of the presentation layer, *action command messages* are generated, using the element-IDs to designate the arguments of the intended operation. Acting on these messages again causes reaction and change in the core, which is reflected back in the form of further diff messages. -Anatomy of the Proc/GUI interface ---------------------------------- +Anatomy of the Steam/Stage interface +------------------------------------ - the `GuiFacade` is used as a general lifecycle facade to start up the GUI and to set up the »Layer Separation - Interfaces«. The `GuiFacade` is implemented by a class _in Proc-Layer_ and loads the Lumiera GTK-UI as a plug-in. + Interfaces«. The `GuiFacade` is implemented by a class _in Steam-Layer_ and loads the Lumiera GTK-UI as a plug-in. - once the UI is running, it exposes the `GuiNotificationFacade`, to allow pushing state and structure updates up into the user interface. - in the opposite direction, for initiating actions from the UI, the Session Subsystem opens the `SessionCommandFacade`, which can be considered __ ``the'' public session interface.__ Both these primary interfaces operate *message based.* As immediate consequence, these interfaces are comparatively -narrow, and interactions can easily be serialised, enqueued and dispatched. On the Proc-Layer side, the `ProcDispatcher` +narrow, and interactions can easily be serialised, enqueued and dispatched. On the Steam-Layer side, the `ProcDispatcher` coordinates command execution and the _Builder run_ to derive the consequences of those session command invocations. And within the UI, the GTK-Event loop runs likewise single threaded, and the Notification facade automatically dispatches any invocation into the UI thread. diff --git a/doc/technical/infra/TestSupport.txt b/doc/technical/infra/TestSupport.txt index 5afcad052..6f06d758f 100644 --- a/doc/technical/infra/TestSupport.txt +++ b/doc/technical/infra/TestSupport.txt @@ -48,7 +48,7 @@ difficulties with tainted state. Test classes are organised into a tree closely mirroring the main application source code tree. Large sections of this test tree are linked together into *test libraries*. Some of these are linked against a specific (sub)scope of the application, like e.g. -only against the support library, the application framework or the backend. Since we +only against the support library, the application framework or the vault. Since we use _strict dependencies_, this linking step will spot code not being placed at the correct scope within the whole system. As a final step, the build system creates a *test runner* application (`target/test-suite`), which links dynamically against _all_ @@ -188,7 +188,7 @@ Options for running the Test Script (cd target; TESTSUITES=41 VALGRINDFLAGS=DISABLE TESTMODE=FAST+FIRSTFAIL ../tests/test.sh) -. invoking the buildsystem, rebuilding if necessary, then invoking just the proc-layer test collections:: +. invoking the buildsystem, rebuilding if necessary, then invoking just the steam-layer test collections:: scons VALGRIND=false TESTSUITES=4 check @@ -239,9 +239,9 @@ The currently employed numbering scheme is as follows |01 |Infrastructure, package consistency |10 |Basic support library functionality |20 |Higher level support library services -|30 |Backend Unit tests -|40 |Proc Layer Unit tests -|50 |User interface Unit tests (Gui, Scripting) +|30 |Vault Layer Unit tests +|40 |Steam Layer Unit tests +|50 |Stage Layer Unit tests (Gui, Scripting) |60 |Component integration tests |70 |Functionality tests on the complete application |80 |Reported bugs which can be expressed in a test case diff --git a/doc/technical/library/index.txt b/doc/technical/library/index.txt index 19a1ba716..67e0a7946 100644 --- a/doc/technical/library/index.txt +++ b/doc/technical/library/index.txt @@ -12,7 +12,7 @@ over time. Interface Library ----------------- The Lumiera Application is designed deliberately in a way to be controllable by scripts. All of -the Session, the models and the backend are fully operational without the GUI. Any significant +the Session, the models and the vault are fully operational without the GUI. Any significant functionality can be addressed through the primary Façade Interfaces. But, in order to make such an open and extensible application a reality, we need to build up diff --git a/doc/technical/overview.txt b/doc/technical/overview.txt index 594a44e27..1ca4bfadd 100644 --- a/doc/technical/overview.txt +++ b/doc/technical/overview.txt @@ -214,7 +214,7 @@ integration:: The player cares for the necessary integration with the other subsystems + it consults the _Output Management,_ retrieves the necessary informations from the _Session_ -and coordinates the forwarding of Backend calls. +and coordinates the forwarding of Vault-Layer calls. time quantisation:: The player translates continuous time values into discrete frame counts. @@ -244,7 +244,7 @@ and notifies any attached _change listeners_. .play process Ongoing effort to calculate a stream of frames for playback or rendering. + -The play process is an conceptual entity linking together several activities in the backend +The play process is an conceptual entity linking together several activities in the vault and the render engine. It maintains a registration entry for the process to keep track of associated entities, resources allocated and calls dispatched as a consequence. Besides each play process is wired to at leas one play-controller acting as frontend interface @@ -255,7 +255,7 @@ necessary to make the stream of calculations actually happen. The play process c within the player subsystem is largely comprised of organisational concerns and not especially performance critical. -- the backend is responsible for dispatching the calculation stream and scheduling calculation jobs +- the vault is responsible for dispatching the calculation stream and scheduling calculation jobs - the render engine has the ability to carry out individual frame calculations - the OutputSlot exposed by the output manager is responsible for accepting timed frame delivery @@ -300,8 +300,8 @@ dumb. Higher level management will be done by the Schedulers and Jobs. Engine Interface ~~~~~~~~~~~~~~~~ While on itself just a thin interface and adaptation layer forwarding calls to -the primary backend facilities, the Engine Interface is the primary point of service -accessed by Proc-Layer to use the backend services for rendering content. +the primary vault facilities, the Engine Interface is the primary point of service +accessed by Steam-Layer to use the vault layer services for rendering content. .Calculation Streams The Engine Interface is cast in terms of an _calculation stream_ entity. This is @@ -1008,7 +1008,7 @@ CLib wrappers Some wrapers for the C memory management functions malloc, calloc, realloc and free which never fail. In case of an error the resourcecollector in the -backend is invoked to free resources or doing an emergency shutdown. +vault is invoked to free resources or doing an emergency shutdown. Safe wrapers for some string functions from the C-library which also never fail. NULL strings are propagated to "" empty strings. diff --git a/doc/technical/proc/index.txt b/doc/technical/proc/index.txt index 42852a76f..af5f57e74 100644 --- a/doc/technical/proc/index.txt +++ b/doc/technical/proc/index.txt @@ -1,11 +1,11 @@ -Technical Documentation: Proc-Layer -=================================== +Technical Documentation: Steam-Layer +==================================== -Eventually, this section will hold technical documentation for the Proc-Layer. +Eventually, this section will hold technical documentation for the Steam-Layer. -Proc-Layer TiddlyWiki ---------------------- -Hermann Voßeler, core developer of the Proc-Layer uses an separate embedded wiki +Development Scrapbook TiddlyWiki +-------------------------------- +Hermann Voßeler, core developer of the Steam-Layer uses an separate embedded wiki for his day-to-day design sketches, notes and also for the more persistent planning. This *TiddlyWiki* is a nifty JavaScript wiki embedded in a single HTML page; as such it lives right within the source tree, where it can be worked on alongside with the diff --git a/doc/user/intro/intro.txt b/doc/user/intro/intro.txt index 15133e5be..569a966a0 100755 --- a/doc/user/intro/intro.txt +++ b/doc/user/intro/intro.txt @@ -215,7 +215,7 @@ In this section, we discuss the user's perspective when working with the GUI. Although Lumiera will initially ship with a standard, default GUI, we do not presume that this GUI will be suitable for all uses. We expect there to be multiple, different GUIs, each designed for different kinds of tasks. We expect that some of these will be written by users, and the -proc-layer is designed to facilitate this easily. +steam-layer is designed to facilitate this easily. Indeed, Lumiera can even work satisfactorily without a GUI, for example, for special purposes @@ -360,8 +360,8 @@ The material in this section provides a cursory view of features not required by a typical user, but of more importance to people looking under the hood (advanced users, software developers) -Most of the material in this section is to be found in the Proc-layer and in the -Backend. +Most of the material in this section is to be found in the Steam-Layer and in the +Vault. @@ -449,11 +449,11 @@ Input-Output Subsystem Lumiera will process large quantities of data and it is of critical importance to perform this efficiently. The input and output subsystem are all processed -in the backend, in fact, this is one very important function provided by the +in the vault layer, in fact, this is one very important function provided by the back end. The typical Lumiera user will have many clips, in various configurations located -at various places. All this data will have to be stored by the backend, +at various places. All this data will have to be stored by the vault layer, moreover all this data will have to be rapidly retrieved from storage and provided to the user. The demands on memory are high: huge chunks of data, that can be quickly stored and equally quickly fetched, even if stored over @@ -465,11 +465,11 @@ Lumiera will break down processes that need to be processed into smaller units called _frame job_. Typically, there will be many hundreds of jobs waiting for processing at any one time. These jobs are queued for processing and the order in which this is performed is managed by the _scheduler_. -This is all done in the backend. +This is all done in the vault layer. -Apart from memory, the backend will be responsible for accessing and saving +Apart from memory, the vault will be responsible for accessing and saving files. It is essential to do this efficiently. This will be carried out -in the backend using low-level mechanisms. +in the vault layer using low-level mechanisms. // file handling // vault, work, cache diff --git a/src/backend/backend.c b/src/backend/backend.c index a0f909b35..296887800 100644 --- a/src/backend/backend.c +++ b/src/backend/backend.c @@ -1,5 +1,5 @@ /* - Backend - common lumiera backend facilities + Backend - common lumiera vault layer facilities Copyright (C) Lumiera.org 2008, Christian Thaeter @@ -22,7 +22,7 @@ /** @file backend.c - ** Lumiera Backend: implementation of global initialisation and services. + ** Lumiera Vault-Layer: implementation of global initialisation and services. */ diff --git a/src/backend/backend.h b/src/backend/backend.h index 5eb00217f..ec601198a 100644 --- a/src/backend/backend.h +++ b/src/backend/backend.h @@ -1,5 +1,5 @@ /* - BACKEND.h - common lumiera backend definitions + BACKEND.h - common lumiera vault definitions Copyright (C) Lumiera.org 2008, Christian Thaeter @@ -22,7 +22,7 @@ /** @file backend.h - ** Lumiera Backend: global initialisation and definitions. + ** Lumiera Vault-Layer: global initialisation and definitions. */ diff --git a/src/backend/engine/job.cpp b/src/backend/engine/job.cpp index b3b1c1513..48a575a28 100644 --- a/src/backend/engine/job.cpp +++ b/src/backend/engine/job.cpp @@ -63,8 +63,8 @@ namespace engine { /** * emit the VTable for JobClosure within this compilation unit, - * which is still part of the backend. The actual job implementation - * classes are defined in the Proc-Layer + * which is still part of the Vault. The actual job implementation + * classes are defined in the Steam-Layer */ JobClosure::~JobClosure() { } diff --git a/src/backend/engine/job.h b/src/backend/engine/job.h index d294878d3..9fbfe5376 100644 --- a/src/backend/engine/job.h +++ b/src/backend/engine/job.h @@ -23,7 +23,7 @@ /** @file job.h ** Definition of a render job. - ** Jobs are defined within Proc-Layer and passed to the scheduler in the Back-end + ** Jobs are defined within Steam-Layer and passed to the scheduler in the Back-end ** for time bound invocation. This header defines the data structures used to describe ** a job, and the basic data structures used by the scheduler to keep track of individual ** jobs. Moreover, within the C++ part of this header, some classes are layered on top @@ -147,16 +147,16 @@ typedef lumiera_jobDefinition* LumieraJobDefinition; /** - * Description of a job. Jobs are passed by the Proc-Layer to the Back-End. + * Description of a job. Jobs are passed by the Steam-Layer to the Back-End. * * This descriptor record is used by the scheduler to organise job invocation. * The actual job's definition, i.e. the invocation parameter and the closure * necessary to invoke the job as a function is embedded (by value) * into this descriptor. * - * @remarks all fields of interest only to the backend, + * @remarks all fields of interest only to the vault layer, * except #jobDefinition, which is provided by and of - * interest to the Proc-Layer + * interest to the Steam-Layer * @note while this descriptor as such is self-contained, * the referred LumieraJobClosure needs to be allocated * and managed separately. Indeed, this closure happens @@ -167,7 +167,7 @@ struct lumiera_jobDescriptor_struct gavl_time_t deadline; ///< given in real wall clock time JobState jobState; - lumiera_jobDefinition jobDefinition; ///< of interest only to Proc-Layer + lumiera_jobDefinition jobDefinition; ///< of interest only to Steam-Layer /* == Job prerequisites == */ LList waiting; diff --git a/src/backend/engine/scheduler-frontend.hpp b/src/backend/engine/scheduler-frontend.hpp index d0c841be9..f0826d39f 100644 --- a/src/backend/engine/scheduler-frontend.hpp +++ b/src/backend/engine/scheduler-frontend.hpp @@ -45,8 +45,8 @@ namespace engine { /** * Access point to the scheduler service provided by the back-end. - * Proc-Layer uses this service as the primary means of instructing - * the backend; suitably prepared and wired frame render jobs are + * Steam-Layer uses this service as the primary means of instructing + * the vault; suitably prepared and wired frame render jobs are * handed over to the scheduler for time-bound or bandwidth-controlled * execution * @@ -55,7 +55,7 @@ namespace engine { * @todo this is planned to become the frontend * to the render node network, which can be considered * at the lower end of the middle layer; the actual - * render operations are mostly implemented by the backend + * render operations are mostly implemented by the vault layer * @todo define the low-level scheduler interface and hook in * the necessary calls to implement this frontend. * ////////TODO WIP as of 9/2013 diff --git a/src/backend/enginefacade.hpp b/src/backend/enginefacade.hpp index 1d0634f59..8f595821f 100644 --- a/src/backend/enginefacade.hpp +++ b/src/backend/enginefacade.hpp @@ -24,7 +24,7 @@ /** @file enginefacade.hpp ** Global control interface for the render engine subsystem. ** The render engine, as implemented in an combined effort by the - ** Lumiera backend and some parts of Proc-Layer, can be started and + ** Lumiera Vault-Layer and some parts of Steam-Layer, can be started and ** stopped as a [Subsystem](\ref subsys.hpp) of the whole application. */ @@ -41,15 +41,15 @@ namespace backend { /**************************************************************//** - * Interface to the backend layer (render engine subsystem): + * Interface to the vault layer (render engine subsystem): * Global access point for starting the render engine subsystem and * for defining the public interface(s) for talking with the engine. * - * While the engine is partially implemented relying on Proc-Layer + * While the engine is partially implemented relying on steam-Layer * operations, the general access point and the playback/render - * controller is considered part of the backend. This results in - * a "W"-shaped control flow: from GUI to backend to proc to - * backend, feeding resulting data to output. + * controller is considered part of the vault. This results in + * a "W"-shaped control flow: from stage to vault to steam to + * vault, feeding resulting data to output. * */ struct EngineFacade diff --git a/src/backend/media-access-facade.cpp b/src/backend/media-access-facade.cpp index 889150272..de4e97d05 100644 --- a/src/backend/media-access-facade.cpp +++ b/src/backend/media-access-facade.cpp @@ -50,14 +50,14 @@ namespace backend { if (isnil (name)) throw Invalid ("empty filename passed to MediaAccessFacade."); - UNIMPLEMENTED ("delegate to backend: query accessability of file"); + UNIMPLEMENTED ("delegate to vault: query accessability of file"); } ChanDesc MediaAccessFacade::queryChannel (MediaDesc& mHandle, uint chanNo) const { - UNIMPLEMENTED ("delegate to backend: query channel information"); + UNIMPLEMENTED ("delegate to vault: query channel information"); ChanDesc nix; return nix; } diff --git a/src/backend/media-access-facade.hpp b/src/backend/media-access-facade.hpp index c398f003d..6ebb081d7 100644 --- a/src/backend/media-access-facade.hpp +++ b/src/backend/media-access-facade.hpp @@ -54,10 +54,10 @@ namespace backend { /**************************************************************//** - * Interface to the backend layer: + * Interface to the vault layer: * provides functions for querying (opening) a media file, * detecting the channels or streams found within this file etc. - * Implementation delegating to the actual backend functions. + * Implementation delegating to the actual vault layer functions. * * convention: data passed by pointer is owned by the originator; * it should be copied if needed beyond the control flow diff --git a/src/backend/netnodefacade.hpp b/src/backend/netnodefacade.hpp index d4090c6b8..49cb7efa0 100644 --- a/src/backend/netnodefacade.hpp +++ b/src/backend/netnodefacade.hpp @@ -41,7 +41,7 @@ namespace backend { /**************************************************************//** - * Interface to the backend layer (renderfarm node): + * Interface to the vault layer (renderfarm node): * Global access point for starting a server listening on a TCP port * and accepting render tasks. Possibly such a server could also * use the backend file/media access functions to provide a media diff --git a/src/backend/real-clock.cpp b/src/backend/real-clock.cpp index aecf4d883..ea3cd6fc5 100644 --- a/src/backend/real-clock.cpp +++ b/src/backend/real-clock.cpp @@ -25,9 +25,9 @@ ** Implementation of simplified access to the current wall clock time. ** ** @todo just a rough draft as of 2012 / 2017 - ** @todo the idea was that the backend has elaborate knowledge about + ** @todo the idea was that the vault has elaborate knowledge about ** timings and time progression; upper layers should thus be able - ** to fulfil their timing needs by querying the backend + ** to fulfil their timing needs by querying the vault layer */ diff --git a/src/backend/real-clock.hpp b/src/backend/real-clock.hpp index a227aa6ae..47ad1f7d2 100644 --- a/src/backend/real-clock.hpp +++ b/src/backend/real-clock.hpp @@ -22,7 +22,7 @@ /** @file real-clock.hpp ** Front-end for simplified access to the current wall clock time. - ** The implementation relies on Lumiera backend functions to access the + ** The implementation relies on Lumiera vault functions to access the ** system clock with a sufficient level of precision. The result is ** delivered in lumiera's internal \link lib::time::Time time format \endlink ** diff --git a/src/backend/scriptrunnerfacade.hpp b/src/backend/scriptrunnerfacade.hpp index e6d46e58b..13be5a2f4 100644 --- a/src/backend/scriptrunnerfacade.hpp +++ b/src/backend/scriptrunnerfacade.hpp @@ -41,7 +41,7 @@ namespace backend { /*******************************************************************//** - * Interface to the backend layer (script runner): + * Interface to the vault layer (TODO 2018 really?) (script runner): * Global access point for starting a script within Lumiera application * context. * diff --git a/src/backend/thread-wrapper.hpp b/src/backend/thread-wrapper.hpp index 9595927cc..775f27182 100644 --- a/src/backend/thread-wrapper.hpp +++ b/src/backend/thread-wrapper.hpp @@ -24,7 +24,7 @@ /** @file thread-wrapper.hpp ** Convenience front-end for basic thread handling needs. - ** The Lumiera backend contains a dedicated low-level thread handling framework, + ** The Lumiera vault contains a dedicated low-level thread handling framework, ** which is relevant for scheduling render activities to make best use of parallelisation ** abilities of the given system. Typically, the upper layers should not have to deal much ** with thread handling, yet at some point there is the need to implement a self contained @@ -68,7 +68,7 @@ namespace backend { /************************************************************************//** * A thin convenience wrapper for dealing with threads, - * as implemented by the threadpool in the backend (based on pthread). + * as implemented by the threadpool in the vault (based on pthread). * Using this wrapper... * - helps with passing data to the function executed in the new thread * - allows to bind to various kinds of functions including member functions diff --git a/src/backend/threadpool-init.hpp b/src/backend/threadpool-init.hpp index 303ec1e00..6186c0488 100644 --- a/src/backend/threadpool-init.hpp +++ b/src/backend/threadpool-init.hpp @@ -22,12 +22,12 @@ */ /** @file threadpool-init.hpp - ** Automatically bring up the threading management and threadpool in the backend. + ** Automatically bring up the threading management and threadpool in the vault layer. ** This works by registering a lifecycle callback, which is activated at the start ** of main or when running the testsuite. Similarly, a shutdown hook is registered. ** ** @todo as of 1/10 it is not clear if this will be the final solution. - ** Alternatively, we may rely on a subsystem "backend" or "threadpool" + ** Alternatively, we may rely on a subsystem "vault" or "threadpool" ** ** @see threads.h ** @see thread-wrapper.hpp diff --git a/src/backend/threads.h b/src/backend/threads.h index cf30bcc69..ed4fafb66 100644 --- a/src/backend/threads.h +++ b/src/backend/threads.h @@ -73,7 +73,7 @@ enum lumiera_thread_class // .. various thread flags follow /** - * flag to let the decision to run the function in a thread open to the backend. + * flag to let the decision to run the function in a thread open to the vault. * depending on load it might decide to run it sequentially. * This has some constraints: * The Thread must be very careful with locking, better don't. diff --git a/src/common/advice.hpp b/src/common/advice.hpp index b8e31541e..1b2f73121 100644 --- a/src/common/advice.hpp +++ b/src/common/advice.hpp @@ -76,7 +76,7 @@ ** ** @note as of 6/2010 this is an experimental setup and implemented just enough to work out ** the interfaces and gain practical usage experiences. Ichthyo expects this collaboration - ** service to play a central role at various places within proc-layer. + ** service to play a central role at various places within steam-layer. ** @todo allow variables in binding patterns ** @todo use the lumiera MPool instead of heap allocations ** @todo consider to provide variations of the basic behaviour by policy classes diff --git a/src/common/advice/binding.hpp b/src/common/advice/binding.hpp index 699e113db..ff83d9a8d 100644 --- a/src/common/advice/binding.hpp +++ b/src/common/advice/binding.hpp @@ -59,7 +59,7 @@ ** obviously this is the foundation of a more generic system to deal with predicate terms. ** @note as of 4/2010 this is an experimental setup and implemented just enough to work out ** the interfaces. Ichthyo expects this collaboration service to play a central role - ** at various places within proc-layer. + ** at various places within steam-layer. ** @todo for now, \em only the case of a completely constant (ground) pattern is implemented. ** Later we may consider to extend the binding patterns to allow variables, which, on match ** could be fed as parameters to the bound advice. But this extension requires to extend diff --git a/src/common/advice/index.hpp b/src/common/advice/index.hpp index 6be0a2aa5..4b7f4bb71 100644 --- a/src/common/advice/index.hpp +++ b/src/common/advice/index.hpp @@ -65,7 +65,7 @@ ** ** @note as of 4/2010 this is an experimental setup and implemented just enough to work out ** the interfaces. Ichthyo expects this collaboration service to play a central role - ** later at various places within proc-layer. + ** later at various places within steam-layer. ** @note for now, _only_ the case of a completely constant (ground) pattern is implemented. ** Later we may consider to extend the binding patterns to allow variables. The mechanics ** of the index are designed right from start to support this case (and indeed the index diff --git a/src/common/config-rules.hpp b/src/common/config-rules.hpp index 45bf3b664..f41b6dffd 100644 --- a/src/common/config-rules.hpp +++ b/src/common/config-rules.hpp @@ -53,7 +53,7 @@ ** @see lumiera::Query ** @see mobject::session::DefsManager ** @see asset::StructFactory - ** @see config-resolver.hpp specialised setup for the Proc-Layer + ** @see config-resolver.hpp specialised setup for the Steam-Layer ** @see fake-configrules.hpp currently used dummy-implementation ** */ @@ -146,7 +146,7 @@ namespace lumiera { }; /** - * the "front side" interface: the Proc-Layer code can + * the "front side" interface: the Steam-Layer code can * use this QueryHandler to retrieve instances of the * type TY fulfilling the given Query. To start with, * we use a mock implementation. diff --git a/src/common/query.hpp b/src/common/query.hpp index 34196fdfa..25c6394c2 100644 --- a/src/common/query.hpp +++ b/src/common/query.hpp @@ -63,7 +63,7 @@ ** @see lumiera::QueryResolver ** @see mobject::session::DefsManager ** @see asset::StructFactory - ** @see config-resolver.hpp specialised setup for the Proc-Layer + ** @see config-resolver.hpp specialised setup for the Steam-Layer ** @see fake-configrules.hpp currently used dummy-implementation ** @see SessionServiceExploreScope ** @see PlacementIndexQueryResolver diff --git a/src/common/query/defs-manager-impl.hpp b/src/common/query/defs-manager-impl.hpp index 6e95796ef..4771d12c8 100644 --- a/src/common/query/defs-manager-impl.hpp +++ b/src/common/query/defs-manager-impl.hpp @@ -28,7 +28,7 @@ ** include to create explicit template instantiations with the concrete types to be used ** for definition and retrieval of default-configured objects. ** - ** For the standard use-case within the session / Proc-Layer, this is performed for the + ** For the standard use-case within the session / Steam-Layer, this is performed for the ** core MObject types, alongside with the definition of the generic config-query-resolver. ** ** @see config-resolver.cpp definition of the explicit specialisations for the session diff --git a/src/gui/ctrl/bus-term.hpp b/src/gui/ctrl/bus-term.hpp index d4b6f918c..32fcbd00d 100644 --- a/src/gui/ctrl/bus-term.hpp +++ b/src/gui/ctrl/bus-term.hpp @@ -25,7 +25,7 @@ ** Attachment point to the UI-Bus. ** Every gui::model::Tangible holds a BusTerm, which is linked ** to the Tangible's identity, and serves to relay interface actions - ** towards the Proc-Layer, to remember state changes and to broadcast + ** towards the Steam-Layer, to remember state changes and to broadcast ** notifications. Moreover, the BusTerm is the service point ** to receive structural change messages. ** @@ -98,7 +98,7 @@ namespace ctrl{ * intended for routing, broadcasting or forwarding. Effectively, * routing is determined from the context and meaning of a message, * where the _act_ and _note_ messages have an implicit receiver - * (either the Proc-Layer or the UI state manager), while the + * (either the Steam-Layer or the UI state manager), while the * _mark_ messages are always directed _downstream_ towards * some element. */ diff --git a/src/gui/ctrl/core-service.hpp b/src/gui/ctrl/core-service.hpp index 72b87e16d..7be2fff9e 100644 --- a/src/gui/ctrl/core-service.hpp +++ b/src/gui/ctrl/core-service.hpp @@ -71,7 +71,7 @@ ** messages, which can not be handled in a generic way on the Nexus: ** - *act* handles command invocation within the Session core, and ** is treated by [forwarding](\ref command-handler.hpp) it over the - ** SessionCommand facade to the [Proc-Dispatcher](\ref proc-dispatcher.hpp) + ** SessionCommand facade to the [Steam-Dispatcher](\ref proc-dispatcher.hpp) ** - *note* observes and captures presentation state note messages, which ** are to be handled by a central presentation state manager (TODO 1/17). ** @@ -106,7 +106,7 @@ namespace ctrl{ * Attachment point to »central services« within the UI-Bus. * This special implementation of the [BusTerm] interface receives and * handles those messages to be processed by centralised services: - * - commands need to be sent down to Proc-Layer + * - commands need to be sent down to Steam-Layer * - presentation state messages need to be recorded and acted upon. * As an object, CoreService encases the heart of the UI-Bus, the * \ref Nexus, and acts as "PImpl" for the gui::UiBus front-end. diff --git a/src/gui/dialog/test-control.hpp b/src/gui/dialog/test-control.hpp index 6934bf789..98a1c9734 100644 --- a/src/gui/dialog/test-control.hpp +++ b/src/gui/dialog/test-control.hpp @@ -165,8 +165,8 @@ namespace dialog { /** - * Ticket #1099 : perform a dummy round-trip to verify Proc-GUI integration. - * This routine invokes the command `test_meta_displayInfo` and friends down in Proc-Layer, + * Ticket #1099 : perform a dummy round-trip to verify Steam-Stage integration. + * This routine invokes the command `test_meta_displayInfo` and friends down in Steam-Layer, * passing the settings from the radio buttons to select the flavour of feedback, and the text * for feedback content. The expected behaviour is for the invoked command to send a feedback * via UI-Bus towards the ErrorLogDisplay within the InfoboxPanel. @@ -212,8 +212,8 @@ namespace dialog { trig_1_.set_use_underline(); trig_1_.set_label ("_display text"); trig_1_.property_xalign() = 0; - trig_1_.set_tooltip_markup (_("Trigger Proc-GUI roundtrip\n" - "Proc invokes GuiNotification::displayInfo")); + trig_1_.set_tooltip_markup (_("Trigger Steam-Stage roundtrip\n" + "Steam invokes GuiNotification::displayInfo")); level_warn_.join_group(level_info_); level_erro_.join_group(level_info_); @@ -222,19 +222,19 @@ namespace dialog { trig_2_.set_use_underline(); trig_2_.property_xalign() = 0; trig_2_.set_label ("mark _error"); - trig_2_.set_tooltip_markup (_("trigger Proc-command, which in turn\n" + trig_2_.set_tooltip_markup (_("trigger Steam-command, which in turn\n" "sends an error state mark via UI-Bus")); trig_3_.set_use_underline(); trig_3_.property_xalign() = 0; trig_3_.set_label ("mark _info"); - trig_3_.set_tooltip_markup (_("trigger Proc-command, which in turn\n" + trig_3_.set_tooltip_markup (_("trigger Steam-command, which in turn\n" "sends an info state mark via UI-Bus")); trig_4_.set_use_underline(); trig_4_.set_label ("_mark"); trig_4_.property_xalign() = 0; - trig_4_.set_tooltip_markup (_("trigger Proc-command, which in turn\n" + trig_4_.set_tooltip_markup (_("trigger Steam-command, which in turn\n" "sends an state mark message, using\n" "the message action-ID from the combobox")); actionID_.append (cuString{MARK_Flash}); diff --git a/src/gui/gtk-base.hpp b/src/gui/gtk-base.hpp index e4c5a48b1..61bcac57a 100644 --- a/src/gui/gtk-base.hpp +++ b/src/gui/gtk-base.hpp @@ -111,14 +111,14 @@ namespace gui { /** The Lumiera GTK-GUI uses a thin proxy layer data model * on top of the actual "high-level-model", which lives in the - * Proc-Layer below. GUI operations interact with these proxy model - * entities, which in turn forward the calls to the actual objects - * in the Proc-Layer, through the Command system (which enables UNDO). + * Steam-Layer below. Stage operations interact with these proxy + * model entities, which in turn forward the calls to the actual objects + * in the Steam-Layer, through the Command system (which enables UNDO). * * @todo: as of 1/2011 this connection between the GUI proxy model and - * the Proc-Layer model needs to be set up. Currently, the GUI model + * the Steam-Layer model needs to be set up. Currently, the GUI model * entities are just created standalone and thus dysfunctional. - * @todo: as of 11/2015 this connection between UI and Proc-Layer is actually + * @todo: as of 11/2015 this connection between UI and Steam-Layer is actually * in the works, and it is clear by now that we won't use proxy objects, * but rather a generic bus-like connection and symbolic IDs to designate * the model elements diff --git a/src/gui/model/clip.hpp b/src/gui/model/clip.hpp index 11ec7ce36..7d4a8ee3a 100644 --- a/src/gui/model/clip.hpp +++ b/src/gui/model/clip.hpp @@ -22,7 +22,7 @@ /** @file gui/model/clip.hpp ** Preliminary UI-model: a Proxy Clip object to base the GUI implementation on. - ** Later this Clip object will be connected to the underlying model in Proc-Layer. + ** Later this Clip object will be connected to the underlying model in Steam-Layer. ** @warning as of 2016 this UI model is known to be a temporary workaround ** and will be replaced in entirety by UI-Bus and diff framework. */ diff --git a/src/gui/model/parent-track.hpp b/src/gui/model/parent-track.hpp index c21110803..e197f90fe 100644 --- a/src/gui/model/parent-track.hpp +++ b/src/gui/model/parent-track.hpp @@ -22,7 +22,7 @@ /** @file parent-track.hpp ** Preliminary UI-model: Definition of ParentTrack, a class which ** represents a base functionality for tracks and sequences which - ** are also track parents. This class was intended to wraps proc layer data. + ** are also track parents. This class was intended to wraps steam layer data. ** @warning as of 2016 this UI model is known to be a temporary workaround ** and will be replaced in entirety by UI-Bus and diff framework. ** @deprecated the existing timeline implementation will be completely rewritten diff --git a/src/gui/model/project.cpp b/src/gui/model/project.cpp index d33f02247..1f3b7d1b3 100644 --- a/src/gui/model/project.cpp +++ b/src/gui/model/project.cpp @@ -23,7 +23,7 @@ /** @file project.cpp ** Preliminary UI-model: Implementation of Project, a class which - ** stores project data, and wraps proc layer data. + ** stores project data, and wraps steam layer data. ** @warning as of 2016 this UI model is known to be a temporary workaround ** and will be replaced in entirety by UI-Bus and diff framework. ** diff --git a/src/gui/model/project.hpp b/src/gui/model/project.hpp index 466986aac..e1236dabc 100644 --- a/src/gui/model/project.hpp +++ b/src/gui/model/project.hpp @@ -22,12 +22,12 @@ /** @file project.hpp ** Preliminary UI-model: Definition of Project, a class which - ** stores project data, and wraps proc layer data. + ** stores project data, and wraps steam layer data. ** @warning as of 2016 this UI model is known to be a temporary workaround ** and will be replaced in entirety by UI-Bus and diff framework. ** ** @todo this solution was used to build the first outline of the UI. - ** It needs to be reshaped into a connector to Proc-Layer ///////////////TICKET #959 + ** It needs to be reshaped into a connector to Steam-Layer ///////////////TICKET #959 */ #ifndef PROJECT_HPP diff --git a/src/gui/model/session-facade.cpp b/src/gui/model/session-facade.cpp index d8b6d332c..c9f0b0402 100644 --- a/src/gui/model/session-facade.cpp +++ b/src/gui/model/session-facade.cpp @@ -26,7 +26,7 @@ ** This header defines the basics of... ** ** @note as of X/2014 this is complete bs - ** @todo THE NAME IS UNFORTUNATE!!!! "SessionFacade" should rather be a facade in Proc! + ** @todo THE NAME IS UNFORTUNATE!!!! "SessionFacade" should rather be a facade in Steam! ** @todo WIP ///////////////////////TICKET # ** ** @see ////TODO_test usage example diff --git a/src/gui/model/track.hpp b/src/gui/model/track.hpp index aecb06436..9410fefe2 100644 --- a/src/gui/model/track.hpp +++ b/src/gui/model/track.hpp @@ -21,7 +21,7 @@ */ /** @file track.hpp ** Preliminary UI-model: Definition of Track, a class which - ** represents a track, and wraps proc layer data + ** represents a track, and wraps steam layer data ** @warning as of 2016 this UI model is known to be a temporary workaround ** and will be replaced in entirety by UI-Bus and diff framework. ** @deprecated the existing timeline implementation will be completely rewritten diff --git a/src/gui/ui-bus.hpp b/src/gui/ui-bus.hpp index d6788528d..ad77dc791 100644 --- a/src/gui/ui-bus.hpp +++ b/src/gui/ui-bus.hpp @@ -123,7 +123,7 @@ namespace gui { namespace controller { /** - * @todo needs to be reshaped for communication with Proc-Layer /////////////////TICKET #959 + * @todo needs to be reshaped for communication with Steam-Layer ////////////////TICKET #959 */ class Controller { diff --git a/src/gui/widget/timeline/timeline-header-container.hpp b/src/gui/widget/timeline/timeline-header-container.hpp index b052a79ea..85acb01d6 100644 --- a/src/gui/widget/timeline/timeline-header-container.hpp +++ b/src/gui/widget/timeline/timeline-header-container.hpp @@ -64,7 +64,7 @@ namespace gui { * * @note This must be called when the track list changes * to synchronise the headers with the timeline body and - * the backend. + * the core data. */ void update_headers(); diff --git a/src/include/dummy-player-facade.h b/src/include/dummy-player-facade.h index 1fc72eec2..1755b294e 100644 --- a/src/include/dummy-player-facade.h +++ b/src/include/dummy-player-facade.h @@ -54,7 +54,7 @@ namespace lumiera { /**************************************************************//** - * Experimental Interface Proc-Layer (or maybe the backend?): + * Experimental Interface Steam-Layer (or maybe the vault?): * Global access point for starting a dummy playback, generating * some test image data for the GUI to display in a viewer window. * @@ -108,9 +108,9 @@ namespace lumiera { * the Process implementation via the Process handle, * without having to map each implementation-level function * into the dummy player interface. We can't access the - * implementation in Proc-Layer without this indirection + * implementation in Steam-Layer without this indirection * through a VTable, since a direct call would require - * us to link against liblumieraproc.so + * us to link against liblumierasteam.so */ class ProcessImplementationLink : public lumiera_playprocess diff --git a/src/include/gui-notification-facade.h b/src/include/gui-notification-facade.h index bb4970cfe..f51feac20 100644 --- a/src/include/gui-notification-facade.h +++ b/src/include/gui-notification-facade.h @@ -23,7 +23,7 @@ /** @file gui-notification-facade.h ** Major public Interface of the Lumiera GUI. While from a user's point of view, ** the GUI controls the application and thus acts on its own, in fact the UI sends - ** command messages to the Session subsystem in Proc-Layer. These commands cause + ** command messages to the Session subsystem in Steam-Layer. These commands cause ** changes in the session, which result in notification and structure change messages ** being pushed up asynchronously back into the UI. The GuiNotification interface ** abstracts this ability of the UI to receive such update messages. It is implemented diff --git a/src/include/logging.h b/src/include/logging.h index b3d1c54a5..a83f82406 100644 --- a/src/include/logging.h +++ b/src/include/logging.h @@ -74,7 +74,7 @@ NOBUG_CPP_DEFINE_FLAG (all); NOBUG_CPP_DEFINE_FLAG_PARENT ( debugging, all); /** debug logging for the main application starter */ NOBUG_CPP_DEFINE_FLAG_PARENT ( main_dbg, debugging); -/** base of debug logging for the backend */ +/** base of debug logging for the vault layer */ NOBUG_CPP_DEFINE_FLAG_PARENT ( backend_dbg, debugging); NOBUG_CPP_DEFINE_FLAG_PARENT ( file_dbg, backend_dbg); NOBUG_CPP_DEFINE_FLAG_PARENT ( filehandle_dbg, backend_dbg); @@ -88,13 +88,13 @@ NOBUG_CPP_DEFINE_FLAG_PARENT ( threads_dbg, thread_dbg); NOBUG_CPP_DEFINE_FLAG_PARENT ( threadpool_dbg, thread_dbg); NOBUG_CPP_DEFINE_FLAG_PARENT ( fileheader_dbg, backend_dbg); -/** base of debug logging for the proc layer */ +/** base of debug logging for the steam layer */ NOBUG_CPP_DEFINE_FLAG_PARENT ( proc_dbg, debugging); NOBUG_CPP_DEFINE_FLAG_PARENT ( command_dbg, proc_dbg); NOBUG_CPP_DEFINE_FLAG_PARENT ( session_dbg, proc_dbg); NOBUG_CPP_DEFINE_FLAG_PARENT ( player_dbg, proc_dbg); NOBUG_CPP_DEFINE_FLAG_PARENT ( engine_dbg, proc_dbg); -/** base of debug logging for the gui */ +/** base of debug logging for the stage layer */ NOBUG_CPP_DEFINE_FLAG_PARENT ( gui_dbg, debugging); /** base if debug logging for the support library */ NOBUG_CPP_DEFINE_FLAG_PARENT ( library_dbg, debugging); @@ -123,7 +123,7 @@ NOBUG_CPP_DEFINE_FLAG_PARENT ( logging, all); NOBUG_CPP_DEFINE_FLAG_PARENT ( progress, logging); /** progress log for the main starter */ NOBUG_CPP_DEFINE_FLAG_PARENT ( main, progress); -/** progress log for the backend */ +/** progress log for the vault layer */ NOBUG_CPP_DEFINE_FLAG_PARENT ( backend, progress); NOBUG_CPP_DEFINE_FLAG_PARENT ( file, backend); //opening/closing files etc NOBUG_CPP_DEFINE_FLAG_PARENT ( mmap, backend); //mmap errors @@ -131,9 +131,9 @@ NOBUG_CPP_DEFINE_FLAG_PARENT ( thread, backend); NOBUG_CPP_DEFINE_FLAG_PARENT ( threads, thread); NOBUG_CPP_DEFINE_FLAG_PARENT ( threadpool, thread); NOBUG_CPP_DEFINE_FLAG_PARENT ( fileheader, backend); -/** progress log for the proc layer */ +/** progress log for the steam layer */ NOBUG_CPP_DEFINE_FLAG_PARENT ( proc, progress); -/** progress log for proc-layer command dispatch */ +/** progress log for steam-layer command dispatch */ NOBUG_CPP_DEFINE_FLAG_PARENT ( command, proc); /** progress log for session datastructure */ NOBUG_CPP_DEFINE_FLAG_PARENT ( session, proc); @@ -181,7 +181,7 @@ NOBUG_CPP_DEFINE_FLAG_PARENT ( mutex_sync, sync); NOBUG_CPP_DEFINE_FLAG_PARENT ( cond_sync, sync); //waiting and signalling condition vars /** base flag for memory related logging */ NOBUG_CPP_DEFINE_FLAG_PARENT ( memory, logging); -/** proc layer memory handling */ +/** steam layer memory handling */ NOBUG_CPP_DEFINE_FLAG_PARENT ( proc_mem, memory); NOBUG_CPP_DEFINE_FLAG_PARENT ( mobject_mem, proc_mem); NOBUG_CPP_DEFINE_FLAG_PARENT ( builder_mem, proc_mem); diff --git a/src/include/play-facade.hpp b/src/include/play-facade.hpp index abf8188d2..26e423c66 100644 --- a/src/include/play-facade.hpp +++ b/src/include/play-facade.hpp @@ -66,7 +66,7 @@ namespace lumiera { /**************************************************************//** - * Interface to the Player subsystem of Lumiera (Proc-Layer). + * Interface to the Player subsystem of Lumiera (Steam-Layer). * Global access point for starting playback and render processes, * calculating media data by running the render engine. * diff --git a/src/include/session-command-facade.h b/src/include/session-command-facade.h index ce49d9f28..8614cf42e 100644 --- a/src/include/session-command-facade.h +++ b/src/include/session-command-facade.h @@ -32,7 +32,7 @@ ** the structure of binding and invocation messages. This goes so far as to ** accept the command arguments for binding packaged as `Record`. ** For each command, there needs to be a registration record within the - ** Proc-Layer implementation. The service implementation backing this + ** Steam-Layer implementation. The service implementation backing this ** facade indeed retrieves the corresponding proc::control::Command ** handles to perform the binding operation and hands them over ** to the ProcDispatcher for invocation. diff --git a/src/lib/frameid.hpp b/src/lib/frameid.hpp index 40adadfbc..8ee33085f 100644 --- a/src/lib/frameid.hpp +++ b/src/lib/frameid.hpp @@ -71,7 +71,7 @@ namespace lumiera { * Identification tuple for addressing frames unambiguously. * * @todo currently (7/08) this is a dummy implementation to find out - * what interface the Proc layer needs. Probably the backend will + * what interface the Steam layer needs. Probably the vault layer will * later on define what is actually needed; this header should then * be replaced by a combined C/C++ header */ diff --git a/src/lib/safeclib.h b/src/lib/safeclib.h index 2a6ab5fb0..63ff7f356 100644 --- a/src/lib/safeclib.h +++ b/src/lib/safeclib.h @@ -37,7 +37,7 @@ LUMIERA_ERROR_DECLARE(NO_MEMORY); * initialised and removed from it before shut down. Without resourcecollector * failed allocations will abort(). * @param hook pointer to the resourcecollector_run function, must be of type - * lumiera_resourcecollector_run_fn but we don't want a dependency on backend in this header + * lumiera_resourcecollector_run_fn but we don't want a dependency on vault in this header */ void lumiera_safeclib_set_resourcecollector (void* hook); diff --git a/src/lib/symbol.hpp b/src/lib/symbol.hpp index f021d3d37..c0e254bb2 100644 --- a/src/lib/symbol.hpp +++ b/src/lib/symbol.hpp @@ -36,7 +36,7 @@ ** we close the circle by allowing Symbol instances to be created from strings at runtime. ** ** @remark this started on occasion 11/2008, just with a typedef to mark assumption on interfaces - ** for rules based configuration in the Proc-Layer. Over time, conversions, comparison and + ** for rules based configuration in the Steam-Layer. Over time, conversions, comparison and ** hashcode implementation were added. It turned out that the most smooth integration in ** coding practice is achieved when allowing transparent conversion for Literal, but not ** for Symbol or std::string. diff --git a/src/lib/time.h b/src/lib/time.h index 1ec4a9d78..2828c4c80 100644 --- a/src/lib/time.h +++ b/src/lib/time.h @@ -36,9 +36,9 @@ ** so that multiple output or rendering operations can use differing time origins ** and frame rates simultaneously on the same model. ** - ** The Lumiera backend functions mostly operate on raw frame counts, which in this - ** model are defined to be a special kind of timecode, and thus dependent on a - ** preceding time quantisation. + ** The Lumiera Vault Layer functions mostly operate on raw frame counts, which in + ** this model are defined to be a special kind of timecode, and thus dependent on + ** a preceding time quantisation. ** ** ** @see lib::time::Time diff --git a/src/lib/time/formats.hpp b/src/lib/time/formats.hpp index f1553af75..1476d6c21 100644 --- a/src/lib/time/formats.hpp +++ b/src/lib/time/formats.hpp @@ -74,8 +74,8 @@ namespace time { * Frame count as timecode format. * An integral number used to count frames * can be used as a simple from of time code. - * Indeed the Lumiera backend mostly relies on - * these frame counts. As with any timecode, the + * Indeed the Lumiera vault layer mostly relies + * on these frame counts. As with any timecode, the * underlying framerate/quantisation remains implicit. */ struct Frames diff --git a/src/lib/time/quantiser.hpp b/src/lib/time/quantiser.hpp index 4ed16703d..194986107 100644 --- a/src/lib/time/quantiser.hpp +++ b/src/lib/time/quantiser.hpp @@ -136,7 +136,7 @@ namespace time { * Simple stand-alone Quantiser implementation based on a constant sized gird. * This is a self-contained quantiser implementation without any implicit referral * to the Lumiera session. As such it is suited for simplified unit testing. - * @warning real GUI and Proc-Layer code should always fetch a quantiser from the + * @warning real GUI and Steam-Layer code should always fetch a quantiser from the * Session, referring to a pre defined TimeGrid. Basically, the overall purpose of * the time-quantisation framework is to enforce such a link to a distinct time scale * and quantisation, so to prevent "wild and uncoordinated" rounding attempts. diff --git a/src/lib/visitor.hpp b/src/lib/visitor.hpp index f15eae4b0..78925dbf6 100644 --- a/src/lib/visitor.hpp +++ b/src/lib/visitor.hpp @@ -37,7 +37,7 @@ Credits for many further implementation ideas go to /** @file visitor.hpp ** A library implementation of the *Visitor Pattern* tailored specifically - ** to Lumiera's needs within the Proc Layer. Visitor enables *double dispatch* + ** to Lumiera's needs within the Steam Layer. Visitor enables *double dispatch* ** calls, based both on the concrete type of some target object and the concrete type of ** a tool object being applied to this target. The code carrying out this tool application ** (and thus triggering the double dispatch) need not know any of these concrete types and is diff --git a/src/proc/asset.hpp b/src/proc/asset.hpp index 58b456a30..013d85ea5 100644 --- a/src/proc/asset.hpp +++ b/src/proc/asset.hpp @@ -22,7 +22,7 @@ /** @file asset.hpp ** @ingroup asset - ** Proc-Layer Interface: Assets. + ** Steam-Layer Interface: Assets. ** Declares the Asset top level Interface, the Asset::Ident identification tuple ** and the asset::ID primary key wrapper. Normally, Assets should be handled ** using asset::PAsset, a ref counting smart pointer. diff --git a/src/proc/asset/typed-id.hpp b/src/proc/asset/typed-id.hpp index 56c83f902..414974f07 100644 --- a/src/proc/asset/typed-id.hpp +++ b/src/proc/asset/typed-id.hpp @@ -57,12 +57,12 @@ //#include #include -namespace lumiera{ ///////TODO: shouldn't that be namespace lib? or proc? +namespace lumiera{ ///////TODO: shouldn't that be namespace lib? or steam? namespace query { /** * Adapter for using this type as a \em primary type - * within Lumiera's Proc-Layer. Any such type is expected + * within Lumiera's Steam-Layer. Any such type is expected * to provide a specialisation, filling in the actual details * necessary to deal with objects of this type. * diff --git a/src/proc/assetmanager.hpp b/src/proc/assetmanager.hpp index 08f6e6244..1ca4245ab 100644 --- a/src/proc/assetmanager.hpp +++ b/src/proc/assetmanager.hpp @@ -21,7 +21,7 @@ */ /** @file assetmanager.hpp - ** Proc-Layer Interface: Asset Lookup and Organisation. + ** Steam-Layer Interface: Asset Lookup and Organisation. ** Declares the AssetManager interface used to access individual ** Asset instances. ** diff --git a/src/proc/cmd.hpp b/src/proc/cmd.hpp index c56ac6c2c..72278771f 100644 --- a/src/proc/cmd.hpp +++ b/src/proc/cmd.hpp @@ -1,5 +1,5 @@ /* - CMD.hpp - Proc Command definition keys + CMD.hpp - Steam Command definition keys Copyright (C) Lumiera.org 2017, Hermann Vosseler @@ -22,9 +22,9 @@ /** @file cmd.hpp - ** Common ID definitions for Proc-Layer commands. + ** Common ID definitions for Steam-Layer commands. ** This header is included when defining the actual command scripts, but also - ** from all those UI elements to use and invoke the defined Proc-Layer commands. + ** from all those UI elements to use and invoke the defined Steam-Layer commands. ** @todo WIP 3/2017 early draft ** ** @see command.hpp diff --git a/src/proc/cmd/meta-cmd.cpp b/src/proc/cmd/meta-cmd.cpp index 030a5ebfa..ed1ce6b48 100644 --- a/src/proc/cmd/meta-cmd.cpp +++ b/src/proc/cmd/meta-cmd.cpp @@ -1,5 +1,5 @@ /* - MetaCmd - actual proc command scripts for internal meta and control activities + MetaCmd - actual steam command scripts for internal meta and control activities Copyright (C) Lumiera.org 2018, Hermann Vosseler @@ -22,7 +22,7 @@ /** @file meta-cmd.cpp - ** Actual definition of Proc-Layer command scripts for meta/ctrl actions. + ** Actual definition of Steam-Layer command scripts for meta/ctrl actions. ** Any actions issued by the UI-Layer to control internal application state ** @todo WIP 8/2018 early draft ** @@ -92,7 +92,7 @@ COMMAND_DEFINITION (test_meta_activateContentDiff) { TODO ("send a population diff starting from scratch"); TODO ("activate life-update service within the session"); - // Temporary hack to get any meaningful UI <-> Proc communication + // Temporary hack to get any meaningful UI <-> Steam communication GuiNotification::facade().displayInfo(NOTE_INFO, "Request: population-Diff from Session."); }) .captureUndo ([]() -> bool @@ -146,7 +146,7 @@ COMMAND_DEFINITION (meta_deactivateContentDiff) /* ===== Demo and Development ===== */ /** DemoGuiRoundtrip: push a notification info message back up into the UI. - * @todo this is a demo mock setup to further development of the Proc-UI integration //////////////////TICKET #1140 : prototypical Proc-GUI communication + * @todo this is a demo mock setup to further development of the Steam-Stage integration //////////////TICKET #1140 : prototypical Steam-Stage communication */ COMMAND_DEFINITION (test_meta_displayInfo) { @@ -166,7 +166,7 @@ COMMAND_DEFINITION (test_meta_displayInfo) /** DemoGuiRoundtrip: send a `markError` message back up into the UI. - * @todo this is a demo mock setup to further development of the Proc-UI integration //////////////////TICKET #1140 : prototypical Proc-GUI communication + * @todo this is a demo mock setup to further development of the Steam-Stage integration //////////////TICKET #1140 : prototypical Steam-Stage communication */ COMMAND_DEFINITION (test_meta_markError) { @@ -187,7 +187,7 @@ COMMAND_DEFINITION (test_meta_markError) /** DemoGuiRoundtrip: send a `markNote` message back up into the UI. - * @todo this is a demo mock setup to further development of the Proc-UI integration //////////////////TICKET #1140 : prototypical Proc-GUI communication + * @todo this is a demo mock setup to further development of the Steam-Stage integration //////////////TICKET #1140 : prototypical Steam-Stage communication */ COMMAND_DEFINITION (test_meta_markNote) { @@ -208,7 +208,7 @@ COMMAND_DEFINITION (test_meta_markNote) /** DemoGuiRoundtrip: send a generic `mark` message with given _action ID_ back up into the UI. - * @todo this is a demo mock setup to further development of the Proc-UI integration //////////////////TICKET #1140 : prototypical Proc-GUI communication + * @todo this is a demo mock setup to further development of the Steam-Stage integration //////////////TICKET #1140 : prototypical Steam-Stage communication */ COMMAND_DEFINITION (test_meta_markAction) { diff --git a/src/proc/cmd/scope-cmd.cpp b/src/proc/cmd/scope-cmd.cpp index 138362e94..9bc1bf4e3 100644 --- a/src/proc/cmd/scope-cmd.cpp +++ b/src/proc/cmd/scope-cmd.cpp @@ -1,5 +1,5 @@ /* - ScopeCmd - actual proc command scripts for actions within model scope + ScopeCmd - actual steam command scripts for actions within model scope Copyright (C) Lumiera.org 2017, Hermann Vosseler @@ -22,7 +22,7 @@ /** @file scope-cmd.cpp - ** Actual definition of Proc-Layer command scripts for actions within scope. + ** Actual definition of Steam-Layer command scripts for actions within scope. ** Here "scope" means a scope within the high-level model, which could be ** - a track or media bin ** - a clip diff --git a/src/proc/cmd/sequence-cmd.cpp b/src/proc/cmd/sequence-cmd.cpp index 38e97f095..f9db100a1 100644 --- a/src/proc/cmd/sequence-cmd.cpp +++ b/src/proc/cmd/sequence-cmd.cpp @@ -1,5 +1,5 @@ /* - SequenceCmd - actual proc command scripts for actions operating within a sequence + SequenceCmd - actual steam command scripts for actions operating within a sequence Copyright (C) Lumiera.org 2017, Hermann Vosseler @@ -22,7 +22,7 @@ /** @file sequence-cmd.cpp - ** Actual definition of Proc-Layer command scripts for actions within a sequence. + ** Actual definition of Steam-Layer command scripts for actions within a sequence. ** Especially all those actions working within the track tree go into this file ** @todo WIP 4/2017 early draft ** diff --git a/src/proc/cmd/session-cmd.cpp b/src/proc/cmd/session-cmd.cpp index 4ef346336..6dfeb8051 100644 --- a/src/proc/cmd/session-cmd.cpp +++ b/src/proc/cmd/session-cmd.cpp @@ -1,5 +1,5 @@ /* - SessionCmd - actual proc command scripts for session-global actions + SessionCmd - actual steam command scripts for session-global actions Copyright (C) Lumiera.org 2017, Hermann Vosseler @@ -22,7 +22,7 @@ /** @file session-cmd.cpp - ** Actual definition of Proc-Layer command scripts for session-global actions. + ** Actual definition of Steam-Layer command scripts for session-global actions. ** @todo WIP 3/2017 early draft ** ** @see cmd.hpp diff --git a/src/proc/common.hpp b/src/proc/common.hpp index 5acea10b0..ac50bfc5d 100644 --- a/src/proc/common.hpp +++ b/src/proc/common.hpp @@ -1,5 +1,5 @@ /* - COMMON.hpp - global definitions and common types for the Proc-Layer + COMMON.hpp - global definitions and common types for the Steam-Layer Copyright (C) Lumiera.org @@ -25,9 +25,9 @@ /** @file proc/common.hpp ** Basic set of definitions and includes commonly used together. ** Including common.hpp gives you a common set of elementary declarations - ** widely used within the C++ code of the Proc-Layer. Besides that, this + ** widely used within the C++ code of the Steam-Layer. Besides that, this ** header is used to attach the doxygen documentation comments for all - ** the primary Proc-Layer namespaces + ** the primary Stean-Layer namespaces ** ** @see main.cpp ** @@ -53,26 +53,26 @@ /** - * Proc-Layer implementation namespace root. + * Steam-Layer implementation namespace root. * Lumiera's middle layer contains the core models, both * high-level (session) and low-level (render nodes), together with * the Builder to translate between those two models, the command frontend, * session support system, the playback-and-render-control subsystem and * the API and backbone of the renderengine. Most render implementation - * code resides in the backend or is loaded from plug-ins though. + * code resides in the vault layer or is loaded from plug-ins though. */ namespace proc { /** - * The asset subsystem of the Proc-Layer. + * The asset subsystem of the Steam-Layer. */ namespace asset { } /** - * Proc-Layer dispatcher, controller and administrative facilities. + * Steam-Layer dispatcher, controller and administrative facilities. */ namespace control { } @@ -80,7 +80,7 @@ namespace proc { /** * Playback and rendering control subsystem. * The so called "player" combines and orchestrates services from - * the engine, session and backend to perform playback or rendering + * the engine, session and vault to perform playback or rendering */ namespace play { @@ -88,10 +88,10 @@ namespace proc { /** - * Render engine code as part of the Proc-Layer. + * Render engine code as part of the Steam-Layer. * Backbone of the engine, render nodes base and cooperation. * A good deal of the active engine code is outside the scope of the - * Proc-Layer, e.g. code located in backend services and plugins. + * Steam-Layer, e.g. code located in vault services and plugins. */ namespace engine { diff --git a/src/proc/config-resolver.cpp b/src/proc/config-resolver.cpp index 410c4b80f..30b38feb0 100644 --- a/src/proc/config-resolver.cpp +++ b/src/proc/config-resolver.cpp @@ -22,7 +22,7 @@ /** @file config-resolver.cpp - ** Implementation of bindings between Proc-Layer objects and rules-based configuration. + ** Implementation of bindings between Steam-Layer objects and rules-based configuration. ** @todo draft from the early design phase of the Lumiera application. As of 2016, nothing ** was done on behalf of rules-based configuration, other then preparing the whole architecture ** for this capability. So this remains one of the most relevant goals of the Project. diff --git a/src/proc/control/argument-erasure.hpp b/src/proc/control/argument-erasure.hpp index 6345849d1..bd7226f84 100644 --- a/src/proc/control/argument-erasure.hpp +++ b/src/proc/control/argument-erasure.hpp @@ -22,7 +22,7 @@ /** @file argument-erasure.hpp - ** Implementation helper to bind Proc-Layer commands with arbitrary argument tuples + ** Implementation helper to bind Steam-Layer commands with arbitrary argument tuples ** @internal details of the [command handling framework](\ref command.hpp). */ diff --git a/src/proc/control/argument-tuple-accept.hpp b/src/proc/control/argument-tuple-accept.hpp index b8cfbe6a7..84176e959 100644 --- a/src/proc/control/argument-tuple-accept.hpp +++ b/src/proc/control/argument-tuple-accept.hpp @@ -27,7 +27,7 @@ ** accept a specifically typed binding or function call, as specified by the ** template parameters, or alternatively it can inherit a complete set of ** templated argument binding functions, assuming that the matching signature - ** can be detected at runtime. These templates are used for the Proc-Layer + ** can be detected at runtime. These templates are used for the Steam-Layer ** command frontend, to bind to the actual command arguments. ** ** The AcceptArgumentBinding template allows to mix in a `bind(...)` function. @@ -531,7 +531,7 @@ namespace control { { }; - /** Helper Template for Proc-Layer control::Command : mix in a \c bind(...) function + /** Helper Template for Steam-Layer control::Command : mix in a \c bind(...) function * @param SIG function signature to mimic (regarding the arguments and return type) * @param TAR the target class providing a function \c bindArg(Tuple >) * @param BASE the base class for inheritance chaining diff --git a/src/proc/control/command-closure.hpp b/src/proc/control/command-closure.hpp index 172ed5a4d..8c7a32ade 100644 --- a/src/proc/control/command-closure.hpp +++ b/src/proc/control/command-closure.hpp @@ -23,7 +23,7 @@ /** @file command-closure.hpp ** A closure enabling self-contained execution of commands within the ProcDispatcher. - ** After defining a proc-layer command, at some point the function arguments + ** After defining a steam-layer command, at some point the function arguments ** of the contained operation are "closed" by storing concrete argument values. ** These values will be fed later on to the operation when the command is invoked. ** diff --git a/src/proc/control/command-def.hpp b/src/proc/control/command-def.hpp index 133c2330b..7371c0d8c 100644 --- a/src/proc/control/command-def.hpp +++ b/src/proc/control/command-def.hpp @@ -1,5 +1,5 @@ /* - COMMAND-DEF.hpp - defining and binding a Proc-Layer command + COMMAND-DEF.hpp - defining and binding a Steam-Layer command Copyright (C) Lumiera.org 2009, Hermann Vosseler diff --git a/src/proc/control/command-impl.hpp b/src/proc/control/command-impl.hpp index c13e898a3..b85a30b24 100644 --- a/src/proc/control/command-impl.hpp +++ b/src/proc/control/command-impl.hpp @@ -1,5 +1,5 @@ /* - COMMAND-IMPL.hpp - Proc-Layer command implementation (top level) + COMMAND-IMPL.hpp - Steam-Layer command implementation (top level) Copyright (C) Lumiera.org 2009, Hermann Vosseler @@ -24,7 +24,7 @@ /** @file command-impl.hpp ** Top level of the command implementation. CommandImpl holds together ** the various data and sub-objects involved into the inner workings of a - ** Proc-Layer command. It serves to implement a "command definition" (prototype) + ** Steam-Layer command. It serves to implement a "command definition" (prototype) ** as well as a concrete command instance. It is a data holder with a well defined ** identity and usually located within the (pooled) storage managed by the ** CommandRegistry. Client code gets access to a specific CommandImpl through @@ -62,7 +62,7 @@ namespace control { /** - * Proc-Layer Command implementation. + * Steam-Layer Command implementation. * Data record holding together the parts necessary for command execution * - command operation functor * - a functor to UNDO the command effect diff --git a/src/proc/control/command-instance-manager.hpp b/src/proc/control/command-instance-manager.hpp index 7a7f3c478..2e83f81c0 100644 --- a/src/proc/control/command-instance-manager.hpp +++ b/src/proc/control/command-instance-manager.hpp @@ -23,7 +23,7 @@ /** @file command-instance-manager.hpp ** Service to support forming and invocation of command instances for use by the UI. - ** A *Proc-Layer command* is a functor, which can be parametrised with concrete arguments. + ** A *Steam-Layer command* is a functor, which can be parametrised with concrete arguments. ** Typically, these arguments are to be picked up from the actual usage context in the GUI. ** This creates the specific twist that possible command instances for invocation can and will ** be formed during an extended time period, non-deterministically -- since the actual context @@ -40,7 +40,7 @@ ** \par lifecycle ** There CommandInstanceManager is maintained by the SessionCommandService, which in turn is ** installed and removed by the implementation within ProcDispatcher. Its lifecycle is thus tied - ** to the opening / closing of the Proc-Layer interface, as dictated by the Session lifecycle. + ** to the opening / closing of the Steam-Layer interface, as dictated by the Session lifecycle. ** When the current session is closed, all command instances "underway" will thus be discarded. ** ** @see command-setup.cpp service implementation diff --git a/src/proc/control/command-invocation.hpp b/src/proc/control/command-invocation.hpp index dcac45aa6..6c1fcbc03 100644 --- a/src/proc/control/command-invocation.hpp +++ b/src/proc/control/command-invocation.hpp @@ -1,5 +1,5 @@ /* - COMMAND-INVOCATION.hpp - shortcuts and helpers for calling Proc-Layer commands + COMMAND-INVOCATION.hpp - shortcuts and helpers for calling Steam-Layer commands Copyright (C) Lumiera.org 2009, Hermann Vosseler diff --git a/src/proc/control/command-mutation.hpp b/src/proc/control/command-mutation.hpp index 23f517cc8..9c33380ca 100644 --- a/src/proc/control/command-mutation.hpp +++ b/src/proc/control/command-mutation.hpp @@ -1,5 +1,5 @@ /* - COMMAND-MUTATION.hpp - functor encapsulating the actual operation of proc-Command + COMMAND-MUTATION.hpp - functor encapsulating the actual operation of steam-Command Copyright (C) Lumiera.org 2009, Hermann Vosseler @@ -22,7 +22,7 @@ /** @file command-mutation.hpp - ** Core of a Proc-Layer command: functor containing the operation to be executed. + ** Core of a Steam-Layer command: functor containing the operation to be executed. ** Each command holds two of these functors: one representing the actual operation ** and one to undo the effect of this operation. The latter involves the capturing ** and storing of a "memento" value behind the scenes. But towards Command, the @@ -57,7 +57,7 @@ namespace control { /** - * Unspecific command functor for implementing Proc-Layer Command. + * Unspecific command functor for implementing Steam-Layer Command. * To be created from an std::function object, which later on gets * any necessary arguments from a closure passed in on invocation. * The concrete type of the function and the arguments is diff --git a/src/proc/control/command-registry.hpp b/src/proc/control/command-registry.hpp index ac54fe8f7..2ea56a2ce 100644 --- a/src/proc/control/command-registry.hpp +++ b/src/proc/control/command-registry.hpp @@ -1,5 +1,5 @@ /* - COMMAND-REGISTRY.hpp - proc-Command object registration and storage management + COMMAND-REGISTRY.hpp - steam-Command object registration and storage management Copyright (C) Lumiera.org 2009, Hermann Vosseler diff --git a/src/proc/control/command-setup.cpp b/src/proc/control/command-setup.cpp index 690eec058..5aba7f167 100644 --- a/src/proc/control/command-setup.cpp +++ b/src/proc/control/command-setup.cpp @@ -85,7 +85,7 @@ namespace control { CommandSetup::~CommandSetup() { } - /** Start a command setup for defining a Proc-Layer command with the given cmdID + /** Start a command setup for defining a Steam-Layer command with the given cmdID * @param cmdID the ID under with the new command will be registered * @note after defining a static variable of type CommandSetup, * a functor or lambda should be assigned, which then diff --git a/src/proc/control/command-setup.hpp b/src/proc/control/command-setup.hpp index 251d665d9..879ab150d 100644 --- a/src/proc/control/command-setup.hpp +++ b/src/proc/control/command-setup.hpp @@ -1,5 +1,5 @@ /* - COMMAND-INSTANCE-SETUP.hpp - Key abstraction for proc/edit operations and UNDO management + COMMAND-INSTANCE-SETUP.hpp - Key abstraction for steam/edit operations and UNDO management Copyright (C) Lumiera.org 2017, Hermann Vosseler @@ -23,7 +23,7 @@ /** @file command-setup.hpp ** Provision for setup of concrete commands for use by the UI. - ** A *Proc-Layer command* is a functor, which can be parametrised with actual arguments. + ** A *Steam-Layer command* is a functor, which can be parametrised with actual arguments. ** It needs to be [defined](\ref command-def.hpp) beforehand, which means to establish an unique ** name and to supply three functions, one for the actual command operation, one to capture ** state and one to _undo_ the effect of the command invocation. CommandSetup allows to create @@ -76,7 +76,7 @@ namespace control { /** - * Marker and Helper for writing Proc-Layer Command definitions. + * Marker and Helper for writing Steam-Layer Command definitions. * Together with the Macro #COMMAND_DEFINITION, such definitions * may be written statically, in DSL-style: * - statically define a variable of type CommandSetup, diff --git a/src/proc/control/command-storage-holder.hpp b/src/proc/control/command-storage-holder.hpp index 6a03ae060..297842f75 100644 --- a/src/proc/control/command-storage-holder.hpp +++ b/src/proc/control/command-storage-holder.hpp @@ -68,11 +68,11 @@ namespace control { * This is "the" top level CmdClosure implementation. * It is a specifically typed CmdClosure, which serves for * actually allocating storage to hold the command arguments - * and the UNDO state (memento) for Proc-Layer commands. + * and the UNDO state (memento) for Steam-Layer commands. * Both the contained components within StorageHolder * can be in \em empty state; there are no distinct * lifecycle limitations. StorageHolder is part - * of Proc-Layer command's implementation + * of Steam-Layer command's implementation * and should not be used standalone. */ template diff --git a/src/proc/control/command.cpp b/src/proc/control/command.cpp index ffd4518c0..036f9a800 100644 --- a/src/proc/control/command.cpp +++ b/src/proc/control/command.cpp @@ -1,5 +1,5 @@ /* - Command - Key abstraction for proc/edit operations and UNDO management + Command - Key abstraction for steam/edit operations and UNDO management Copyright (C) Lumiera.org 2009, Hermann Vosseler diff --git a/src/proc/control/command.hpp b/src/proc/control/command.hpp index 24b78c54e..cecdc10dd 100644 --- a/src/proc/control/command.hpp +++ b/src/proc/control/command.hpp @@ -1,5 +1,5 @@ /* - COMMAND.hpp - Key abstraction for proc/edit operations and UNDO management + COMMAND.hpp - Key abstraction for steam/edit operations and UNDO management Copyright (C) Lumiera.org 2009, Hermann Vosseler @@ -22,7 +22,7 @@ /** @file command.hpp - ** Proc-Layer command frontend. + ** Steam-Layer command frontend. ** A *command* is a functor, which can be invoked according to a pre-defined HandlingPattern. ** Most notably, command invocation can be scheduled and logged with the serialiser, and the effect ** of any command invocation can be _undone_ later on by invoking the "undo operation" defined diff --git a/src/proc/control/handling-pattern.cpp b/src/proc/control/handling-pattern.cpp index 043a25306..deaf19555 100644 --- a/src/proc/control/handling-pattern.cpp +++ b/src/proc/control/handling-pattern.cpp @@ -23,7 +23,7 @@ /** @file handling-pattern.cpp ** Implementation of pre-defined command handling patterns - ** @internal detail of the Proc-Layer command handling framework. + ** @internal detail of the Steam-Layer command handling framework. */ diff --git a/src/proc/control/handling-patterns.hpp b/src/proc/control/handling-patterns.hpp index e317c042c..e05c5ed8b 100644 --- a/src/proc/control/handling-patterns.hpp +++ b/src/proc/control/handling-patterns.hpp @@ -24,7 +24,7 @@ /** @file handling-patterns.hpp ** A hard wired collection of predefined command handling patterns. ** There is a small number of different possibilities to handle execution - ** and UNDO of proc-Layer commands. Each of these is defined as a subclass + ** and UNDO of Steam-Layer commands. Each of these is defined as a subclass ** in this header and then hard wired into a small table. Handling patterns ** are stateless singleton objects, thus we build using multiple Singleton ** factory objects and configure them hard wired with the respective diff --git a/src/proc/control/looper.hpp b/src/proc/control/looper.hpp index 04ce1a2cf..d5e2fadb8 100644 --- a/src/proc/control/looper.hpp +++ b/src/proc/control/looper.hpp @@ -1,5 +1,5 @@ /* - LOOPER.hpp - proc dispatcher loop and timing control logic + LOOPER.hpp - steam dispatcher loop and timing control logic Copyright (C) Lumiera.org 2016, Hermann Vosseler diff --git a/src/proc/control/memento-tie.hpp b/src/proc/control/memento-tie.hpp index dfa290fd7..1f70e44a0 100644 --- a/src/proc/control/memento-tie.hpp +++ b/src/proc/control/memento-tie.hpp @@ -22,7 +22,7 @@ /** @file memento-tie.hpp - ** A special binding used by Proc-Layer commands for capturing UNDO state information. + ** A special binding used by Steam-Layer commands for capturing UNDO state information. ** The UndoMutation, which is the functor object created and configured by the Command ** for handling UNDO, utilises a MementoTie (as ctor parameter) for binding together ** the "undo capture function" and the actual "undo function", by retrieving the diff --git a/src/proc/control/proc-dispatcher.cpp b/src/proc/control/proc-dispatcher.cpp index c15ec1ce2..d40807ea5 100644 --- a/src/proc/control/proc-dispatcher.cpp +++ b/src/proc/control/proc-dispatcher.cpp @@ -1,5 +1,5 @@ /* - ProcDispatcher - Proc-Layer command dispatch and execution + ProcDispatcher - Steam-Layer command dispatch and execution Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -145,7 +145,7 @@ namespace control { }) { Thread::sync(); // done with setup; loop may run now.... - INFO (session, "Proc-Dispatcher running..."); + INFO (session, "Steam-Dispatcher running..."); { Lock(this); // open public session interface: commandService_.createInstance(*this); @@ -156,9 +156,9 @@ namespace control { { try { commandService_.shutdown(); // redundant call, to ensure session interface is closed reliably - INFO (session, "Proc-Dispatcher stopped."); + INFO (session, "Steam-Dispatcher stopped."); } - ERROR_LOG_AND_IGNORE(session, "Stopping the Proc-Dispatcher"); + ERROR_LOG_AND_IGNORE(session, "Stopping the Steam-Dispatcher"); } void @@ -314,7 +314,7 @@ namespace control { void startBuilder() { - TODO ("+++ start the Proc-Builder..."); + TODO ("+++ start the Steam-Builder..."); } }; diff --git a/src/proc/control/proc-dispatcher.hpp b/src/proc/control/proc-dispatcher.hpp index 66381e2b9..0009e2f66 100644 --- a/src/proc/control/proc-dispatcher.hpp +++ b/src/proc/control/proc-dispatcher.hpp @@ -1,5 +1,5 @@ /* - PROC-DISPATCHER.hpp - Proc-Layer command dispatch and execution + PROC-DISPATCHER.hpp - Steam-Layer command dispatch and execution Copyright (C) Lumiera.org 2009, Hermann Vosseler diff --git a/src/proc/controllerfacade.hpp b/src/proc/controllerfacade.hpp index b4e8babc4..f96cef0f9 100644 --- a/src/proc/controllerfacade.hpp +++ b/src/proc/controllerfacade.hpp @@ -1,5 +1,5 @@ /* - CONTROLLERFACADE.hpp - Facade and service access point for the Proc Layer Controller + CONTROLLERFACADE.hpp - Facade and service access point for the Steam Layer Controller Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -22,7 +22,7 @@ /** @file controllerfacade.hpp - ** unfinished draft for a "Proc-Layer Controller" + ** unfinished draft for a "Steam-Layer Controller" ** @todo as of 2016 it very much looks like there wont'be any such thing... */ @@ -37,7 +37,7 @@ namespace proc_interface /** - * Interface providing unified access to the Proc-Subsystem Controller. + * Interface providing unified access to the Steam-Subsystem Controller. * Especially, this Facade class exports the functions to get a render * engine for carrying out actual renderings. */ diff --git a/src/proc/engine/calc-stream.hpp b/src/proc/engine/calc-stream.hpp index 7b64bb137..727b08121 100644 --- a/src/proc/engine/calc-stream.hpp +++ b/src/proc/engine/calc-stream.hpp @@ -94,7 +94,7 @@ namespace engine{ * calculation jobs, delivering frames into the configured * OutputSlot in a timely fashion. Behind the scenes, this * "stream of calculations" will be translated into several - * jobs enqueued with the scheduler in the backend layer. + * jobs enqueued with the scheduler in the Vault Layer. * The implementation of the \link Dispatcher frame dispatch * step \endlink cares to create and configure these jobs * and to manage the necessary dependencies and callbacks. diff --git a/src/proc/engine/engine-service.hpp b/src/proc/engine/engine-service.hpp index f27cbd218..95060137f 100644 --- a/src/proc/engine/engine-service.hpp +++ b/src/proc/engine/engine-service.hpp @@ -22,8 +22,8 @@ /** @file engine-service.hpp ** Access point for the (core) calculation service of the render engine. - ** This Proc-Layer internal service is provided for use by the Player subsystem. - ** The actual implementation is forwarded to backend services (especially the scheduler). + ** This Steam-Layer internal service is provided for use by the Player subsystem. + ** The actual implementation is forwarded to Vault services (especially the scheduler). ** The EngineService singleton has no state beyond the jobs currently managed by the ** scheduler; when the latter isn't available, any invocation will throw. ** @@ -31,7 +31,7 @@ ** This represents a series of calculations, expected to happen in a timely fashion and in order ** to deliver a frame data stream into an opened output connection. On the implementation side, ** a calculation stream will be translated into a series of jobs to invoke render nodes; - ** these jobs are to be executed through the scheduler in the backend layer. + ** these jobs are to be executed through the scheduler in the Vault Layer. ** ** While the individual CalcStram is simple, linear and unmodifiable, any CalcStream may be ** _superseded_ by a new definition. In this case, the engine will care for a seamless @@ -92,7 +92,7 @@ namespace engine{ * sink in a timely fashion. Actually the CalculationStream * instances provided through this (facade) interface are * backed by jobs executed through the scheduler in the - * backend layer. The implementation of this service is + * vault layer. The implementation of this service is * responsible for creating the right job entries in the * correct order and to enqueue these into the scheduler. * @ingroup engine diff --git a/src/proc/engine/nodeoperation.hpp b/src/proc/engine/nodeoperation.hpp index 5ad0da05c..f0965ff21 100644 --- a/src/proc/engine/nodeoperation.hpp +++ b/src/proc/engine/nodeoperation.hpp @@ -88,7 +88,7 @@ namespace config { BuffHandle getSource (Invocation& ivo, uint chanNo) { - UNIMPLEMENTED ("retrieve source data provided by the backend/scheduler"); + UNIMPLEMENTED ("retrieve source data provided by the vault/scheduler"); } BuffHandle diff --git a/src/proc/engine/renderengine.hpp b/src/proc/engine/renderengine.hpp index ed533afdd..5915ecc7c 100644 --- a/src/proc/engine/renderengine.hpp +++ b/src/proc/engine/renderengine.hpp @@ -51,7 +51,7 @@ namespace engine { * @todo this was planned to become the frontend * to the render node network, which can be considered * at the lower end of the middle layer; the actual - * render operations are mostly implemented by the backend + * render operations are mostly implemented by the vault layer * ////////TODO WIP as of 12/2010 */ class RenderEngine @@ -59,7 +59,7 @@ namespace engine { { public: ///// TODO: find out about the public operations - // note: the play controller lives in the proc-layer, + // note: the play controller lives in the steam-layer, // but is a subsystem separate of the session. RenderEngine(); diff --git a/src/proc/engine/source.hpp b/src/proc/engine/source.hpp index 8ec180103..1f85bffd5 100644 --- a/src/proc/engine/source.hpp +++ b/src/proc/engine/source.hpp @@ -48,7 +48,7 @@ namespace engine /** * Source Node: represents a media source to pull data from. * Source is special, because it has no predecessor nodes, - * but rather makes calls down to the data backend internally + * but rather makes calls down to the vault layer internally * to get at the raw data. */ class Source : public ProcNode diff --git a/src/proc/facade.cpp b/src/proc/facade.cpp index 6475ef457..66995d54f 100644 --- a/src/proc/facade.cpp +++ b/src/proc/facade.cpp @@ -1,5 +1,5 @@ /* - Facade - access point for communicating with the Proc-Interface + Facade - access point for communicating with the Steam-Interface Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -22,7 +22,7 @@ /** @file facade.cpp - ** Implementation of subsystem lifecycle behaviour for the core parts of Proc-Layer. + ** Implementation of subsystem lifecycle behaviour for the core parts of Steam-Layer. ** - The »session subsystem« is responsible for accepting operations to work on the ** session datastructure, and it will trigger the Builder to reflect those changes ** into a suitable render nodes network diff --git a/src/proc/facade.hpp b/src/proc/facade.hpp index f32fa46e5..fcdcfe428 100644 --- a/src/proc/facade.hpp +++ b/src/proc/facade.hpp @@ -1,5 +1,5 @@ /* - FACADE.hpp - access point for communicating with the Proc-Interface + FACADE.hpp - access point for communicating with the Steam-Interface Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -21,7 +21,7 @@ */ /** @file facade.hpp - ** Top level entrance point and facade for the Proc-Layer. + ** Top level entrance point and facade for the Steam-Layer. ** The middle layer of the application holds a session with the high-level model, ** to be translated by the Builder into a node network, which can be _performed_ ** by the Engine to render output. @@ -44,12 +44,12 @@ namespace proc { - /*****************************************************************//** - * Global access point for the services implemented by the Proc-Layer. + /******************************************************************//** + * Global access point for the services implemented by the Steam-Layer. * * @todo this is a dummy placeholder as of 1/2009. Currently, there - * is only implementation-level code within the Proc-Layer and - * the interfaces need to be worked out. + * is only implementation-level code within the Steam-Layer + * and the interfaces need to be worked out. * @todo at least the Play/Output subsystem slowly turns into * something real, as of 6/2011 * @todo and as of 1/2017, the Session subsystem is basically @@ -74,7 +74,7 @@ namespace proc { static lumiera::Subsys& getPlayOutDescriptor(); - //////////////////TODO: define the global access interfaces for the Proc-Layer + //////////////////TODO: define the global access interfaces for the Steam-Layer //////////////////TODO: provide a function for accessing this interface //////////////////TODO: register similar proxy/facade interfaces for the GUI diff --git a/src/proc/mobject/builderfacade.hpp b/src/proc/mobject/builderfacade.hpp index 2148e651b..4ff700ca9 100644 --- a/src/proc/mobject/builderfacade.hpp +++ b/src/proc/mobject/builderfacade.hpp @@ -22,7 +22,7 @@ /** @file builderfacade.hpp - ** Proc-Layer Facade: access to the Builder. + ** Steam-Layer Facade: access to the Builder. ** The Builder walks the Session model to compile a corresponding render node network. ** ** @todo as of 2016 the builder, as the most crucial component within the architecture, diff --git a/src/proc/mobject/explicitplacement.hpp b/src/proc/mobject/explicitplacement.hpp index 655a4c6a1..3d1110994 100644 --- a/src/proc/mobject/explicitplacement.hpp +++ b/src/proc/mobject/explicitplacement.hpp @@ -28,7 +28,7 @@ ** together. However, placements are typically only defined in parts, and what ** is left out in the definition is assumed to be _"obvious from the context"._ ** - ** The core operation within Proc-Layer is the Builder run, which walks the Session model + ** The core operation within Steam-Layer is the Builder run, which walks the Session model ** to resolve and fill in all the contextual information. The result is a completely resolved ** Placement for each actually visible and relevant entity. Such is represented as ExplicitPlacement. ** These are arranged into the backbone structure, the Fixture, and the actual render node network diff --git a/src/proc/mobject/session/dummy-session-connection.cpp b/src/proc/mobject/session/dummy-session-connection.cpp index fcbd37adc..748e56c2b 100644 --- a/src/proc/mobject/session/dummy-session-connection.cpp +++ b/src/proc/mobject/session/dummy-session-connection.cpp @@ -153,7 +153,7 @@ namespace cmd { /* ============ dedicated Fake-Commands ============ */ /** Populate the Timeline in the UI with a typical simple Dummy sequence. - * This Proc-Layer command script fabricates a faked "population diff", which not + * This Steam-Layer command script fabricates a faked "population diff", which not * corresponds to any existing session data structure, but looks as if emanated while * loading current session state. * - one single Timeline diff --git a/src/proc/mobject/session/dummy-session-connection.hpp b/src/proc/mobject/session/dummy-session-connection.hpp index 745785420..0e5f38ff2 100644 --- a/src/proc/mobject/session/dummy-session-connection.hpp +++ b/src/proc/mobject/session/dummy-session-connection.hpp @@ -80,7 +80,7 @@ namespace session { /** * Scaffolding to drive the evolution of the Lumiera application. * @todo as of 2018, the most pressing problem is to establish the interplay between - * GUI-Layer and Proc-Layer, so the software gains some tangible functionality... + * Stage-Layer and Steam-Layer, so the software gains some tangible functionality... * @note readily-available singleton to enact prototypical behaviour as appropriate. * * @see DummySessionConnection_test diff --git a/src/proc/mobject/session/placement-index-query-resolver.hpp b/src/proc/mobject/session/placement-index-query-resolver.hpp index c786bf5bd..bd6877702 100644 --- a/src/proc/mobject/session/placement-index-query-resolver.hpp +++ b/src/proc/mobject/session/placement-index-query-resolver.hpp @@ -26,7 +26,7 @@ ** This wrapper adds a service to resolve queries for exploring the contents or ** the parent path of a given scope; the actual implementation relies on the ** basic operations provided by the PlacementIndex; usually this wrapper is - ** instantiated as one of the SessionServices for use by Proc-Layer internals. + ** instantiated as one of the SessionServices for use by Steam-Layer internals. ** The PlacementIndex to use for the implementation is handed in to the ctor. ** ** As any of the QueryResolver services, the actual resolution is completely diff --git a/src/proc/mobject/session/placement-index.hpp b/src/proc/mobject/session/placement-index.hpp index 480be0528..d8a37337f 100644 --- a/src/proc/mobject/session/placement-index.hpp +++ b/src/proc/mobject/session/placement-index.hpp @@ -25,7 +25,7 @@ ** Core of the session implementation datastructure. ** The PlacementIndex is attached to and controlled by the SessionImpl. ** Client code is not intended to interface directly to this API. Even - ** Proc-Layer internal facilities use the session datastructure through + ** Steam-Layer internal facilities use the session datastructure through ** SessionServices. Embedded within the implementation of PlacementIndex ** is a flat table structure holding all the Placement instances \em contained ** in the session. Any further structuring exists on the logical level only. @@ -36,7 +36,7 @@ ** "the object instance" within the session. As long as this instance isn't removed from ** the session / PlacementIndex, a direct (language) reference can be used to work with ** "the object instance"; accessing this way is adequate for implementation code living - ** within Lumiera's Proc-Layer. + ** within Lumiera's Steam-Layer. ** ** To avoid the dangerous dependency on a direct reference, external code would rather ** rely on the Placement-ID. Moreover, being a simple value, such an ID can be passed @@ -74,7 +74,7 @@ ** The reverse operation is also possible: given a scope-defining Placement, we can ** \em discover all the other Placements directly contained within this scope: ** \c getReferrers(ID) returns an (possibly empty) "Lumiera Forward Iterator", - ** allowing to enumerate the nested elements. Client code within Lumiera's Proc-Layer + ** allowing to enumerate the nested elements. Client code within Lumiera's Steam-Layer ** typically uses this functionality through a ScopeQuery passed to the SessionServices, ** while external client code would use either QueryFocus and the Scope wrapper objects, ** or the specific query functions available on the facade objects accessible through @@ -87,7 +87,7 @@ ** be casted into a more specifically typed Placement, thus allowing to re-gain ** the fully typed context. This technique plays an important role when it comes ** to generic processing of the session contents by a visitor, and especially - ** within the Builder. This is a fundamental design decision within Proc-Layer: + ** within the Builder. This is a fundamental design decision within Steam-Layer: ** code should not operate on MObjects and do type/capability queries -- rather ** any processing is assumed to happen in a suitable typed context. Consequently, ** client code will never need to fetch Placements directly from the index. This diff --git a/src/proc/mobject/session/root.cpp b/src/proc/mobject/session/root.cpp index 4ed24cd2e..bb435d123 100644 --- a/src/proc/mobject/session/root.cpp +++ b/src/proc/mobject/session/root.cpp @@ -51,7 +51,7 @@ namespace session { * @return an embedded LUID tagged with the type of the session::Root. * This ID is suitable to be used in model diff and as ID on * the UI-Bus to address the corresponding representations - * in Proc-Layer and UI-Layer + * in Steam-Layer and Stage-Layer */ lib::idi::EntryID Root::getID() diff --git a/src/proc/mobject/session/sess-manager-impl.hpp b/src/proc/mobject/session/sess-manager-impl.hpp index 8c31f7b29..f728888b3 100644 --- a/src/proc/mobject/session/sess-manager-impl.hpp +++ b/src/proc/mobject/session/sess-manager-impl.hpp @@ -81,7 +81,7 @@ namespace session { public: - /* ==== proc layer internal API ==== */ + /* ==== steam layer internal API ==== */ virtual SessionImplAPI* operator-> () noexcept override; diff --git a/src/proc/mobject/session/session-impl.hpp b/src/proc/mobject/session/session-impl.hpp index 20142690a..54f8c3d41 100644 --- a/src/proc/mobject/session/session-impl.hpp +++ b/src/proc/mobject/session/session-impl.hpp @@ -30,7 +30,7 @@ ** This file contains the implementation level API, it should never ** be included by client code. Besides the actual SessionImpl, a set ** of further implementation level services is provided for use by - ** Proc-Layer's internals. These additional SessionServices are to be + ** Steam-Layer's internals. These additional SessionServices are to be ** accessed through dedicated headers and interface classes (typically ** through static access functions), thereby abstracting from the actual ** session implementation. Within this file, the implementation of these @@ -110,7 +110,7 @@ namespace session { - /* ===== providing internal services for Proc ===== */ + /* ===== providing internal services for Steam ===== */ template struct ServiceAccessPoint diff --git a/src/proc/mobject/session/session-interface-modules.hpp b/src/proc/mobject/session/session-interface-modules.hpp index c729088e7..6d85c2950 100644 --- a/src/proc/mobject/session/session-interface-modules.hpp +++ b/src/proc/mobject/session/session-interface-modules.hpp @@ -56,7 +56,7 @@ ** In any case, ctor and dtor of Timeline and Sequence have to care for proper ** registration into the SessionInterfaceModules for timelines and sequences ** respectively. This is accomplished by using kind-of a backdoor, a SessionServices (???) - ** (proc internal API) definition, allowing direct communication on implementation + ** (steam internal API) definition, allowing direct communication on implementation ** level, without the need to expose this access point on the public session API. ** The lib::ElementTracker configured in ( ??? ) receives these ** calls to maintain a list of asset smart-ptrs diff --git a/src/proc/mobject/session/session-services.cpp b/src/proc/mobject/session/session-services.cpp index f22b81850..078322d87 100644 --- a/src/proc/mobject/session/session-services.cpp +++ b/src/proc/mobject/session/session-services.cpp @@ -1,5 +1,5 @@ /* - SessionServices - accessing Proc-Layer internal session implementation services + SessionServices - accessing Steam-Layer internal session implementation services Copyright (C) Lumiera.org 2008, Hermann Vosseler diff --git a/src/proc/mobject/session/session-services.hpp b/src/proc/mobject/session/session-services.hpp index 9545d7bae..e0f79e0ec 100644 --- a/src/proc/mobject/session/session-services.hpp +++ b/src/proc/mobject/session/session-services.hpp @@ -1,5 +1,5 @@ /* - SESSION-SERVICES.hpp - accessing Proc-Layer internal session implementation services + SESSION-SERVICES.hpp - accessing Steam-Layer internal session implementation services Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -25,9 +25,9 @@ ** A mechanism for exposing and accessing implementation level ** services of the session. While any client code should always ** use the public Session API, some implementation level facilities - ** within Proc-Layer need to cooperate with a wider SessionImpl API. + ** within Steam-Layer need to cooperate with a wider SessionImpl API. ** On the other hand, we don't want to create coupling between the - ** mentioned Proc internals and the session implementation. Another + ** mentioned Steam internals and the session implementation. Another ** concern addressed by this mechanism is to assure consistency ** across all those implementation APIs. New APIs can be added ** just by extending a template definition and will automatically @@ -36,11 +36,11 @@ ** ** \par structure of session implementation-level services ** - ** Assumed any part of the Proc implementation needs to cooperate + ** Assumed any part of the Steam implementation needs to cooperate ** with the session implementation; the necessary link has to be ** abstracted into an implementation level API. Typically, this ** API provides an static access function, which is to be implemented - ** "somewhere else", so the Proc implementation isn't required to + ** "somewhere else", so the Steam implementation isn't required to ** include anything of the session implementation level ** ** In order to actually provide such a service, an specialisation of @@ -107,7 +107,7 @@ namespace session { * to provide by the Session. An instance of this template * is created on top of SessionImpl, configured such as * to inherit from all the concrete services to be - * exposed for use by Proc-Lyer's internals. + * exposed for use by Steam-Layer's internals. * * @param APIS sequence of API types to implement * @param FRONT type of the frontend used for access diff --git a/src/proc/mobject/session/session.cpp b/src/proc/mobject/session/session.cpp index 27f062b80..3b84db651 100644 --- a/src/proc/mobject/session/session.cpp +++ b/src/proc/mobject/session/session.cpp @@ -73,7 +73,7 @@ namespace mobject { SessManager& Session::current = theSessionManager(); - /** special access point allowing Proc-Layer internals + /** special access point allowing Steam-Layer internals * to cooperate with session implementation level APIs */ template<> diff --git a/src/proc/play/dummy-player-interface-proxy.cpp b/src/proc/play/dummy-player-interface-proxy.cpp index 8435e8737..411cd3a3f 100644 --- a/src/proc/play/dummy-player-interface-proxy.cpp +++ b/src/proc/play/dummy-player-interface-proxy.cpp @@ -41,7 +41,7 @@ ** proxy used by the client code to access the interface). ** ** @see dummy-player-facade.hpp - ** @see dummy-player-service.hpp actual implementation within the Proc-Layer + ** @see dummy-player-service.hpp actual implementation within the Steam-Layer ** @deprecated obsolete early design draft from 2009; ** as of 2018 only kept in source to compile some likewise obsolete UI widgets. */ diff --git a/src/proc/play/dummy-player-service.cpp b/src/proc/play/dummy-player-service.cpp index 206757e57..11a50e0b8 100644 --- a/src/proc/play/dummy-player-service.cpp +++ b/src/proc/play/dummy-player-service.cpp @@ -115,7 +115,7 @@ namespace proc { ) , LUMIERA_INTERFACE_INLINE (brief, const char*, (LumieraInterface ifa), - { (void)ifa; return "Proc Interface: dummy player to test integration with the GUI"; } + { (void)ifa; return "Steam Interface: dummy player to test integration with the GUI"; } ) , LUMIERA_INTERFACE_INLINE (homepage, const char*, (LumieraInterface ifa), diff --git a/src/proc/play/dummy-player-service.hpp b/src/proc/play/dummy-player-service.hpp index b91b560e1..de77ca2a0 100644 --- a/src/proc/play/dummy-player-service.hpp +++ b/src/proc/play/dummy-player-service.hpp @@ -21,7 +21,7 @@ */ /** @file dummy-player-service.hpp - ** A public service provided by the Proc-Layer, implementing a dummy/mockup playback process. + ** A public service provided by the Steam-Layer, implementing a dummy/mockup playback process. ** This is a design sketch; Lumiera isn't able to generate rendered output as of 2/2009. The ** idea is, that for each ongoing calculation process, there is a ProcessImpl instance holding ** the necessary handles and allocations and providing an uniform API to the client side. diff --git a/src/proc/play/output-slot.hpp b/src/proc/play/output-slot.hpp index 8cb7a7baf..2c98d1599 100644 --- a/src/proc/play/output-slot.hpp +++ b/src/proc/play/output-slot.hpp @@ -25,7 +25,7 @@ ** OutputSlot is the central metaphor for the organisation of actual (system level) outputs; ** using this concept allows to separate and abstract the data calculation and the organisation ** of playback and rendering from the specifics of the actual output sink. Actual output - ** possibilities can be added and removed dynamically from various components (backend, GUI), + ** possibilities can be added and removed dynamically from various components (vault, stage), ** all using the same resolution and mapping mechanisms ** ** Each OutputSlot is an unique and distinguishable entity. It corresponds explicitly to an diff --git a/src/proc/state.hpp b/src/proc/state.hpp index 618b71b7b..593a30a48 100644 --- a/src/proc/state.hpp +++ b/src/proc/state.hpp @@ -49,8 +49,8 @@ namespace engine { /** * Abstraction to access the state of a currently ongoing render/calculation process, - * as it is tied to the supporting facilities of the backend. An State (subclass) instance - * is the sole connection for the render node to invoke services of the backend needed + * as it is tied to the supporting facilities of the vault layer. An State (subclass) instance + * is the sole connection for the render node to invoke services of the vault needed * to carry out the calculations. * * @see engine::RenderInvocation top-level entrance point diff --git a/src/proc/streamtype.hpp b/src/proc/streamtype.hpp index 7522dc1e6..412d936d0 100644 --- a/src/proc/streamtype.hpp +++ b/src/proc/streamtype.hpp @@ -22,7 +22,7 @@ /** @file streamtype.hpp ** Framework for classification of media streams. - ** Besides the actual implementation type of a media stream, the Proc-Layer + ** Besides the actual implementation type of a media stream, the Steam-Layer ** needs a more general way for accessing, comparing and manipulating media streams ** based on type information. ** diff --git a/tests/40core.tests b/tests/40core.tests index 8cc2623d0..4be87ba21 100644 --- a/tests/40core.tests +++ b/tests/40core.tests @@ -1,4 +1,4 @@ -TESTING "Proc-Layer Foundations: basics and fundamental facilities" ./test-suite --group=common +TESTING "Steam-Layer Foundations: basics and fundamental facilities" ./test-suite --group=common diff --git a/tests/42query.tests b/tests/42query.tests index 46b82366f..adbf718d4 100644 --- a/tests/42query.tests +++ b/tests/42query.tests @@ -1,4 +1,4 @@ -TESTING "Proc Layer config rules Test Suite" ./test-suite --group=query +TESTING "Steam Layer config rules Test Suite" ./test-suite --group=query diff --git a/tests/45controller.tests b/tests/45controller.tests index 22c6c2322..cd61264f5 100644 --- a/tests/45controller.tests +++ b/tests/45controller.tests @@ -1,4 +1,4 @@ -TESTING "Component Test Suite: Proc-Layer controller" ./test-suite --group=controller +TESTING "Component Test Suite: Steam-Layer controller" ./test-suite --group=controller diff --git a/tests/48proc-operate.tests b/tests/48proc-operate.tests index afa182280..1737e8d77 100644 --- a/tests/48proc-operate.tests +++ b/tests/48proc-operate.tests @@ -1,4 +1,4 @@ -TESTING "Proc Layer combined operations Test Suite" ./test-suite --group=operate +TESTING "Steam Layer combined operations Test Suite" ./test-suite --group=operate diff --git a/tests/SConscript b/tests/SConscript index c1d249ad3..26247a145 100644 --- a/tests/SConscript +++ b/tests/SConscript @@ -25,7 +25,7 @@ def linkContext(id): if id.startswith('lib'): return app_lib # tests in 'lib*' subdirs only linked against application framework elif id.startswith('back'): - return backend_lib # tests in 'back*' subdirs only linked against backend layer + return backend_lib # tests in 'back*' subdirs only linked against vault layer elif id.startswith('gui'): return guimodule+core_lib # tests in 'gui*' are additionally linked against the GTK GUI module else: diff --git a/tests/basics/stream-type-lifecycle-test.cpp b/tests/basics/stream-type-lifecycle-test.cpp index 1e41dbb4a..1835807e4 100644 --- a/tests/basics/stream-type-lifecycle-test.cpp +++ b/tests/basics/stream-type-lifecycle-test.cpp @@ -64,10 +64,10 @@ namespace test_format { /***************************************************************//** * @test check the stream type registration lifecycle. * Any internal or external component (plugin) can extend - * the Proc Layer's registry of media stream types. + * the Steam Layer's registry of media stream types. * There is a basic pristine set of type information, which is - * restored automatically everytime the STypeManager is reset, - * which in turn happenes before loading a (new) Session. + * restored automatically every time the STypeManager is reset, + * which in turn happens before loading a (new) Session. */ class StreamTypeLifecycle_test : public Test { @@ -81,7 +81,7 @@ namespace test_format { /** @test this test defines a new (dummy) type info - * and schedules it for setop in the pristine state; + * and schedules it for setup in the pristine state; * check this info is actually present after resetting * the stream type manager, while other additional info * \em not scheduled in this manner is not present diff --git a/tests/core/proc/asset/media-structure-query-test.cpp b/tests/core/proc/asset/media-structure-query-test.cpp index df448dcc0..e2e03ff56 100644 --- a/tests/core/proc/asset/media-structure-query-test.cpp +++ b/tests/core/proc/asset/media-structure-query-test.cpp @@ -47,14 +47,14 @@ namespace test { /*******************************************************************//** * This test documents the Interface used by MediaFactory when loading - * media files for querying Lumiera's backend layer for information + * media files for querying Lumiera's vault layer for information * on how the media file is structured. */ class MediaStructureQuery_test : public Test { virtual void run(Arg) { - UNIMPLEMENTED ("querying media file structure from backend"); + UNIMPLEMENTED ("querying media file structure from vault"); } diff --git a/tests/core/proc/asset/typed-id-test.cpp b/tests/core/proc/asset/typed-id-test.cpp index 737b71901..23ba5e948 100644 --- a/tests/core/proc/asset/typed-id-test.cpp +++ b/tests/core/proc/asset/typed-id-test.cpp @@ -67,7 +67,7 @@ namespace test { }}}} -namespace lumiera{ ///////TODO: shouldn't that be namespace lib? or proc? +namespace lumiera{ ///////TODO: shouldn't that be namespace lib? or steam? namespace query { /** diff --git a/tests/core/proc/control/command-basic-test.cpp b/tests/core/proc/control/command-basic-test.cpp index 51a6e5ae3..d6807625e 100644 --- a/tests/core/proc/control/command-basic-test.cpp +++ b/tests/core/proc/control/command-basic-test.cpp @@ -75,7 +75,7 @@ namespace test { /***********************************************************************//** - * @test basic usage of the Proc-Layer command dispatch system. + * @test basic usage of the Steam-Layer command dispatch system. * Shows how to define a simple command inline and how to * trigger execution and UNDO. Verifies the command action * takes place and is reverted again by the UNDO function. diff --git a/tests/core/proc/control/command-mutation-test.cpp b/tests/core/proc/control/command-mutation-test.cpp index 52b811010..7b4a29f0b 100644 --- a/tests/core/proc/control/command-mutation-test.cpp +++ b/tests/core/proc/control/command-mutation-test.cpp @@ -1,5 +1,5 @@ /* - CommandMutation(Test) - checking the functor and undo-functor used within Proc-commands + CommandMutation(Test) - checking the functor and undo-functor used within Steam-commands Copyright (C) Lumiera.org 2009, Hermann Vosseler @@ -73,7 +73,7 @@ namespace test { /***********************************************************************//** * Verify the behaviour of the type erased closure, which is used - * by Proc-Layer commands to implement the capturing and later + * by Steam-Layer commands to implement the capturing and later * re-invocation of a function. * * @see control::Command diff --git a/tests/core/proc/control/memento-tie-test.cpp b/tests/core/proc/control/memento-tie-test.cpp index c26c75411..f4b0da5e0 100644 --- a/tests/core/proc/control/memento-tie-test.cpp +++ b/tests/core/proc/control/memento-tie-test.cpp @@ -71,7 +71,7 @@ namespace test { /*************************************************************************************//** * @test Verify the state capturing mechanism (memento), which is used to implement - * the Undo() functionality for Proc-Layer commands. Bind an undo function and a state + * the Undo() functionality for Steam-Layer commands. Bind an undo function and a state * capturing function and wire up both to store and retrieve a memento value. * Verify that after closing the functions, actually state is captured by each invocation. * diff --git a/tests/core/proc/engine/node-source-test.cpp b/tests/core/proc/engine/node-source-test.cpp index 1b4a95390..e34b64042 100644 --- a/tests/core/proc/engine/node-source-test.cpp +++ b/tests/core/proc/engine/node-source-test.cpp @@ -46,7 +46,7 @@ namespace test { { virtual void run(Arg) { - UNIMPLEMENTED ("render node pulling source data from backend"); + UNIMPLEMENTED ("render node pulling source data from vault"); } }; diff --git a/tests/core/proc/mobject/controller/render-segment-test.cpp b/tests/core/proc/mobject/controller/render-segment-test.cpp index 17d851f76..1fbfe65aa 100644 --- a/tests/core/proc/mobject/controller/render-segment-test.cpp +++ b/tests/core/proc/mobject/controller/render-segment-test.cpp @@ -1,5 +1,5 @@ /* - RenderSegment(Test) - Proc-Layer integration test + RenderSegment(Test) - Steam-Layer integration test Copyright (C) Lumiera.org 2008, Hermann Vosseler @@ -42,9 +42,9 @@ namespace test { /****************************************************************//** * @test create a render process from a given segment of the Session. * Basically this includes cooperation of all parts of the - * Lumiera Proc Layer. For a prepared test-Session we invoke the + * Lumiera Steam Layer. For a prepared test-Session we invoke the * controller to create a render process. This includes building - * the render pipeline. Finally, we analyze all the created + * the render pipeline. Finally, we analyse all the created * Structures. * @note this test doesn't cover the actual rendering. * @see proc_interface::ControllerFacade diff --git a/tests/core/proc/mobject/session/session-service-access-test.cpp b/tests/core/proc/mobject/session/session-service-access-test.cpp index ecb837c7f..0c0b849d1 100644 --- a/tests/core/proc/mobject/session/session-service-access-test.cpp +++ b/tests/core/proc/mobject/session/session-service-access-test.cpp @@ -279,7 +279,7 @@ namespace test { /***************************************************************************//** * Verify the access mechanism both to the pubic session API and - * to implementation level APIs used by Proc-Layer internals. + * to implementation level APIs used by Steam-Layer internals. * * Actually, this test uses a simulated setup of the real session, * complete with interfaces, implementation and session manager frontend. @@ -323,7 +323,7 @@ namespace test { /** example of an one-liner, as it might be used - * internally by implementation code within Proc-Layer */ + * internally by implementation code within Steam-Layer */ uint magic() { return InternalAPI_1::access().getMagic(); } /** @test accessing implementation-level APIs */ diff --git a/tests/gui/abstract-tangible-test.cpp b/tests/gui/abstract-tangible-test.cpp index 2bc76eb68..87008526c 100644 --- a/tests/gui/abstract-tangible-test.cpp +++ b/tests/gui/abstract-tangible-test.cpp @@ -315,7 +315,7 @@ namespace test { MARK_TEST_FUN EventLog nexusLog = gui::test::Nexus::startNewLog(); - // Setup test stage: define a command/action "in Proc" + // Setup test stage: define a command/action "in Steam" CommandDef (DUMMY_CMD_ID) .operation (operate) .captureUndo (capture) diff --git a/tests/gui/session-structure-mapping-test.cpp b/tests/gui/session-structure-mapping-test.cpp index 148a59187..c4a615555 100644 --- a/tests/gui/session-structure-mapping-test.cpp +++ b/tests/gui/session-structure-mapping-test.cpp @@ -24,7 +24,7 @@ /** @file session-structure-mapping-test.cpp ** This test is a concept study how to organise the proxy model ** in the Lumiera GUI. This mediating model shields access to the - ** actual "high-level model" in Proc-Layer, it translates signals + ** actual "high-level model" in Steam-Layer, it translates signals ** into command invocations and helps to push structure changes ** up to the timeline display. ** diff --git a/tests/gui/test/placeholder-command.hpp b/tests/gui/test/placeholder-command.hpp index cd4528168..898ade4cd 100644 --- a/tests/gui/test/placeholder-command.hpp +++ b/tests/gui/test/placeholder-command.hpp @@ -24,7 +24,7 @@ /** @file placeholder-command.hpp ** Generate fake commands with stub operations and the ability to verify invocation. ** This helper for unit testing of UI interactions might serve as dummy placeholder, - ** or be used to mock some operation expected to happen within Proc-Layer. The test::Nexus + ** or be used to mock some operation expected to happen within Steam-Layer. The test::Nexus ** offers a convenience front-end to install such an placeholder operation and use it ** as counterpart for some tested elements connected to the UI-bus. ** @@ -64,7 +64,7 @@ namespace test{ /** * Set of stub command operations. * This is a typed definition frame with some operations, - * suitably to be bound into a Proc-Layer command. The actual + * suitably to be bound into a Steam-Layer command. The actual * command "operation" just logs invocation into a statically * obtained [Event-Log](\ref EventLog) instance. * @note by design, in Lumiera the actual command functions are stateless. diff --git a/tests/gui/test/test-nexus.cpp b/tests/gui/test/test-nexus.cpp index 597cc3cd8..33a29f62f 100644 --- a/tests/gui/test/test-nexus.cpp +++ b/tests/gui/test/test-nexus.cpp @@ -402,7 +402,7 @@ namespace test{ * in the test-UI-Bus. In the real Lumiera-UI, the UI-Bus * is wired with a [core service handler](\ref core-service.hpp), * which processes command messages by actually triggering - * command invocation on the Session within Proc-Layer + * command invocation on the Session within Steam-Layer * @note when called without arguments, a default handler * will be installed, which just logs and discards * any command invocation message. diff --git a/tests/gui/test/test-nexus.hpp b/tests/gui/test/test-nexus.hpp index 3cb9c8a15..118841057 100644 --- a/tests/gui/test/test-nexus.hpp +++ b/tests/gui/test/test-nexus.hpp @@ -32,7 +32,7 @@ ** of a test rigged mock interface backbone remains an implementation detail. The purpose ** of this setup is to capture messages sent from elements operated within a test setup ** and directed at "core services" (that is, towards a presentation state manager or - ** towards the Proc-Layer for command invocation). Test code may then verify the + ** towards the Steam-Layer for command invocation). Test code may then verify the ** proper shape and incidence of these messages. ** ** @see [abstract-tangible-test.cpp] @@ -121,9 +121,9 @@ namespace test{ /** - * Setup of test fixture: prepare a mocked Proc-Layer command, + * Setup of test fixture: prepare a mocked Steam-Layer command, * which accepts arguments with the denoted types. - * @note this call installs the command mock into the Proc-Layer + * @note this call installs the command mock into the Steam-Layer * command registry, where it remains in place until shutdown. * The can be accessed through the generated command ID. Besides, * this call also installs a command handler into the Test-Nexus, diff --git a/tests/library/c-lib/test-psplay.c b/tests/library/c-lib/test-psplay.c index fd9760f6b..2b2753814 100644 --- a/tests/library/c-lib/test-psplay.c +++ b/tests/library/c-lib/test-psplay.c @@ -23,7 +23,7 @@ /** @file test-psplay.c ** C unit test to cover a probabilistic splay tree library implementation. ** These tree data structures are used as key-value store in several of the - ** management facilities of the backend + ** management facilities of the vault ** @see psplay.h */ diff --git a/tests/library/exception-error-test.cpp b/tests/library/exception-error-test.cpp index 104883e7f..0a9565108 100644 --- a/tests/library/exception-error-test.cpp +++ b/tests/library/exception-error-test.cpp @@ -59,7 +59,7 @@ namespace lumiera { /******************************************************//** * Some aspects of C++ exception handling. * Not to be confused with the basic C-style error value - * mechanism used by the low-level parts of the backend. + * mechanism used by the low-level parts of the vault. * Both approaches are largely orthogonal, but the * C++ exception handling uses the C-style error constants. *