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

DOC: some further round-up and polishsing

Browse source
This commit is contained in:
Fischlurch 2013-10-28 06:12:05 +01:00
parent 2c4ed4ca91
commit d15ec47f9e
6 changed files with 46 additions and 64 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
doc/design/index.txt
View file

@ -13,16 +13,15 @@ Lumiera Design Documents
Lumiera is to be a professional tool for video editing on Lumiera is to be a professional tool for video editing on
GNU/Linux systems. The vision of the development team defines a modern design GNU/Linux systems. The vision of the development team defines a modern design
for the core of a Non-Linear Editing software. A key aspect of Lumiera for the core of a Non-Linear Editing software. A key aspect of Lumiera
is strong separation between the user interface and the processing core. is the strong separation between the user interface and the processing core.
Lumiera will have a GTK GUI but that will not be We are developing Lumiera with a GTK GUI but that will in no way be exclusive;
exclusive; other GUIs can be written, even by users, other GUIs can be written, as well as scripts to drive the core.
as well as scripts to drive the core. This becomes possible by an ongoing effort to decrease coupling. Each major
This is made possible by an ongoing effort to decrease coupling. Each major
component in the application strives to be open to extensions, but closed component in the application strives to be open to extensions, but closed
against external modification. The presentation, the model and the ``performing'' against external modification. The presentation, the model and the ``performing''
of the model are separate and self-contained parts of the application. Lumiera of the model are separate and self-contained parts of the application. Lumiera
as a processing core will be able to perform any conceivable as a processing core will be able to perform any conceivable
task on video and audio, even some unrelated to video editing. task on video and audio, maybe even tasks entirely unrelated to video editing.
.Workflow .Workflow
***************** *****************
@ -48,8 +47,8 @@ Graphical User Interface
User interfaces are implemented as plug-ins. As a consequence, it is User interfaces are implemented as plug-ins. As a consequence, it is
possible to interface with Lumiera through scripts. It is also possible to create possible to interface with Lumiera through scripts. It is also possible to create
specialised GUIs. The interface is the component that is closest to the user. It specialised GUIs. The interface is the component that is closest to the user. It
provides purely visual interaction with the user. There the user manipulates, provides purely visual interaction with the user. Within this work environment, the user
organizes, loads, configures all sorts of data, especially MObjects (media manipulates, organizes, loads, configures all sorts of data, especially MObjects (media
objects) and Assets. These elements are contained within a structure called the Session. + objects) and Assets. These elements are contained within a structure called the Session. +
-> link:gui/index.html[GUI design documents] -> link:gui/index.html[GUI design documents]
@ -57,16 +56,16 @@ objects) and Assets. These elements are contained within a structure called the
The Processing Layer The Processing Layer
~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
The processing layer (``Proc-layer'' or ``proc'') has several closely related aspects. The processing layer (``Proc-layer'' or ``proc'') covers several closely related aspects.
When the user works with the GUI, all the clips, effects and other components presented When the user works with the GUI, all the clips, effects and other visually presented
there are actually stored within the _Session model_ (``high-level model''). Any editing components are actually stored within the _Session model_ (``high-level model''). Any editing
operations initiated by the user are actually performed there. Next, after each change, operation initiated by the user is actually _executed_ in the context of the session. Next,
a component known as _the Builder_ assembles the contents of this model and transforms after each change, a component known as _the Builder_ assembles the contents of this session model
them to form a network of nodes, which can be _performed_ efficiently for rendering. to transform them into a network of nodes, which can be efficiently _performed_ for rendering.
Often, we refer to this node structure as the ``low-level model''. On rendering or Often, we refer to this node structure as the ``low-level model''. On rendering or
playback, the Proc-layer is responsible for accessing this node structure to playback, the Proc-layer is responsible for accessing this low-level node structure to
generate individual _frame render jobs,_ ready to be handed over to the backend, which generate individual _frame render jobs,_ ready to be handed over to the backend, which
performs the actual rendering calculations. + finally initiates the actual rendering calculations. +
-> more about the link:model/index.html[Model] + -> more about the link:model/index.html[Model] +
-> design of the link:engine/index.html[Engine] subsystem -> design of the link:engine/index.html[Engine] subsystem
@ -75,8 +74,8 @@ performs the actual rendering calculations. +
The Backend The Backend
~~~~~~~~~~~ ~~~~~~~~~~~
The backend uses the low-level model and the _render jobs_ generated by Proc. The backend attaches to the low-level model and the _render jobs_ generated by Proc.
It actually performs the rendering operations and makes heavy use of the It actually conducts the rendering operations and makes heavy use of the
Input/Output System for accessing media content and sending generated data to Input/Output System for accessing media content and sending generated data to
the screen or to external output. + the screen or to external output. +
-> link:backend/index.html[Backend design level documents] + -> link:backend/index.html[Backend design level documents] +

2
doc/devel/DIR_INFO
View file

@ -1,3 +1 @@
developer documentation, extra sources, doxygen developer documentation, extra sources, doxygen
dir uml: html documentation generated by BOUML

1
doc/devel/transcript/DIR_INFO Normal file
View file

@ -0,0 +1 @@
transcripts of relevant IRC discussions

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

@ -133,15 +133,15 @@ configuration example
[source,python] [source,python]
-------------------------------------------------------------------------- --------------------------------------------------------------------------
def addPredefined(): def addPredefined():
root = Node(TREE_ROOT, label='Lumiera') <1> root = Node(TREE_ROOT, label='Lumiera') # <1>
proj = root.linkChild('project') <2> proj = root.linkChild('project') # <2>
proj.linkChild('faq') proj.linkChild('faq')
proj.prependChild ('screenshots') <3> proj.prependChild ('screenshots') # <3>
proj.putChildLast ('press') proj.putChildLast ('press')
proj.putChildAfter('faq', refPoint=Node('screenshots')) <4> proj.putChildAfter('faq', refPoint=Node('screenshots')) # <4>
proj.link('http://issues.lumiera.org/roadmap', label="Roadmap (Trac)") <5> proj.link('http://issues.lumiera.org/roadmap', label="Roadmap (Trac)") # <5>
Node('rfc').sortChildren() Node('rfc').sortChildren()
-------------------------------------------------------------------------- --------------------------------------------------------------------------
<1> the _root node_ by convention uses a special ID token. Additional <1> the _root node_ by convention uses a special ID token. Additional

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

@ -424,7 +424,18 @@ rendering...
[[builder]] [[builder]]
builder builder
^^^^^^^ ^^^^^^^
[red]#to be written# The inner workings of Lumiera exhibit some striking similarities to the implementation
of a programming language compiler. On one side, there is a tree-like data structure
which represents the high-level meaning of the edit currently in the works. We call
this data structure the ``high-level model'' -- it is comprised of timelines and
sequences, tracks, bins, clips and effects. On the other side, the render engine
requires a properly wired network of low-level processing nodes, where every connection
has been made explicit, and any indirection has been resolved.
The *Builder* is the entity performing the translation between these both flip sides
of the coin: it creates the low-level processing graphs by traversing and evaluating
the relevant parts of the high-level-model. Indirections will be resolved and
connections will be made explicit by querying the _rules system_.
rules system rules system
^^^^^^^^^^^^ ^^^^^^^^^^^^
@ -492,13 +503,14 @@ libraries.
A library is used in an application by _linking_ the library into the A library is used in an application by _linking_ the library into the
application. (There are other things to be done, but we'll call these 'details', application. (There are other things to be done, but we'll call these 'details',
which wont concern us here.) There are different ways to _link_ a library which wont concern us here.) There are different ways to _link_ a library
into an application: statically linking and dynamically linking. into an application: linking statically and linking dynamically.
_Statically Linking_ is done while the application is being built, or _Static Linking_ is done while the application is being built, or
compiled. It is performed by the linker. The linker can perform some checks compiled. It is performed by the linker, which executes as the last step
(mostly checks on syntax) and warn the user that some particular feature is of the compilation process. The linker can perform some sanity checks
being used incorrectly. The user can then correct the offending code, and (mostly checks regarding formally correct function invocation) and warn the user
recompile. hat some particular feature is being used incorrectly. The user can then correct
the offending code, and recompile. +
There are a number of disadvantages associated with static linking. Features and There are a number of disadvantages associated with static linking. Features and
libraries are being constantly improved. If the application wants to use new libraries are being constantly improved. If the application wants to use new
features, it will have to be recompiled with the new library which provides the features, it will have to be recompiled with the new library which provides the
@ -531,11 +543,11 @@ How are Plugins Implemented?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
We can view Lumiera itself as being a slender application with many of the bells We can view Lumiera itself as being a slender application with many of the bells
and whistles being supplied __directly_ by external FOSS tools. Such tools will and whistles being supplied _directly_ by external FOSS tools. Such tools will
be made available to the Lumiera code base via the Lumiera Plugin Interface (LPI). be made available to the Lumiera code base via the Lumiera Plugin Interface (LPI).
As LPI will be used throughout most layers of Lumiera--from the low-level As LPI will be used throughout most layers of Lumiera -- from the low-level
backend, right up to the GUI--the interface will have to be compatible to both C backend, right up to the GUI -- the interface will have to be compatible to both C
and C++. In effect, this means that LPI will be implemented in C. and C++. In effect, this means that LPI will be implemented in C.
Using LPI a plugin interface can be defined for each external library. The Using LPI a plugin interface can be defined for each external library. The

30
src/lib/bool-checkable.hpp
View file

@ -21,34 +21,6 @@
*/ */
/** @file bool-checkable.hpp
** When working with generic function objects and function pointers typed to
** arbitrary signatures, often there is the necessity to hold onto such a functor
** while hiding the actual signature behind an common interface ("type erasure").
** The usual solution based on subclassing has the downside of requiring separate
** storage for the concrete functor object, which might become problematic when
** dealing with lots of functor objects.
**
** Especially when dealing with tr1::function objects, all of the type differences
** are actually encoded into 3 internal pointers, thus yielding the same size for
** all various types of functors. Building on this observation, we can create an
** common container object to store the varying functors inline, while hiding the
** actual signature.
**
** There remains the problem of re-accessing the concrete functor later on. As
** C++ has only rudimental introspection capabilities, we can only rely on the
** usage context to provide the correct function signature; only when using a
** virtual function for the re-access, we can perform at least a runtime-check.
**
** Thus there are various flavours for actually implementing this idea, and the
** picking a suitable implementation depends largely on the context. Thus we
** provide a common and expect the client code to pick an implementation policy.
**
** @see control::Mutation usage example
** @see function-erasure-test.cpp
**
*/
#ifndef LIB_BOOL_CHECKABLE_H #ifndef LIB_BOOL_CHECKABLE_H
#define LIB_BOOL_CHECKABLE_H #define LIB_BOOL_CHECKABLE_H
@ -63,7 +35,7 @@ namespace lib {
} }
/* /**
* Provide an implicit conversion to "bool". * Provide an implicit conversion to "bool".
* Inherit (mix-in) from this template by providing the * Inherit (mix-in) from this template by providing the
* concrete subclass type ("CRTP"). Additionally, to implement * concrete subclass type ("CRTP"). Additionally, to implement