ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Global-Layer-Renaming: adapt lots of documentation

Browse source
This commit is contained in:
Fischlurch 2018-11-15 21:13:52 +01:00
parent 24d421c6ed
commit 9e951e1eeb
152 changed files with 354 additions and 354 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/design/application/Config.txt
View file

@ -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.

2
doc/design/architecture/TimeQuant.txt
View file

@ -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.

8
doc/design/architecture/playRender.txt
View file

@ -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;

22
doc/design/backend/index.txt
View file

@ -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.

2
doc/design/engine/PlayModes.txt
View file

@ -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.

10
doc/design/gui/GuiDiscussion/TimelineDiscussion.txt
View file

@ -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

7
doc/devel/rfc/ArchitectureOverview.txt
View file

@ -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

23
doc/devel/rfc/DesignRenderNodesInterface.txt
View file

@ -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)

4
doc/devel/rfc/EDLsAreMetaClips.txt
View file

@ -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.

2
doc/devel/rfc/EngineInterfaceOverview.txt
View file

@ -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

2
doc/devel/rfc/FeatureBundle_PluggableModules.txt
View file

@ -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.

2
doc/devel/rfc/LumieraForwardIterator.txt
View file

@ -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

2
doc/devel/rfc/MarbleMode.txt
View file

@ -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)

12
doc/devel/rfc/ProcBuilder.txt
View file

@ -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.

10
doc/devel/rfc/ProcHighLevelModel.txt
View file

@ -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

8
doc/devel/rfc/ProcPlacementMetaphor.txt
View file

@ -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

4
doc/devel/rfc/Roadmap-first.txt
View file

@ -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.

6
doc/devel/rfc/SchedulerRequirements.txt
View file

@ -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

10
doc/devel/rfc/StreamTypeSystem.txt
View file

@ -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

4
doc/devel/rfc/TimelineSequenceOutput.txt
View file

@ -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

6
doc/technical/backend/index.txt
View file

@ -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:

22
doc/technical/code/linkingStructure.txt
View file

@ -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:

4
doc/technical/gui/CodePolicy.txt
View file

@ -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

10
doc/technical/gui/GuiConnect.txt
View file

@ -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.

10
doc/technical/infra/TestSupport.txt
View file

@ -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

2
doc/technical/library/index.txt
View file

@ -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

12
doc/technical/overview.txt
View file

@ -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.

12
doc/technical/proc/index.txt
View file

@ -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

16
doc/user/intro/intro.txt
View file

@ -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

4
src/backend/backend.c
View file

@ -1,5 +1,5 @@
/*
Backend - common lumiera backend facilities
Backend - common lumiera vault layer facilities
Copyright (C) Lumiera.org
2008, Christian Thaeter <ct@pipapo.org>
@ -22,7 +22,7 @@
/** @file backend.c
** Lumiera Backend: implementation of global initialisation and services.
** Lumiera Vault-Layer: implementation of global initialisation and services.
*/

4
src/backend/backend.h
View file

@ -1,5 +1,5 @@
/*
BACKEND.h - common lumiera backend definitions
BACKEND.h - common lumiera vault definitions
Copyright (C) Lumiera.org
2008, Christian Thaeter <ct@pipapo.org>
@ -22,7 +22,7 @@
/** @file backend.h
** Lumiera Backend: global initialisation and definitions.
** Lumiera Vault-Layer: global initialisation and definitions.
*/

4
src/backend/engine/job.cpp
View file

@ -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() { }

10
src/backend/engine/job.h
View file

@ -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;

6
src/backend/engine/scheduler-frontend.hpp
View file

@ -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

12
src/backend/enginefacade.hpp
View file

@ -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

4
src/backend/media-access-facade.cpp
View file

@ -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;
}

4
src/backend/media-access-facade.hpp
View file

@ -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

2
src/backend/netnodefacade.hpp
View file

@ -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

4
src/backend/real-clock.cpp
View file

@ -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
*/

2
src/backend/real-clock.hpp
View file

@ -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
**

2
src/backend/scriptrunnerfacade.hpp
View file

@ -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.
*

4
src/backend/thread-wrapper.hpp
View file

@ -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

4
src/backend/threadpool-init.hpp
View file

@ -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

2
src/backend/threads.h
View file

@ -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.

2
src/common/advice.hpp
View file

@ -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

2
src/common/advice/binding.hpp
View file

@ -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

2
src/common/advice/index.hpp
View file

@ -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

4
src/common/config-rules.hpp
View file

@ -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.

2
src/common/query.hpp
View file

@ -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

2
src/common/query/defs-manager-impl.hpp
View file

@ -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

4
src/gui/ctrl/bus-term.hpp
View file

@ -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.
*/

4
src/gui/ctrl/core-service.hpp
View file

@ -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.

14
src/gui/dialog/test-control.hpp
View file

@ -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 <b>roundtrip</b>\n"
"Proc invokes GuiNotification::displayInfo"));
trig_1_.set_tooltip_markup (_("Trigger Steam-Stage <b>roundtrip</b>\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 <b>state mark</b> message, using\n"
"the message action-ID from the combobox"));
actionID_.append (cuString{MARK_Flash});

10
src/gui/gtk-base.hpp
View file

@ -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

2
src/gui/model/clip.hpp
View file

@ -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.
*/

2
src/gui/model/parent-track.hpp
View file

@ -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

2
src/gui/model/project.cpp
View file

@ -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.
**

4
src/gui/model/project.hpp
View file

@ -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

2
src/gui/model/session-facade.cpp
View file

@ -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

2
src/gui/model/track.hpp
View file

@ -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

2
src/gui/ui-bus.hpp
View file

@ -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
{

2
src/gui/widget/timeline/timeline-header-container.hpp
View file

@ -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();

6
src/include/dummy-player-facade.h
View file

@ -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

2
src/include/gui-notification-facade.h
View file

@ -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

14
src/include/logging.h
View file

@ -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);

2
src/include/play-facade.hpp
View file

@ -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.
*

2
src/include/session-command-facade.h
View file

@ -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<GenNode>`.
** 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.

2
src/lib/frameid.hpp
View file

@ -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
*/

2
src/lib/safeclib.h
View file

@ -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);

2
src/lib/symbol.hpp
View file

@ -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.

6
src/lib/time.h
View file

@ -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

4
src/lib/time/formats.hpp
View file

@ -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

2
src/lib/time/quantiser.hpp
View file

@ -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.

2
src/lib/visitor.hpp
View file

@ -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

2
src/proc/asset.hpp
View file

@ -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.

4
src/proc/asset/typed-id.hpp
View file

@ -57,12 +57,12 @@
//#include <boost/operators.hpp>
#include <memory>
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.
*

2
src/proc/assetmanager.hpp
View file

@ -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.
**

6
src/proc/cmd.hpp
View file

@ -1,5 +1,5 @@
/*
CMD.hpp - Proc Command definition keys
CMD.hpp - Steam Command definition keys
Copyright (C) Lumiera.org
2017, Hermann Vosseler <Ichthyostega@web.de>
@ -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

14
src/proc/cmd/meta-cmd.cpp
View file

@ -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 <Ichthyostega@web.de>
@ -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)
{

4
src/proc/cmd/scope-cmd.cpp
View file

@ -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 <Ichthyostega@web.de>
@ -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

4
src/proc/cmd/sequence-cmd.cpp
View file

@ -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 <Ichthyostega@web.de>
@ -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
**

4
src/proc/cmd/session-cmd.cpp
View file

@ -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 <Ichthyostega@web.de>
@ -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

20
src/proc/common.hpp
View file

@ -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 {

2
src/proc/config-resolver.cpp
View file

@ -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.

2
src/proc/control/argument-erasure.hpp
View file

@ -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).
*/

4
src/proc/control/argument-tuple-accept.hpp
View file

@ -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<Types<T1...> >)
* @param BASE the base class for inheritance chaining

2
src/proc/control/command-closure.hpp
View file

@ -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.
**

2
src/proc/control/command-def.hpp
View file

@ -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 <Ichthyostega@web.de>

6
src/proc/control/command-impl.hpp
View file

@ -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 <Ichthyostega@web.de>
@ -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

4
src/proc/control/command-instance-manager.hpp
View file

@ -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

2
src/proc/control/command-invocation.hpp
View file

@ -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 <Ichthyostega@web.de>

6
src/proc/control/command-mutation.hpp
View file

@ -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 <Ichthyostega@web.de>
@ -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

2
src/proc/control/command-registry.hpp
View file

@ -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 <Ichthyostega@web.de>

2
src/proc/control/command-setup.cpp
View file

@ -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

6
src/proc/control/command-setup.hpp
View file

@ -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 <Ichthyostega@web.de>
@ -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,

4
src/proc/control/command-storage-holder.hpp
View file

@ -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<typename SIG, typename MEM>

2
src/proc/control/command.cpp
View file

@ -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 <Ichthyostega@web.de>

4
src/proc/control/command.hpp
View file

@ -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 <Ichthyostega@web.de>
@ -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

2
src/proc/control/handling-pattern.cpp
View file

@ -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.
*/

2
src/proc/control/handling-patterns.hpp
View file

@ -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

Some files were not shown because too many files have changed in this diff Show more