Ichthyostega
501f92bc87
this is the entry point into the section holding the various design documents -- we try to separatte conceptual/design from the actual technical documentation
107 lines
4.7 KiB
Text
107 lines
4.7 KiB
Text
Lumiera Design Documents
|
|
========================
|
|
|
|
// Menu : prepend child design/backend
|
|
// Menu : prepend child engine
|
|
// Menu : prepend child model
|
|
// Menu : prepend child design/gui
|
|
// Menu : prepend child architecture
|
|
|
|
// Menu : append child plugins
|
|
// Menu : append child workflow
|
|
|
|
The goal of Lumiera is to provide a professional tool for video editing on
|
|
GNU/Linux systems. The vision of the development team defines a modern design
|
|
for the core of a Non-Linear Editing software. One of the key aspect of Lumiera
|
|
is the strong separation between the user interface and the processing core.
|
|
Lumiera as a software will come along with a GTK GUI but that does not make this
|
|
exclusive, any other GUI could be written as well as scripts to drive the core.
|
|
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
|
|
against external modification. The presentation, the model and the ``performing''
|
|
of the model are separate and self-contained parts of the application. Lumiera
|
|
as a processing core will be able to do anything possibly conceivable, therefore it
|
|
may be used to do any task on video (and audio?), even unrelated to video editing.
|
|
|
|
.Workflow
|
|
*****************
|
|
The word Workflow is used to name the way tasks can be achieved in an
|
|
application. Any operation in Lumiera must be possible in the most suitable and
|
|
stringent fashion. The Workflow is closely related to how flexible the GUI is
|
|
but also the concern of deeper and more technical parts of the application.
|
|
*****************
|
|
|
|
|
|
Overview
|
|
--------
|
|
|
|
The internal structure of Lumiera is divided in numerous subsystems. This
|
|
overview will try to go through the elements from the highest to the lowest
|
|
piece of the structure. They can be categorized into three main categories plus
|
|
extra components:
|
|
|
|
|
|
Graphical User Interface
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
User interfaces are basically included as a plugin, consequently it is possible
|
|
to interface with Lumiera through scripts. It is also possible to create
|
|
specialised GUIs. The interface is the closest component to the user, it is
|
|
purely visual. There the user manipulates, organizes, loads, configures all
|
|
sorts of data, especially MObjects (media objects) and Assets. These elements
|
|
are contained within a structure called the Session. +
|
|
-> link:gui/index.html[GUI design documents]
|
|
|
|
|
|
The Processing Layer
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The processing layer (``Proc-layer'' or ``proc'') covers several closely related aspects.
|
|
While the user works with the GUI, all the clips, effects and other components presented
|
|
there are actually stored within the _Session model_ (``high-level model''). Any editing
|
|
operations initiated by the user are actually performed here. Next, after each change,
|
|
a component known as _the Builder_ assembles the contents of this model and transforms
|
|
them to form a network of nodes, which can be _performed_ efficiently for rendering.
|
|
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
|
|
generate individual _frame render jobs,_ ready to be handed over to the backend
|
|
for the actual rendering calculations. +
|
|
-> more about the link:model/index.html[Model] +
|
|
-> design of the link:engine/index.html[Engine] subsystem
|
|
|
|
|
|
|
|
The Backend
|
|
~~~~~~~~~~~
|
|
|
|
The backend uses the Low-level model and the _render jobs_ generated by Proc.
|
|
It actually performs the the rendering operations and makes a heavy use of the
|
|
Input/Output System for accessing media content and sending generated data to
|
|
the screen or external output. +
|
|
-> link:backend/index.html[Backend design level documents] +
|
|
-> link:{ldoc}/technical/backend/index.html[technical documentation] +
|
|
|
|
|
|
Extra components
|
|
----------------
|
|
|
|
The Application
|
|
~~~~~~~~~~~~~~~
|
|
|
|
The application controls the initialization and shutdown procedures as well as
|
|
loading external elements like plugins that are widely used. It acts as a framework
|
|
to support the operation of the core components. This framework is complemented by
|
|
a library of commonly used components, algorithms and data structures. +
|
|
-> link:application/index.html[Application framework]
|
|
|
|
|
|
link:plugins/index.html[Plugins]
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Plugins play an important role within Lumiera since the application relies heavily
|
|
existing implementations and external libraries. Moreover, the application is envisioned
|
|
to be configurable and can be extended in various ways; whenever some extension isn't permanent
|
|
or will be used only on demand, it is packaged as separate module into a plug-in. For example,
|
|
the GUI of Lumiera is a plugin. +
|
|
-> design doruments regarding the link:plugins/index.html[Plugins]
|
|
|