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

Compare commits

base: ichthyo:9225d868bb7096d8d8fa268fefc8f4195f279f0e
Branches Tags
ichthyo:master
ichthyo:dev/play
ichthyo:integration
ichthyo:v0.pre.04
ichthyo:prg@ichthyostega.de/integration_signature
ichthyo:platform/Trixie
ichthyo:platform/Buster
ichthyo:platform/Jessie
ichthyo:0.pre.03
ichthyo:0.pre.02
ichthyo:0.pre.01
ichthyo:prg@ichthyostega.de/gui_signature
ichthyo:dummy-player
ichthyo:GUI-plugin-startup
ichthyo:Lumiera-is-born
..
compare: ichthyo:651cf144a5474ce54b52f072c31150ba6c7fbc6b
Branches Tags
ichthyo:dev/play
ichthyo:integration
ichthyo:master
ichthyo:v0.pre.04
ichthyo:prg@ichthyostega.de/integration_signature
ichthyo:platform/Trixie
ichthyo:platform/Buster
ichthyo:platform/Jessie
ichthyo:0.pre.03
ichthyo:0.pre.02
ichthyo:0.pre.01
ichthyo:prg@ichthyostega.de/gui_signature
ichthyo:dummy-player
ichthyo:GUI-plugin-startup
ichthyo:Lumiera-is-born

35 commits
9225d868bb ... 651cf144a5

Author SHA1 Message Date
Ichthyostega
651cf144a5 Release: general washdown 
- comb through the Website, starting at the frontpage
- add a **news** entry to confirm this major upgrade step (C++23)
- improve the wording in various overview pages
- adapt the ''release checklist'' to align it with **git-flow**
- reorganise the image folder(s) on the website
- the animated beating heart is back ;-)
 2025-11-30 21:22:23 +01:00
Ichthyostega
797174ef19 Release: extensive makeover of Build and Debian documentation 
On the Website, there is a set of interconnected pages related
to compiling from source, the Debian package and our DEB depot.

Although these pages have always been superficially kept up-to-date,
the overall presentation feels dated and generally not well organized.
During the last weeks, I have almost entirely rewritten all those pages,
added information about the (now reworked) DEB package, explained the
alternate ways to build from a Debian source package (notably the
`mk-build-deps` for handling the build dependencies, which effectively
the only method which always worked during the last years, since our
DEB package was totally outdated)

Furthermore, I have tested most of the build steps with the current
source trees, repositories and package definition, and finally I
have also updated and polished the front-page of our DEB-Depot
(-> see commit on the depot-Branch)

Wheew ... quite some work done!
 2025-11-29 18:04:30 +01:00
Ichthyostega
eb4c49e1b2 Build: upgrade, tighten and document the prerequisites 
Many versions enforced with this changeset are chosen such
as to support Ubuntu/Noble (24.04) and otherwise use versions
reasonably close to Debian-Trixie (≙reference-platform)

Since we now require a fairly modern compiler for C++23,
I have added now an explicit version check, which however
is performed only if the defined compiler is named `g++*`

Furthermore, I combed through all of our build tutorials and documentation pages
and updated a lot of information regarding dependencies and build practices...
 2025-11-28 04:24:52 +01:00
Ichthyostega
d24e025de2 Build: chase down and solve spurious SVG icon rebuilds 
Many years ago, I integrated the IconSvgRenderer (written by Joel Holdsworth)
directly into the SCons build by means of a custom builder with an ''emitter function''.

The build as such works fine and automatically determines which icons can be
generated from a given SVG source. However, those SVG icons tend to be rebuilt
very frequently, even while none of the SVG sources has changed.

Basically this was more of an annoyance, since we have now about 15 icons
and the rendering is really fast ... it is just ugly, especially on
incremental builds (and it could become a problem once we have a
massive amount of graphics to process.

So I took the opportunity to take close look now, since I am doing
uninspiring clean-up work since several weeks now. But that problem
turned out to be quite insidious and hard to spot.

First, AI set me off into a completely wrong angle, since it is ''not''
caused by a missing string representation of the custom Action class.
However, from there I went to watching the target checks with the debugger,
and this eventually got me to realise, that SCons mistakenly detects
a change in the Executor / the Action class.

The root cause is, that we invoke Python code from an external Module,
IconSvgRenderer.py, and this is »materialised« by SCons automatically
into a string representation, which includes memory addresses of functions
in that module. And that yields a signature, that is, quite obviously,
not stable, even while you end up sometimes with loading the code to
the same memory location.

As a solution / workaround, we now subclass the standard implementation
from SCons and override the signature function; instead of fingerprinting
the binary code, we just compute a MD5 over the python source file,
which can be easily achieved with the help of the File-Node from SCons.

Essential resources:
https://scons.org/doc/4.8.0/HTML/scons-user.html#chap-builders-writing

...and the Reference / Manpage of SCons
https://scons.org/doc/4.8.0/HTML/scons-man.html#action_objects

SCons/Action.py
SCons/Node/__init__.py
 2025-11-27 18:15:49 +01:00
Ichthyostega
8b2a329898 Build: some further code clean-up and documentation 
* Simplify some constructs from the Python-3 migration
 * update copyright, since I did maintain the SCons build continuosly
 * remove unused method from Buildhelper

Furthermore, the documentation page for our build system
https://lumiera.org/documentation/technical/build/SCons.html
has been reworked, to add a synopsis, some further background
information about the internal structure of SCons and about
the specific conventions and definitions used for Lumiera
 2025-11-27 18:21:22 +01:00
Ichthyostega
88ae398e67 Build: remove old workaround for transitive shared object lookup (closes: #965) 
Lumiera is built such that it can be invoked from a ''bundle directory''
without the need to install it into the system; this requires to perform
a relative lookup of shared modules loaded as dependencies.

Since Lumiera has a layered architecture, and each layer is built into a shared object,
we get transitive dependencies and thus transitive relative lookup.

There was a bug in binutils 2.23, which caused that transitive relative lookup to fail.

 * as of 2025, Debian/Trixie is defined as ''Reference Platform''
 * in Trixie the binutils version is v2.44-3
 * after removing the workaround, Lumiera and all tests can be launched
 * thus ''considering this workaround as obsolete now''
 2025-11-24 23:12:39 +01:00
Ichthyostega
3812c801fb Build: ensure that installed shared libs are not executable 
This is a Debian policy, which collides with the default behaviour
of GCC rsp. the plattform linker. The latter creates all ELF files as
executable, possibly because some platforms require that, and also
because some libraries provide a main() function for diagnostics.

The argument by the Debian people is that most libraries don't provide
such a main() and that this is an esoteric feature which should not be
supported by default.

We can fix that in our SCons build, since we use a specialised Builder
to also define the install targets systematically; it suffices to add
a post-action to these install targets for shared objects.

Note: currently Debian/Trixie provides SCons 4.8, but v4.10 will provide
a shorthand notation with the env.Chmod Action factory.
 2025-11-24 22:03:11 +01:00
Ichthyostega
ceceaf4ece Release: compile authorship information 
Some recherche regarding the requirements and conditions of the GPL
made it clear that we are obliged to have at least an summary statement
of all authors and the years of their contributions embedded somewhere
in the source itself. The Git history alone is not sufficient to fulfil
this requirement, since a code base could be packaged as Tarball
and passed-on outside of any Git repository.

Thus I propose the following policy
- add yourself to the copyright header whenever you made
  some ''significant'' contribution to a code file
- maintain a list of relevant authors at top-level,
  indicating a time range of their contribution
- use the same information also in the debian/copyright (DEB package)
- clarify in the LICENSE that authorship can be extracted from Git

__Remark__: Anton Yakovlev made a single code contribution in 2009 (87e528bd),
which was never used anywhere and removed as part of a general clean-up in 2023.
Thus I do not list him as a code author, but he is mentioned in credits.txt
 2025-11-24 00:52:47 +01:00
Ichthyostega
524dc61771 Release: check and update licensing information 
- use a current copy of the GPL2 text, downloaded from fsf.org
- reformat the AUTHORS and get rid of the table formatting
- Stackoverflow has upgraded its Subscriber Content license to CC-By-SA 4.0
 2025-11-26 00:57:25 +01:00
Ichthyostega
8601202be5 Release: rework and update the changelog 
A handwritten changelog is considered important and
helps to single out the overall relevant achievements.
Following a proposal from the Debian policy, this summary
of development steps will now be maintained in the NEWS file.

It will be marked with the version number of Lumiera.
 2025-11-22 23:51:21 +01:00
Ichthyostega
6c3f0edf10 Release: update README 
...and split-out the description of preview-releases,
since that rather belongs into some kind of changelog (NEWS).

Furthermore, check the links to the build dependencies
 2025-11-22 01:40:43 +01:00
Ichthyostega
4d373c929e Release: check legal statements / Authors 
See corresponding commit in the website repository.
- Verified all authors via Git
- simplify the list and group by core/contributors
- list only significant contributors here

__Note__: the page "project/contributors" on the website
contains a much more extensive list with all helpers,
casual contributors and concept discussion participants
 2025-11-21 18:36:27 +01:00
Ichthyostega
b3d8abcb2c Build: provide and install a lumiera.desktop file 
The XDG Desktop spec is accepted universally, and thus
the old Debian-specific 'menu' system is deprecated and
no longer engaged automatically.

See: https://lists.debian.org/debian-devel-announce/2015/09/msg00000.html

Thus we'll now provide a Desktop file and install that already from out
SCons build system, together with a suitable variation of the Lumiera icon.

TODO: not sure if everything was done the correct way
 * do we need to ''register'' the new file in some way (preinst script?)
 * the menu entry shows up, but not the icon
 * but if we put an absolute path for the lumiera.svg into the desktop file, it shows up

Remark: in later experiments with package building,
the menu entry and the icon showed up in the menu.
Not sure if this requires a reboot or some similar
trigger (like restart of the destkop)
 2025-11-21 01:12:49 +01:00
Ichthyostega
5a5168b145 Build: fix problem that prevented installation into absolute path 
...funny enough I never noticed this obvious mistake,
since I never install software directly into my system,
while the DEB-build does not use absolute paths...

Solution:
 * SCons has this speical convention that a path prefixed with '#'
   is resolved relative to the root of the build (where the SConstruct resides)
 * now we apply this automatically to the two relevant settings
   ** INSTALLDIR
   ** TARGDIR
 * but only (conditionally) if the configured path is relative, not absolute

As a consequence, most other hard-coded usages of the '#'-prefix can then be dropped
 2025-11-19 22:40:08 +01:00
Ichthyostega
5c8e88e59e Build: provide a placeholder page for the (planned) User-Manual 
Debian-Docbase allows to register some HTML documentation;
My old package definition added placeholder config, which renders
the documentation configuration invalid (as pointed out by Lintian).
However, I still think it is a good idea to have the anchor point
already defined, and thus I came up with the idea of in fact
providing some usable placeholder content...

As it turns out, we also have a placeholder page at the Lumiera website,
where the User Manual is assumed to be located later — so why not extend
this one and then provide the HTML-rendering for the DEB package?

To allow for this setup
 * I have now extended the placeholder page for the Website
   to include some generic description about Lumiera (from the 'about' page)
 * Furthermore, I added the screenshot (from the »Outer Space« page)
 * and I use this a an opportunity to document the various test / demo
   facilities currently available in the GUI, since these are rather obscure.
   While only intended for the developer, it seems still worthwhile
   to describe the possible effects — it may well be that we retain
   some of that test/demo functionality and in that case, we have
   now already some starting point for a documentation

 * Then, to include that page as stand-alone HTML, I used the 'Print Edit WE'-plugin
   from Firefox, to encode the images as inline-base64 URLs (which are restored
   by a tiny JavaScript embedded into that page)

 * and last but not least, our SCons buildsystem needs the ability
   to install such a documentation file, since it seems most adequate
   to handle this requirement as part of the generic installation (and
   not hidden in some Debian scripting)
 2025-11-18 23:09:54 +01:00
Ichthyostega
c8196ce234 Build: configuring via environment is bad practice 
Yes, I know...
Programmers absolutely LOVE to sneak-in various nifty toggles via environment.

Yet this is an anti-pattern!
And, by extension of that verdict, a "build interface" which relies
on the implicit convention that some magical variables are set,
is **not a proper interface** but a hack.

Thus we abandon that bad practice and handle the build in a clean and explicit way.

 * the DEB-Build in `debian/rules` now invokes SCons explicitly, passing arguments
 * the Lumiera Build-System is FSH aware and knows the proper installation locations
 * the setup of the application uses a setup configuration, shipped with the package
 * there is no need to ''compile-in any configuration''
   ** `LUMIERA_PLUGIN_PATH` is obsolete and unused since several years now
   ** `LUMIERA_CONFIG_PATH` was never used at all
   ** consequently, we also do not need `PKGLIBDIR` and `PKGDATADIR`
 2025-11-16 02:09:24 +01:00
Ichthyostega
741b8fe573 Build: document and disentangle dependencies 
A long-standing unnecessary mutual dependency caused rebuild
of most tests in the standard target, because the ''valgrind suppression''
executable was classified as »tool«, while also depending on the libraies
with the test code.
 2025-11-16 03:42:50 +01:00
Ichthyostega
75ffb060c7 Bugfix: Buildsystem -- no need to check for installdir 
The option handling did check if the installdir exists;
this is problematic since it is often created later,
automatically from the installation...
 2025-11-16 01:55:28 +01:00
Ichthyostega
aac9ee2934 Bugfix: uninitialised stack-memory used in test 
...this bug was spotted as the test failed reproducibly
when built with `-fstack-protector-strong` — which adds
additional "canary" markers to some kinds of problematic
stack storage; this seemed to have the effect that now
the second test uses exactly the same location as the
preceding test, and thus finds valid data in the newly
created work buffers.

There is no reason for using uninitialised storage in this
test (I can recall that I wanted to build a generic helper
and intended to use that as ''virtual overlay'' over existing
memory — but that usage never took place, and the `struct Buffer`
is not a general-purpose tool now, but only made for this
specific test. Thus memory can be easily zero-initialised.
 2025-11-15 02:00:11 +01:00
Ichthyostega
a34b1f6ddd Bugfix: setVersion.py -- ability to handle suffixes 
Turns out that in practice there will be (at least temporarily)
some version-tags including a suffix: the RC-versions!

Now there is the special twist, that Git does not allow '~' in Tag names,
and thus `git-buildpackage` introduced an additional layer of translation.
So we are forced to revert that translation, which is possible,
since the basic Debian version syntax disallows '_' in version numbers
(because '_' is used to separate the package name from the version number).

It seems prudent to implement that as an preprocessing step
and thus keep it out of the regular version number syntax.

Furthermore we need the ability to handle existing suffixes,
which (as we know now) can be picked up from the Git history.
 * my decision is to allow both pass-through and suppressing them
 * use `--suffix=False` to suppress / remove any existing suffix
 * the latter now allows us also to automate the setting of
   the final Release version
 2025-11-13 22:06:06 +01:00
Ichthyostega
2ca07bfe6b Bugfix-failed: attempt to fix XVideo widget drawing problems 
Based on the additional insight gained through the FrOSCon talk,
an attempt was made to investigate and fix the garbled display of the
docking panel header directly above our VideoDisplayWidget.

However, that turned out to be a problem with insufficeint support
of the XVideo standard with my (very old, 2011) NVidia graphic card.
Indeed, the hardware+software stack needs to support this Auto-Keying
extension of XVideo, so that the video display can be integrated
seamlessly into the rest of the UI. In my case, the driver seemingly
just fills the complete XWindow with the key-marker and thus the
decorations of the docking panel, which happens to use the same XWindow,
will just not be flushed to the display.

This unsuccessful research indicates that upholding support for XVideo
could become problematic...
 2025-11-20 21:36:47 +01:00
Ichthyostega
11efb6e9de Git-flow: Illustrations 
Vectorgraphic drawings to show the Git-flow branching scheme
explained in the accompanying text
 2025-11-10 19:20:15 +01:00
Ichthyostega
1c234d5a0b clean-up: some Doxygen improvements 
- reorganise the navigation tab structure
- place all further index lists into a common "Index" tab
- include a list of concepts
- remove the various "member" sub-tabs, these are not helpful
- the "modules" tab is now called "topics" (since C++ has now Modules!)
- generally re-sync DoxygenLayout.xml with a current pristine template
- comb though the Doxygen Warnings and fix a lot of small problems
 2025-11-05 02:55:45 +01:00
Ichthyostega
19497f8a7b clean-up: update content of the introductory overview pages 
The »Outer Space« and »Inner Core« documents present a comprehensive
overview of the vision, architecture and essential parts of the implementation.

In the light of changes to policy, design and implementation approaches,
some updates were necessary to align these crucial texts with the current
state of planning and implementation. Notably I have added a recent Screenshot
of the UI, showing a nested track structure pushed up by Diff from the core.

Over the last weeks, I conducted an extended analysis of the inception time
of the Lumiera project, which gave me a sharpened understanding of the goals,
going forward. I have also written an in-depth essay "Complexity and Flexibility".
See the corresponding commits in the Website repository.
 2025-10-28 02:23:42 +01:00
Ichthyostega
051cb31e28 clean-up: re-classify essential RfCs 
The RfC documents were written to complement discussions of the Lumiera developers;
yet since the time where ''Ichthyo'' is working basically alone on the project,
this kind of discussions have ceased. During the following years, some ideas
promoted by the existing RfC documents became rather detached from the
actual state of development in the code base.

Many of the existing RfC documents require some commentary to place them
into context, and some of the decisions taken in the early stage of the
project should be **re-assessed**. This includes the decision to reject
some proposals, which initially might have seemed desirable, yet could not
be reconciled with the understanding of the matter and topic in question,
as was gained through the ongoing analysis and development.
 2025-10-08 00:48:13 +02:00
Ichthyostega
c7528bbe8a clean-up: some RfCs became effectively final 
The purpose of RfCs is to channel and document discussions
among a group of developers regarding questions of design.
While there is unfortunately no longer a group of developers
discussing matters and working together on the code base,
some questions can be considered more or less settled,
by being implemented and validated.

- the Scheduler
- structure of the Developer Documentation
- Application installation as relocatable bundle
 2025-09-21 05:40:15 +02:00
Ichthyostega
67695c97b8 clean-up: drop superseded or obsoleted RfCs 
See added comments for the reason
 2025-09-21 05:40:15 +02:00
Ichthyostega
b556d2b770 clean-up: comb through the historical pages to fix markup errors 
Some sections of the Lumiera website document meeting minutes,
discussion protocols and design proposals from the early days
of the project; these pages were initially authored in the
»Moin Moin Wiki« operated by Cehteh on pipapo.org at that time;
this wiki backed the first publications of the »Cinelerra-3«
initiative, which turned into the Lumiera project eventually.

Some years later, those pages were transliterated into Asciidoc
semi-automatically, resulting in a lot of broken markup and links.
This is a long standing maintenance problem problem plaguing the
Lumiera website, since those breakages cause a lot of warnings
and flood the logs of any linkchecker run.
 2025-09-21 05:40:15 +02:00
Ichthyostega
ab2a363653 clean-up: remove the GCH builder from the SCons tools 
`BuilderGCH` was added as an experimental feature many years ago;
this is code found ''somewhere'' on the net and was use ''as-is'' —
however, precompiled headers turned out as a feature of GCC with
a lot of quality problems and, furthermore seems of questionable
usability — we thus decided to adhere strictly to the »Borland model«
of template instantiation and recommend against using precompiled headers.

Rather, in the Lumiera code base, much care is taken to avoid unnecessary
header includes — this, together with the incremental build feature of SCons
largely obsoletes the necessity to resort to precompiled headers and
similar facilities (as CCache).
 2025-09-19 19:51:28 +02:00
Ichthyostega
8dc6580da1 clean-up: update links embedded into API-doc (Doxygen) 
Notably some links on the **Gnome documentation** pages are problematic,
since there was seemingly an infrastructure change -- which unfortunately
leads to loosing several deep-links into the GTK-3 related documentation
and tutorials.

While the differences to GTK-4 are often rather minimal, I would still prefer
to link to those documentation pages used as reference at implementation time
of our related library and GUI functionality.

In several cases I have thus looked up the old URLs at Archive.org
 2025-09-19 19:51:28 +02:00
Ichthyostega
0c3cd9027c DOC: clarify UI / discussion 
- indicate clearly that a ''past discussion'' is documented here
- point out what is the primary focus for UI design ''currently''
- arrange some links better
- use cross-links / Linkfarm; especially cross-link to
  the discussion regarding Wouter's Workflow proposals (2025)
 2025-09-19 19:51:28 +02:00
Ichthyostega
217ec447c0 DOC: reorganise time handling pages (use Linkfarm) 
Create a new subcategory "design/architecture/time"
and rearrange several pages related to time handling and time codes.

NOTE: starting with this changeset, a ''Link-Farm'' is required for cross-links;
since we don't have an automatic solution for this task yet, I have created
the necessary forwarding pages manually in the website repository.
 2025-09-19 19:34:27 +02:00
Ichthyostega
25eb6a61e3 clean-up: link maintenance 
- use HTTPS
- avoid redirects
- supply Archive.org snapshots for old resources
 2025-09-19 19:34:27 +02:00
Ichthyostega
643779c4a2 Review: integrate Christian's improvements to the website build 
Christian started a series of reworks in 2018;
the result was considered experimental and was parked on website-staging ever since.

As part of the current release- and clean-up activities I now reviewed
and integrated those changes into the current website as far as applicable.
 2025-09-02 02:20:39 +02:00
Christian Thäter
060cbae2cd DOC: Server and Mailinglists 2025-09-02 02:03:24 +02:00
259 changed files with 19542 additions and 4439 deletions
Show stats Expand all files Collapse all files

84
AUTHORS
View file

@ -1,60 +1,39 @@
Lumiera Authors and Credits
===========================
Version: 0.pre.03
:Date: 11/2015
:Date: 11/2025
|==========================================
|*Architecture and Design*|
|graphical
user interface | JOEL HOLDSWORTH
| | HERMANN VOSSELER
| | BRIAN RYTEL
|processing layer | HERMANN VOSSELER
|backend | CHRISTIAN THÄTER
Architecture::
- Hermann Voßeler
- Christian Thäter
- Joel Holdsworth
| |
| |
|*Workflow design* |
|concept | BRIAN RYTEL
| | MIKE PROVOST
| | NIKOLA DUPER
| | CHRISTOPH VARGA
Workflow Concept::
- Hermann Voßeler
- Wouter Verwijlen
- Christoph Varga
- Brian Rytel
- Clay Barnes
| |
| |
|*Programming*|
|session and engine| HERMANN VOSSELER
|backend | CHRISTIAN THÄTER
| | MICHAEL PLOUJNIKOV
|graphical
user interface| JOEL HOLDSWORTH
| | STEFAN KANGAS
| | MICHAEL FISHER
|library | HERMANN VOSSELER
| | CHRISTIAN THÄTER
| | ANTON YAKOVLEV
| | STEFAN KANGAS
|testsuite | CHRISTIAN THÄTER
| | NICHOLAS SINNOTT-ARMSTRONG
| | HERMANN VOSSELER
| |
| |
|*Programming Documentation*|
| | CHRISTIAN THÄTER
| | HERMANN VOSSELER
| | MICHAEL PLOUJNIKOV
| | ODIN HØRTHE OMDAL
| | SIMEON VÖLKEL
| | MANO STIENEN
| | HENDRIK BOOM
| | BENNY LYONS
| |
| |
|*Server Administration*|
| | CHRISTIAN THÄTER
|==========================================
Core Developers::
- 2007-2025 Hermann Voßeler
- 2008-2009 Joel Holdsworth
- 2007-2011 Christian Thäter
Programming::
- 2007-2010 Michael Ploujnikov
- 2010-2011 Stefan Kangas
- 2010-2012 Michael Fisher
- 2007-2008 Simeon Völkel
Documentation::
- Hermann Vosseler
- Christian Thäter
- Odin Hørthe Omdal
- Simeon Völkel
- Mano Stienen
- Hendrik Boom
- Benny Lyons
@ -76,7 +55,10 @@ The Lumiera project feels especially obliged to::
Further Credits
---------------
- inspirations and some UI components were taken from http://Ardour.org[Ardour]
- inspirations and some UI components were taken from https://ardour.org/[Ardour]
- https://github.com/x42/xjadeo[xjadeo] by Robin Gareus was very helpful
for learning how to output raw video from a desktop application
- Parts of the Implementation are heavily inspired by +
*The Loki Library* (c) 2001 by *Andrei Alexandrescu*

47
COPYING
View file

@ -1,12 +1,12 @@
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
<https://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
@ -15,7 +15,7 @@ software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.) You can apply it to
the GNU Lesser General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
@ -55,8 +55,8 @@ patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
@ -110,7 +110,7 @@ above, provided that you also meet all of these conditions:
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
@ -168,7 +168,7 @@ access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
@ -225,7 +225,7 @@ impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
@ -255,7 +255,7 @@ make exceptions for this. Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.
NO WARRANTY
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
@ -277,9 +277,9 @@ YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
@ -291,7 +291,7 @@ convey the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) 19yy <name of author>
Copyright (C) <year> <name of author>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@ -303,17 +303,15 @@ the "copyright" line and a pointer to where the full notice is found.
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
You should have received a copy of the GNU General Public License along
with this program; if not, see <https://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
@ -330,11 +328,12 @@ necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
<signature of Moe Ghoul>, 1 April 1989
Moe Ghoul, President of Vice
This General Public License does not permit incorporating your program into
proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do, use the GNU Library General
library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License.

1
INSTALL
View file

@ -1 +0,0 @@
doc/user/tutorials/building.txt

60
LICENSE
View file

@ -1,24 +1,60 @@
- the *Lumiera* source code is (C) by the original authors (see `AUTHORS`)
Lumiera is Free Software
========================
:Date: 11/2025
This source tree or package is based on various contributions
and its use is permitted under the conditions of the *GNU General Public License*
- the *Lumiera* source code is copyrighted and licensed by the original authors
+
--
* (c) 2007-2025 Hermann Voßeler
* (c) 2007-2011 Christian Thäter
* (c) 2008-2009 Joel Holdsworth
--
+
-----------------------------------------------------------------------------
Lumiera is free software -- you may use and redistribute it under the
Terms and conditions of the GNU GENERAL PUBLIC LICENSE (GPL);
either version 2 of the License, or (at your option) any later version.
Lumiera is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License,
or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
For a copy of the GPL Version 2 see the file COPYING
-----------------------------------------------------------------------------
- Website, design documents and accompanying materials are covered by
the same license as the source code, +
in addition they are also dual-licensed under *CC-By-SA 3*
- The full source code can always be retrieved from
https://git.lumiera.org/?p=LUMIERA;a=summary[`git://git.lumiera.org/LUMIERA`]
* there are a lot of additional authors, which all hold copyright
on their respective contributions made under this license;
see the copyright statements of individual files
* furthermore, a full list of contributors can be retrieved
from the Git repository:
git log --format="\"%an <%ae>\",%ad" --date=short HEAD
* see also the file `AUTHORS`
- at various places, the implementation draws on solutions
and comments published at http://Stackoverflow.com[Stackoverflow] --
according to the http://stackexchange.com/legal[License Agreement] page,
any ``subscriber content'' on that site is provided under *CC-By-SA 3*..
- Website, design documents and accompanying materials are covered
by the same license as the source code (GPL2+), +
in addition they are also dual-licensed under *CC-By-SA 4*
- at various places, the implementation draws on solutions and comments
published at http://Stackoverflow.com[Stackoverflow] -- according to the
https://stackoverflow.com/legal/terms-of-service/public#licensing[License Agreement],
any ``subscriber content'' on that site is provided under *CC-By-SA 4*.
We attribute significant usages of solutions published this way
in the doxygen comments of the relevant source code entities.
@ -27,7 +63,7 @@ For a copy of the GPL Version 2 see the file COPYING
*The Loki Library* (C) 2001 by *Andrei Alexandrescu*
+
-----------------------------------------------------------------------------
Loki is governed by a MIT-License. See: http://loki-lib.sourceforge.net
Loki is governed by a MIT-License. See: https://sourceforge.net/projects/loki-lib/
Permission to use, copy, modify, distribute and sell this software for any
purpose is hereby granted without fee, provided that the above copyright
notice appear in all copies and that both that copyright notice and this

80
NEWS Normal file
View file

@ -0,0 +1,80 @@
Lumiera -- Significant Changes
==============================
Version: 0.pre.04~rc.1
:Date: 11/2025
*************************************************************
Lumiera is a non-linear video editing and compositing tool.
NOTE: as of 11/2025, Lumiera is in early development stage;
it is not usable yet. This is a preview Release of a
current development snapshot in pre-alpha stage.
Source code and a list of all contributors can be retrieved
from `git://git.lumiera.org/LUMIERA`
*************************************************************
In the current stage of development, the focus is primarily on the
overall integration of fundamental functionality at all levels of
the code base.
Lumiera pre-Alpha Versions
--------------------------
As of _11/2025_ (0.pre.04)::
This version is again motivated by a series of major upgrades and clean-up.
Compilation now requires C++23 and Debian/Trixie is considered the reference
platform. The GUI is connected to the core over an asynchronous messaging
bus and the timeline display has been reshaped to accommodate flexibly
nested structures of media content, instructed by the session through
a series of _diff messages_. A scheduler has been implemented to drive
the Render Engine, but the connection to the player and UI for output
is yet unfinished.
As of _11/2015_ (0.pre.03)::
A lot of long standing maintenance work has been done.
The Project upgraded to C++14 and Debian/Jessie as reference platform,
followed by clean-up of workarounds now obsoleted. On the GUI side, we largely
made the transition to GTK-3, which leads to a rework of our timeline widget,
which is in progress but not finished yet. This work also spurred an effort
to reorder the connection and communication between core and the UI, which
is expected to be asynchronous. Due to the limited developer resources,
work on the Engine and Player part is stalled.
As of _10/2013_ (0.pre.02)::
The data models have been elaborated and some significant parts of the session
are finished. Work has continued with time handling, a draft of the output
connection framework, a draft of the player subsystem and interfaces to the
engine and processing network. Unfortunately there was a considerable slowdown
and decrease in team size, yet still the code base is growing towards 90k LOC.
No tangible progress regarding the GUI and the backend.
As of _1/2011_ (0.pre.01)::
The project has created and documented a fairly consistent design,
and some parts implemented -- progressing from the technical foundations.
The code base is approaching 65k LOC. Roughly half of this is test code.
The Application can be installed and started to bring up a GTK GUI framework,
but the GUI is rather preliminary and not connected to core functionality.
The video processing pipeline exists only in the blueprints.
As of _2/2008_::
The project has been separated completely from Cinelerra, the parent project.
The Community, which at that time was largely identical to the Cinelerra-CV community,
choose the new project name **Lumiera** through a collaborative selection and vote.
The basic project infrastructure was established, and work on the new codebase
was underway. It is clear that no results other than a test suite can be shown
in the foreseeable future.
As of _7/2007_::
A group of volunteers has formed to address some longstanding issues and limitations
of **Cinelerra**, which we all used for video editing tasks requiring professional quality.
The plan was to restructure some central parts of the render engine: introduce a Builder
for render pipelines and use Placements to control arrangement of clips and a unified
Data-Backend to coordinate usage of system resources. These innovations would serve
as anchor, with the intention to propose the reworked codebase as a new version
of Cinelerra, in the hope of turning Cinelerra development into a more
participatory process going forward.

96
README
View file

@ -1,16 +1,14 @@
Lumiera -- the video NLE for Linux
====================================
==================================
Version: 0.pre.04~rc.1
:Date: 11/2015
:Date: 11/2025
*************************************************************
Lumiera is a non-linear video editing and compositing tool.
The Application will allow to edit footage using common
multimedia formats and audio/video stream codecs.
The Application will allow to edit footage in the common
multimedia formats (quicktime, ogg, mkv, avi) and audio/video
stream codecs (dv, mpeg1/2/4, h264 ...)
Lumiera features non-destructive editing, compositing tools,
Lumiera features nondestructive editing, compositing tools,
a selection of effects plugins, processing in RGB, YUV and
RGB-float colour models and the ability to mix media with
differing sizes and framerates. Lumiera is especially well
@ -19,12 +17,11 @@ with lots of material, several scenes, nested sequences,
colour grading, 3D support, full fledged sound montage
and multiple edit versions prepared in parallel.
NOTE: as of 11/2015, Lumiera is in early development stage;
NOTE: as of 11/2025, Lumiera is in early development stage;
it is not usable yet. The above describes the Lumiera project
vision, which will need years to implement. This preview Release
installs a current development snapshot in pre-alpha stage.
vision, the implementation of which will require many more years.
Visit http://Lumiera.org and join the mailing list
Visit https://Lumiera.org and join the mailing list
when interested in Lumiera planning and development.
****************************************************************
@ -32,48 +29,20 @@ when interested in Lumiera planning and development.
Lumiera pre-Alpha Versions
--------------------------
**This source tree doesn't yet contain a working video editing application** +
Rather, it contains the framework and technology core
of the envisioned Application ``Lumiera''.
.This source tree doesn't contain a working video editing application yet.
Rather, it contains the framework and technology core of the envisioned
Application »Lumiera«. What we attempt to build here is innovative,
and we must engage in a series of integration steps to search for
suitable pathways towards our envisaged architecture.
See http://issues.lumiera.org/roadmap[Project roadmap]
Since 2024, the integration of the Render Engine takes centre stage,
in an effort to establish a steady state realtime processing and
display pipeline, still relying on generated video data rather
than using a library to read and playback a video file.
As of _11/2015_ (0.pre.03)::
a lot of long standing maintennance work has been done. The Project switched
to C++11 and in the end even to C++14 and Debian/Jessie as reference platform,
followed by clean-up of now obsolete workarounds. On the GUI side, we largely
made the transition to GTK-3, which lead to rework of our timeline widget, not
finished yet. This work also spured an effort the connection and communication
between Proc and the UI, which is expected to be asynchroneous. Due to the
limited developer resources, work on the Engine and Player part is stalled.
- https://Lumiera.org/documentation/design/governance/integration.html[Integration steps]
- See also https://issues.lumiera.org/roadmap[Project roadmap]
As of _10/2013_ (0.pre.02)::
the data models have been elaborated and some significant parts of the session
are finished. Work has continued with time handling, a draft of the output
connection framework, a draft of the player subsystem and interfaces to the
engine and processing network. Unfortunately there was a considerable slowdown
and decrease in team size, yet still the code base is growing towards 90k LOC.
No tangible progress regarding the GUI and the backend.
As of _1/2011_ (0.pre.01)::
the project has created and documented a fairly consistent design,
partially coded up -- starting from the technical foundations and working up.
The code base is approaching 65k LOC. Roughly half of this is test code.
The Application can be installed and started to bring up a GTK GUI framework,
but the GUI is very preliminary and not connected to core functionality.
The video processing pipeline exists only in the blueprints.
As of _2/2008_::
the project has been separated completely from ``Cinelerra'', the parent project.
The Community, which at that time was largely identical to the Cinelerra-CV community,
choose the new project name ``Lumiera'' through a collaborative selection and vote.
The basic project infrastructure is up and running, and work on the new codebase
has started. We can show nothing beyond a test suite for some time to come.
As of _7/2007_::
we started with the backend and render engine draft, some example code
complemented by several unit tests. There is a TiddlyWiki with detailed
design considerations and developer documentation and a UML model
@ -82,19 +51,24 @@ Build Requirements
For building Lumiera, you'll need:
* C99 / C++14 compiler GCC `>=4.9` or Clang `>=3.5`
* C++23 compiler GCC >=14 (Clang fails atm)
* Git Version management system
* http://www.scons.org/[SCons build system]
* http://www.boost.org/[Boost libraries]
* http://gmerlin.sourceforge.net/[GAVL library]
* http://nobug.pipapo.org/[NoBug library]
* http://www.gtkmm.org/en/[GTKmm]
* http://alsa-project.org[ALSA libasound2-dev]
* http://cgit.freedesktop.org/xorg/lib/libXv[libXv]
* https://wiki.gnome.org/LibRsvg[lib rSVG]
* https://git.gnome.org/browse/gdl[lib GDL]
* https://www.scons.org/[SCons build system]
* https://www.boost.org/[Boost libraries]
* https://github.com/bplaum/gavl[GAVL library]
* https://www.alsa-project.org/[ALSA (libasound2-dev)]
* https://nobug.pipapo.org/[NoBug library]
* https://gtkmm.gnome.org/en/[gtkmm]
* https://cgit.freedesktop.org/xorg/lib/libXv[libXv]
* https://wiki.gnome.org/Projects/LibRsvg[lib rSVG]
* https://git.lumiera.org/?p=debian/gdl;a=summary[lib GDL]
* https://git.lumiera.org/?p=debian/gdlmm;a=summary[GDL-mm bindings]
See the online documentation at http://Lumiera.org/download.html
Further information:
* Online documentation at https://Lumiera.org/download.html[Build and install].
* Documentation is also available in-tree in 'doc/user/tutorials/building.txt'
* Source code can be retrieved with `git clone git://git.lumiera.org/LUMIERA`

7
SConstruct
View file

@ -4,7 +4,7 @@
##
# Copyright (C)
# 2008, Hermann Vosseler <Ichthyostega@web.de>
# 2008-2025 Hermann Vosseler <Ichthyostega@web.de>
#
# **Lumiera** is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the
@ -16,7 +16,7 @@
# NOTE: scons -h for help.
# This script /defines/ the components and how they fit together.
# SCons will derive dependencies and the necessary build steps.
# Read more about the SCons build system at: http://www.scons.org
# Read more about the SCons build system at: https://www.scons.org
# NOTE: Lumiera SCons extension modules and plugins
@ -52,7 +52,6 @@ SConscript(dirs=['data','src','src/tool','research','tests','doc'], exports='env
# additional files to be cleaned when cleaning 'build'
env.Clean ('build', [ 'scache.conf', '.sconf_temp', '.sconsign.dblite', 'config.log' ])
env.Clean ('build', [ 'src/pre.gch' ])
@ -63,8 +62,8 @@ env.Clean ('build', [ 'src/pre.gch' ])
Import('lumiera plugins tools gui testsuite')
build = env.Alias('build', lumiera + plugins + tools + gui)
# this defines the SCons **default target**
env.Default('build')
# SCons default target
#env.Alias ('all', build + testsuite + doxydoc)

50
admin/buildVersion.py
View file

@ -47,7 +47,7 @@ def parseAndBuild():
,choices=['maj','min','rev'], const='rev'
,help='bump the version detected from Git (optionally bump a specific component)')
parser.add_argument ('--suffix','-s'
,help='append (or replace) a suffix (by default attached with ~)')
,help='append (or replace) a suffix (attached with ~); False -> remove suffix')
parser.add_argument ('--snapshot'
,action='store_true'
,help='mark as development snapshot by appending ~dev.YYYYMMDDhhmm, using UTC date from HEAD commit')
@ -72,11 +72,30 @@ def getTimestampFromGit():
def rebuild (version, bump=None, suffix=None, snapshot=False):
mat = re.fullmatch (VER_SYNTAX, version)
def parseVerNr (verStr):
""" parse a version spec from a git tag,
possibly preprocess to translate _ -> ~
"""
NOT_SFX = r'(?:[^_\W]|[\.\+])+'
DECODE = r'('+NOT_SFX+')(?:_('+NOT_SFX+'))?'
#
mat = re.fullmatch (DECODE, verStr)
if not mat:
__FAIL ('invalid version syntax in "'+version+'"')
__FAIL ('version string contains invalid characters: "'+verStr+'"')
verStr = mat.group(1)
if mat.group(2):
verStr += '~'+mat.group(2)
#
# check syntax of translated version spec
mat = re.fullmatch (VER_SYNTAX, verStr)
if not mat:
__FAIL ('invalid version syntax in "'+verStr+'"')
else:
return mat
def rebuild (version, bump=None, suffix=None, snapshot=False):
mat = parseVerNr (version)
maj = mat.group(1)
min = mat.group(2)
rev = mat.group(3)
@ -97,7 +116,10 @@ def rebuild (version, bump=None, suffix=None, snapshot=False):
if snapshot:
suf = 'dev.'+getTimestampFromGit()
elif suffix:
suf = suffix
if not evalBool(suffix):
suf = None
else:
suf = suffix
version = maj
if min:
@ -128,10 +150,26 @@ def runGit (argStr):
proc = subprocess.run (argList, check=True, capture_output=True, encoding='utf-8', env={'LC_ALL':'C'})
return proc.stdout.rstrip() # Note: sanitised env
except:
__FAIL ('invoking git-describe')
__FAIL ('invoking git '+argStr)
def evalBool (val) ->bool:
""" evaluate as bool value
@author: Tim Poulsen
@note: Adapted from the original, published 2023, CC-By-SA-4
https://www.timpoulsen.com/2023/python-bool-from-any.html
"""
try:
return float(val) > 0
except:
if type(val) is str:
return val.lower() not in ['false', 'no', 'n', 'none', 'null']
else:
# rely on Python's type coercion rules
return bool(val)
def __ERR (*args, **kwargs):
print (*args, file=sys.stderr, **kwargs)

61
admin/build_lumiera-build-dependencies.sh
View file

@ -1,61 +0,0 @@
#!/bin/sh
#
# build_lumiera-build-dependencies.sh - prepare/build on a pristine Debian/Ubuntu system (Docker)
#
#
#------------------------------------------------------Setup
# The Debian DEB Depot to retrieve the source packages
DEBIAN_REPO="http://lumiera.org/debian/"
SRC_DISTRO="stretch"
REPO_SECTION="experimental"
#
# GPG pubkey to trust for signed packages
TRUSTED_GPG=$(dirname $0)/deb.lumiera.org.PUB.gpg
#
# Directory for building DEB packages
PACK_DIR=./pack
#
#------------------------------------------------------Setup(End)
#
fail() {
echo "\nFAIL: $1\n\n"
exit 1
}
# Sanity-Checks
[ -f $TRUSTED_GPG ] || fail "GPG Key not found: $TRUSTED_GPG"
mkdir -p $PACK_DIR
[ -w $PACK_DIR ] || fail "Unable to build. Can not write to $PACK_DIR"
# prepare the host system with Lumiera package sources
cp $TRUSTED_GPG /etc/apt/trusted.gpg.d/
chmod a+r-x /etc/apt/trusted.gpg.d/$(basename $TRUSTED_GPG)
echo "deb-src $DEBIAN_REPO $SRC_DISTRO $REPO_SECTION" > /etc/apt/sources.list.d/55-lumiera.list
apt update
apt install -y build-essential ca-certificates
apt update
# build some special build dependencies from source
WORKDIR=$(pwd -P)
cd $PACK_DIR
echo "\n\n======= building NoBug =======\n"
apt-get -y build-dep nobug
apt-get source --compile nobug
dpkg -i nobug-dev*deb libnobug*deb || fail "installing NoBug"
echo "\n\n======= building GDLmm =======\n"
apt-get -y build-dep libgdlmm-3-dev
apt-get source --compile libgdlmm-3-dev || fail "installing GDLmm"
dpkg -i libgdlmm-3*deb
# install the build dependencies of Lumiera from DEB
echo "\n\nInstalling Lumiera build dependencies...\n"
apt-get -y build-dep lumiera
# return to the working directory
cd $WORKDIR
echo "Build-Dependencies of Lumiera successfully installed.\n\n"

BIN
admin/deb.lumiera.org.PUB.gpg
View file

Binary file not shown.

44
admin/docker_open-lumiera-buildenv.sh
View file

@ -1,44 +0,0 @@
#!/bin/sh
#
# docker_open-lumiera-buildenv.sh - launch Docker container with interactive build shell
#
#
#------------------------------------------------------Setup
#
# Working directory path on the host
WORKDIR_HOST="/home/$USER/devel/lumi"
#
# bind-mount of the working dir in the container
WORKDIR_GUEST="/lumi"
#
# Docker image-ID to launch
DOCKER_IMAGE="ubuntu:bionic"
#
# Script code to inject into interactive shell
COMMANDS=$(cat) <<RUN_IN_CONTAINER
. /etc/bash.bashrc
. ~/.bashrc
alias la='ls -latr'
$WORKDIR_GUEST/admin/build_lumiera-build-dependencies.sh
RUN_IN_CONTAINER
#
#------------------------------------------------------Setup(End)
#
# Launch...
# (1) launch the docker container
# (2) start a bash there to process a bash commandline
# (3) this commandline in turn launches an interactive bash
# (4) and this interactive bash gets a startup-Shellscript to perform
# (5) and this shellscript is read from an temporary named pipe to another shellscript
# (6) which in turn prints the script code from the setup-variable $COMMANDS
#
# bash magic thanks to Jonathan Potter; see https://serverfault.com/a/586272
#
#
docker run -v $WORKDIR_HOST:$WORKDIR_GUEST -it $DOCKER_IMAGE bash -c "bash --rcfile <(echo \"${COMMANDS}\" )"

5
admin/gnu-indent.sh
View file

@ -1,5 +0,0 @@
#!/bin/sh
#
# gnu-indent -- call the "indent" tool with parameters suitable for GNU coding style
#
indent -nbad -bap -nbc -bbo -bl -bli2 -bls -ncdb -nce -cp1 -cs -di2 -ndj -nfc1 -nfca -hnl -i2 -ip5 -lp -pcs -psl -nsc -nsob $@

109
admin/scons/BuilderGCH.py
View file

@ -1,109 +0,0 @@
# coding: utf-8
##
## BuilderGCH.py - SCons builder for gcc's precompiled headers
##
# Copyright (C) scons.org/wiki/GchBuilder
# 2006, Tim Blechmann
# 2008, Hermann Vosseler <Ichthyostega@web.de>
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2 of
# the License, or (at your option) any later version.
#####################################################################
# history: 8/2008 adapted for Lumiera build system
# changed to accept a list of precompiled header defs
# TODO: WIP-remove these comments when port to Python 3.x is DONE
# types.py does not contain ListType in Python 3.x
# # Why do we require ListType?
# To do something like
# if type(item) is ListType:
# ....
# But types.py does not have ListType anymore
# if isinstance(item, list):
#from types import ListType
import SCons.Action
import SCons.Builder
import SCons.Scanner.C
import SCons.Util
import SCons.Script
SCons.Script.EnsureSConsVersion(0,96,92)
GchAction = SCons.Action.Action('$GCHCOM', '$GCHCOMSTR')
GchShAction = SCons.Action.Action('$GCHSHCOM', '$GCHSHCOMSTR')
def gen_suffix(env, sources):
return sources[0].get_suffix() + env['GCHSUFFIX']
GchShBuilder = SCons.Builder.Builder(action = GchShAction,
source_scanner = SCons.Scanner.C.CScanner(),
suffix = gen_suffix)
GchBuilder = SCons.Builder.Builder(action = GchAction,
source_scanner = SCons.Scanner.C.CScanner(),
suffix = gen_suffix)
def setup_dependency(target,source,env, key):
scanner = SCons.Scanner.C.CScanner()
path = scanner.path(env)
deps = scanner(source[0], env, path)
if key in env and env[key]:
for header in env[key]:
header_path = header.path.strip('.gch')
if header_path in [x.path for x in deps]:
print("Precompiled header(%s) %s \t <--- %s" % (key,header_path,source[0]))
env.Depends(target, header)
def static_pch_emitter(target,source,env):
SCons.Defaults.StaticObjectEmitter( target, source, env )
setup_dependency(target,source,env, key='GCH')
return (target, source)
def shared_pch_emitter(target,source,env):
SCons.Defaults.SharedObjectEmitter( target, source, env )
setup_dependency(target,source,env, key='GCH-sh')
return (target, source)
def generate(env):
""" Add builders and construction variables for the Gch builder.
"""
env.Append(BUILDERS = {
'gch': env.Builder(
action = GchAction,
target_factory = env.fs.File,
),
'gchsh': env.Builder(
action = GchShAction,
target_factory = env.fs.File,
),
})
try:
bld = env['BUILDERS']['GCH']
bldsh = env['BUILDERS']['GCH-sh']
except KeyError:
bld = GchBuilder
bldsh = GchShBuilder
env['BUILDERS']['PrecompiledHeader'] = bld
env['BUILDERS']['PrecompiledHeaderShared'] = bldsh
env['GCHCOM'] = '$CXX -o $TARGET -x c++-header -c $CXXFLAGS $_CCCOMCOM $SOURCE'
env['GCHSHCOM'] = '$CXX -o $TARGET -x c++-header -c $SHCXXFLAGS $_CCCOMCOM $SOURCE'
env['GCHSUFFIX'] = '.gch'
for suffix in SCons.Util.Split('.c .C .cc .cxx .cpp .c++'):
env['BUILDERS']['StaticObject'].add_emitter( suffix, static_pch_emitter )
env['BUILDERS']['SharedObject'].add_emitter( suffix, shared_pch_emitter )
def exists(env):
return env.Detect('g++')

17
admin/scons/Buildhelper.py
View file

@ -4,7 +4,7 @@
##
# Copyright (C)
# 2008, Hermann Vosseler <Ichthyostega@web.de>
# 2008-2025 Hermann Vosseler <Ichthyostega@web.de>
#
# **Lumiera** is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the
@ -104,19 +104,6 @@ def isSrcDir(path, patterns=SRCPATTERNS):
def filterNodes(nlist, removeName=None):
""" filter out scons build nodes using the given criteria.
removeName: if set, remove all nodes with this srcname
"""
if removeName:
predicate = lambda n : not fnmatch.fnmatch(os.path.basename(str(n[0])), removeName)
else:
predicate = lambda n : True
return list(filter(predicate, nlist))
def getDirname (d, basePrefix=None):
""" extract directory name without leading path,
or without the explicitly given basePrefix
@ -218,7 +205,7 @@ def extract_localPathDefs (localDefs):
pattern and returns them wrapped into a Record for convenient access
"""
def relevantPathDefs (mapping):
for (k,v) in list(mapping.items()):
for (k,v) in mapping.items():
if (k.startswith('src') or k.startswith('build') or k.startswith('install')) and Util.is_String(v):
v = v.strip()
if not v.endswith('/'): v += '/'

164
admin/scons/LumieraEnvironment.py
View file

@ -4,7 +4,7 @@
##
# Copyright (C)
# 2008, Hermann Vosseler <Ichthyostega@web.de>
# 2008-2025 Hermann Vosseler <Ichthyostega@web.de>
#
# **Lumiera** is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the
@ -16,7 +16,8 @@
from os import path
import SCons.SConf
from SCons.Action import Action
from SCons.Action import Action, FunctionAction
from SCons.Script import File as SConsFile
from SCons.Environment import Environment
from Buildhelper import *
@ -29,21 +30,36 @@ class LumieraEnvironment(Environment):
using global vars. Idea inspired by Ardour.
"""
def __init__(self, buildSetup, buildVars, **kw):
kw.update(VERSION = buildSetup.VERSION
,TARGDIR = buildSetup.TARGDIR
,DESTDIR = '$INSTALLDIR/$PREFIX'
,toolpath = [buildSetup.TOOLDIR ]
,variables = buildVars
)
Environment.__init__ (self, **kw)
self.path = Record (extract_localPathDefs(buildSetup)) # e.g. buildExe -> env.path.buildExe
Environment.__init__ (self, toolpath = [buildSetup.TOOLDIR ]
, variables = buildVars # ◁───── reads settings from the commandline (see Options.py)
, **kw)
#
self['TARGDIR'] = buildSetup.TARGDIR
self['VERSION'] = buildSetup.VERSION
self['DESTDIR'] = '$INSTALLDIR/$PREFIX'
self['SHARE' ] = '$DESTDIR/share'
self._anchor_relative('INSTALLDIR')
self._anchor_relative('TARGDIR')
#
self.path = Record (extract_localPathDefs(buildSetup)) # ◁───── e.g. buildExe -> env.path.buildExe
self.libInfo = {}
self.Tool("BuilderDoxygen")
self.Tool("ToolDistCC")
self.Tool("ToolCCache")
register_LumieraResourceBuilder(self)
register_LumieraIconBuilder(self)
register_LumieraResourceBuilders(self)
register_LumieraCustomBuilders(self)
def _anchor_relative(self, key):
""" ensure that a relative path spec becomes anchored at build-root
@note: a special convention within scons: '#' implies directory of SConstruct
"""
spec = self[key].strip()
if not (spec.startswith('/') or spec.startswith('#')):
spec = '#'+spec
self[key] = spec
def Configure (self, *args, **kw):
kw['env'] = self
@ -61,9 +77,9 @@ class LumieraEnvironment(Environment):
if other in self.libInfo:
self.mergeConf(self.libInfo[other])
else:
self.Append (LIBS = other.get ('LIBS',[]))
self.Append (LIBPATH = other.get ('LIBPATH', []))
self.Append (CPPPATH = other.get('CPPPATH', []))
self.Append (LIBS = other.get('LIBS',[]))
self.Append (LIBPATH = other.get('LIBPATH', []))
self.Append (CPPPATH = other.get('CPPPATH', []))
self.Append (LINKFLAGS = other.get('LINKFLAGS', []))
return self
@ -109,26 +125,55 @@ class LumieraConfigContext(ConfigBase):
###############################################################################
####### Lumiera custom tools and builders #####################################
def register_LumieraResourceBuilder(env):
""" Registers Custom Builders for generating and installing Icons.
def register_LumieraIconBuilder(env):
""" Registers a custom Builder for generating and installing Icons from SVG.
Additionally you need to build the tool (rsvg-convert.c)
used to generate png from the svg source using librsvg.
"""
import IconSvgRenderer as renderer # load Joel's python script for invoking the rsvg-convert (SVG render)
renderer.rsvgPath = env.subst("$TARGDIR/rsvg-convert")
renderer.rsvgPath = env.subst("$TARGDIR/rsvg-convert").removeprefix('#')
# # the prefix '#' is a SCons specific convention,
# # which the external tool can not handle
#
# MD5 signature for this specific python source code...
thisCodeSignature = SConsFile(__file__).get_csig() + SConsFile(renderer.__file__).get_csig()
thisCodeSignature = bytearray(thisCodeSignature, 'utf-8')
def invokeRenderer(target, source, env):
source = str(source[0])
targetdir = env.subst(env.path.buildIcon)
if targetdir.startswith('#'): targetdir = targetdir[1:]
renderer.main([source,targetdir])
return 0
class IconRenderAction(FunctionAction):
""" SCons Action subclass to provide a controlled cache signature.
@note: usually it would be sufficient to pass just a callable to the Builder,
however, our implementation calls into an external Python module and thus
the default signature from SCons would not be stable, since it relies
on a code representation including memory addresses. Without this,
the icons would be frequently rebuilt unnecessarily.
"""
def __init__(self):
FunctionAction.__init__(self, IconRenderAction.invokeRenderer
, {'cmdstr' : "rendering Icon: $SOURCE --> $TARGETS"}
)
def get_contents(self, target, source, env):
""" a stable signature based on the source code """
return thisCodeSignature
@staticmethod
def invokeRenderer(target, source, env):
""" render the SVG icon with libRSVG """
source = str(source[0])
targetdir = env.subst(env.path.buildIcon).removeprefix('#')
renderer.main([source,targetdir])
return 0
def createIconTargets(target,source,env):
""" parse the SVG to get the target file names """
source = str(source[0])
@ -146,6 +191,20 @@ def register_LumieraResourceBuilder(env):
return (generateTargets, source)
buildIcon = env.Builder( action = IconRenderAction()
, single_source = True
, emitter = createIconTargets
)
env.Append(BUILDERS = {'IconRender' : buildIcon})
def register_LumieraResourceBuilders(env):
""" Registers further Custom Methods for installing various Resources.
"""
def IconResource(env, source):
""" copy icon pixmap to corresponding icon dir. """
subdir = getDirname(str(source))
@ -155,7 +214,7 @@ def register_LumieraResourceBuilder(env):
return env.Install(toBuild, source)
def GuiResource(env, source):
""" pick up giben source resource and install
""" pick up given source resource and install
them (flat) into the configured target
"""
toBuild = env.path.buildUIRes
@ -165,9 +224,11 @@ def register_LumieraResourceBuilder(env):
def ConfigData(env, prefix, source, targetDir=None):
""" install (copy) configuration- and metadata.
target dir is either the install location configured (in SConstruct),
or an explicitly given absolute or relative path segment, which might refer
to the location of the executable through the $ORIGIN token
@param targetDir: when None, then use he install location configured (in Setup.py),
otherwise an explicitly given absolute or relative path segment,
which might refer to the location of the executable through the $ORIGIN token
@param prefix: a prefix relative to the current path (location of SConscript),
i.e. typically a subdirectory where to find the source config file
"""
source = path.join(prefix,str(source))
subdir = getDirname(source, prefix) # removes source location path prefix
@ -188,15 +249,31 @@ def register_LumieraResourceBuilder(env):
env.Install (toInstall, source)
return env.Install(toBuild, source)
def DocFile(env, prefix, source, target=None):
""" install (copy) files for documentation.
Always places the documentation below the standard location 'installDoc' configured in Setup.py
@param prefix: relative to current path (SConscript), will be stripped at destination
@param target: when given, the target will be named explicitly, or (when only a directory)
placed into a specific subdir, otherwise (when None) the source spec will be placed
into the corresponding subdir after stripping the prefix
"""
source = path.join(prefix,str(source))
subdir = getDirname(source, prefix) # removes source location path prefix
if not target:
target = subdir+'/'
elif target.endswith('/'):
target = target+subdir+'/'
toInstall = path.join(env.path.installDoc, target)
if toInstall.endswith('/'):
return env.Install(toInstall, source)
else:
return env.InstallAs(toInstall, source) # this renames at target
buildIcon = env.Builder( action = Action(invokeRenderer, "rendering Icon: $SOURCE --> $TARGETS")
, single_source = True
, emitter = createIconTargets
)
env.Append(BUILDERS = {'IconRender' : buildIcon})
env.AddMethod(IconResource)
env.AddMethod(GuiResource)
env.AddMethod(ConfigData)
env.AddMethod(DocFile)
@ -262,7 +339,6 @@ class LumieraExeBuilder(WrappedStandardExeBuilder):
"""
custEnv = lumiEnv.Clone()
custEnv.Append( LINKFLAGS = "-Wl,-rpath=\\$$ORIGIN/modules,--enable-new-dtags" )
custEnv.Append( LINKFLAGS = "-Wl,-rpath-link=target/modules" ) ### Workaround for bug in binutils > 2.23 /////TICKET #965
if 'addLibs' in kw:
custEnv.Append(LIBS = kw['addLibs'])
return custEnv
@ -282,7 +358,7 @@ class LumieraModuleBuilder(WrappedStandardExeBuilder):
Lumiera modules; modules are assumed to reside in a subdirectory below the executable.
"""
custEnv = lumiEnv.Clone()
custEnv.Append(LINKFLAGS = "-Wl,-soname="+self.defineSoname(target,**kw))
custEnv.Append( LINKFLAGS = "-Wl,-soname="+self.defineSoname(target,**kw))
custEnv.Append( LINKFLAGS = "-Wl,-rpath=\\$$ORIGIN/../modules,--enable-new-dtags" )
if 'addLibs' in kw:
custEnv.Append(LIBS = kw['addLibs'])
@ -292,6 +368,26 @@ class LumieraModuleBuilder(WrappedStandardExeBuilder):
def getInstallDestination(self, lumiEnv): return lumiEnv.path.installLib
def installTarget(self, env, buildTarget, **kw):
""" ensure a shared library is not marked executable.
The default toolchain on Linux often installs shared libraries as executable, which seems
to be necessary on some arcane Unix platforms. However, Debian Policy prohibits that.
See https://unix.stackexchange.com/questions/400187/why-should-or-should-not-shared-libraries-be-executable-e-g-red-hat-vs-debian
"""
toInstall = super().installTarget(env, buildTarget, **kw)
if toInstall:
def _Chmod(target, source, env):
""" Workaround since env.Chmod is present only in SCons 4.10 """
import os
for t in target:
os.chmod(str(t), 0o644)
return None
# removeExecBit = env.Chmod(toInstall, 0o644) # ◁◁◁ could use this for SCons > 4.10
msg = '....... clear exec perm %s' % [str(t) for t in toInstall]
removeExecBit = env.Action(_Chmod, msg)
env.AddPostAction(toInstall, removeExecBit)
return toInstall
def defineSoname (self, target, **kw):
""" internal helper to extract or guess
a suitable library SONAME, either using an

4
admin/scons/Options.py
View file

@ -42,9 +42,7 @@ def defineCmdlineVariables(buildVars):
# ,EnumVariable('DIST_TARGET', 'Build target architecture', 'auto',
# allowed_values=('auto', 'i386', 'i686', 'x86_64' ), ignorecase=2)
,PathVariable('PREFIX', 'Installation dir prefix', 'usr/local', PathVariable.PathAccept)
,PathVariable('INSTALLDIR', 'Root output directory for install. Final installation will happen in INSTALLDIR/PREFIX/... ', '/', PathVariable.PathIsDir)
,PathVariable('PKGLIBDIR', 'Installation dir for plugins, defaults to PREFIX/lib/lumiera/modules', '',PathVariable.PathAccept)
,PathVariable('PKGDATADIR', 'Installation dir for default config, usually PREFIX/share/lumiera', '',PathVariable.PathAccept)
,PathVariable('INSTALLDIR', 'Root output directory for install. Final installation will happen in INSTALLDIR/PREFIX/... ', '/', PathVariable.PathAccept)
)

48
admin/scons/Platform.py
View file

@ -4,7 +4,7 @@
##
# Copyright (C)
# 2012, Hermann Vosseler <Ichthyostega@web.de>
# 2012-2025 Hermann Vosseler <Ichthyostega@web.de>
#
# **Lumiera** is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the
@ -35,6 +35,23 @@ def configure(env):
if not conf.TryAction('pkg-config --version > $TARGET')[0]:
problems.append('We need pkg-config for including library configurations, exiting.')
# A special check in case we are compiling with GCC...
compiler = env.subst('$CXX')
verGCCmin = (14,) # note no trailing zero for version ordering check
expectedFeature = 'solid C++23 support'
if compiler.startswith("g++"):
# verify sufficient compiler version
try:
import subprocess
res = subprocess.check_output([compiler,'-dumpversion'], universal_newlines=True).strip()
res = tuple(int(x) for x in res.split('.'))
except Exception:
res = None
#
if res and res < verGCCmin:
problems.append('The compiler "%s" reports version %s, yet we need at least %s for %s.'
% (compiler, res, verGCCmin, expectedFeature))
if not conf.CheckLibWithHeader('m', 'math.h','C'):
problems.append('Did not find math.h / libm.')
@ -60,7 +77,7 @@ def configure(env):
print('Valgrind not found. The use of Valgrind is optional; building without.')
if not conf.CheckPkgConfig('nobugmt', 201008.1):
problems.append('Did not find NoBug [http://nobug.pipapo.org/].')
problems.append('Did not find NoBug [https://nobug.pipapo.org/].')
else:
conf.env.mergeConf('nobugmt')
@ -84,45 +101,45 @@ def configure(env):
problems.append('We need boost::program_options (including binary lib for linking).')
if not conf.CheckPkgConfig('gavl', '1.4'):
if not conf.CheckPkgConfig('gavl', '2.0'):
problems.append('Did not find Gmerlin Audio Video Lib [https://github.com/bplaum/gavl].')
else:
conf.env.mergeConf('gavl')
if not conf.CheckPkgConfig('alsa', '1.0.23'):
if not conf.CheckPkgConfig('alsa', '1.2'):
problems.append('Support for ALSA sound output is required')
if not conf.CheckPkgConfig('gtkmm-3.0', '3.10'):
if not conf.CheckPkgConfig('gtkmm-3.0', '3.20'):
problems.append('Unable to configure the mm-bindings for GTK-3')
if not conf.CheckPkgConfig('glibmm-2.4', '2.39'):
if not conf.CheckPkgConfig('glibmm-2.4', '2.66'):
problems.append('Unable to configure the mm-bindings for Glib')
if not conf.CheckPkgConfig('sigc++-2.0', '2.2.10'):
if not conf.CheckPkgConfig('sigc++-2.0', '2.12'):
problems.append('Need the signal-slot-binding library SigC++2')
if not conf.CheckPkgConfig('glib-2.0', '2.40'):
if not conf.CheckPkgConfig('glib-2.0', '2.80'):
problems.append('Need a suitable Glib version.')
if not conf.CheckPkgConfig('gthread-2.0', '2.40'):
if not conf.CheckPkgConfig('gthread-2.0', '2.80'):
problems.append('Need gthread support lib for Glib based thread handling.')
if not conf.CheckPkgConfig('cairomm-1.0', '1.10'):
if not conf.CheckPkgConfig('cairomm-1.0', '1.14'):
problems.append('Unable to configure Cairo--')
verGDL = '3.8' # lowered requirements to allow building on Ubuntu/Trusty & Mint (was originally '3.12')
verGDL = '3.40' # now orphaned and thus directly provided from Lumiera.org -> can require latest available
verGDLmm = '3.7.3'
urlGDLmm = 'http://ftp.gnome.org/pub/GNOME/sources/gdlmm/'
urlGDLmm = 'git://git.lumiera.org/debian/gdlmm'
urlGDLmmDEB = 'http://lumiera.org/debian/'
if not conf.CheckPkgConfig('gdl-3.0', verGDL):
problems.append('GNOME Docking Library not found. We need at least GDL %s '
'and suitable C++ ("mm")-bindings (GDLmm >=%s)' % (verGDL, verGDLmm))
if not conf.CheckPkgConfig('gdlmm-3.0', verGDLmm, alias='gdl'):
problems.append('We need the C++ bindings for GDL by Fabien Parent: GDLmm >=%s '
'(either from GNOME %s or use the debian package from %s)' %
'(either from %s or use the debian package from %s)' %
(verGDLmm, urlGDLmm, urlGDLmmDEB))
if not conf.CheckPkgConfig('librsvg-2.0', '2.30'):
if not conf.CheckPkgConfig('librsvg-2.0', '2.40'):
problems.append('Need rsvg Library for rendering icons.')
if not conf.CheckCHeader(['X11/Xutil.h', 'X11/Xlib.h'],'<>'):
@ -140,8 +157,7 @@ def configure(env):
print("*** unable to build due to the following problems:")
for isue in problems:
print(" * %s" % isue)
print()
print("build aborted.")
print("\nbuild aborted.")
Exit(1)
print("** Gathered Library Info: %s" % list(conf.env.libInfo.keys()))

41
admin/scons/Setup.py
View file

@ -4,7 +4,7 @@
##
# Copyright (C)
# 2012, Hermann Vosseler <Ichthyostega@web.de>
# 2012-2025 Hermann Vosseler <Ichthyostega@web.de>
#
# **Lumiera** is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the
@ -28,21 +28,24 @@ OPTCACHE = 'optcache'
CUSTOPTFILE = 'custom-options'
# these are accessible via env.path.xxxx
buildExe = '#$TARGDIR'
buildLib = '#$TARGDIR/modules'
buildPlug = '#$TARGDIR/modules'
buildIcon = '#$TARGDIR/gui/icons' # for IconResource() and IconRender()
buildUIRes = '#$TARGDIR/gui/' # for GuiResource()
buildConf = '#$TARGDIR/config' # for ConfigData()
installExe = '#$DESTDIR/lib/lumiera'
installLib = '#$DESTDIR/lib/lumiera/modules'
installPlug = '#$DESTDIR/lib/lumiera/modules'
installIcon = '#$DESTDIR/share/lumiera/icons'
installUIRes = '#$DESTDIR/share/lumiera/'
installConf = '#$DESTDIR/lib/lumiera/config'
buildExe = '$TARGDIR'
buildLib = '$TARGDIR/modules'
buildPlug = '$TARGDIR/modules'
buildIcon = '$TARGDIR/gui/icons' # for IconResource() and IconRender()
buildUIRes = '$TARGDIR/gui/' # for GuiResource()
buildConf = '$TARGDIR/config' # for ConfigData()
installExe = '$DESTDIR/lib/lumiera'
installLib = '$DESTDIR/lib/lumiera/modules'
installPlug = '$DESTDIR/lib/lumiera/modules'
installIcon = '$DESTDIR/share/lumiera/icons'
installUIRes = '$DESTDIR/share/lumiera/'
installConf = '$DESTDIR/lib/lumiera/config'
installDoc = '$DESTDIR/share/doc/lumiera/'
#-------------------------------------------------------Configuration
buildSetup = Record(locals())
# passed to LumieraEnvironment() -> env.path.xxxx
@ -54,9 +57,9 @@ def defineBuildEnvironment():
define locations in source and target tree,
parse the commandline and pick up options
"""
EnsureSConsVersion(2,0)
EnsurePythonVersion(2,6)
Decider('MD5-timestamp') # detect changed files by timestamp, then do a MD5
EnsureSConsVersion(4,0)
EnsurePythonVersion(3,10)
Decider('content-timestamp') # detect changed files by timestamp, then do a MD5
buildVars = Variables([OPTCACHE, CUSTOPTFILE])
Options.defineCmdlineVariables(buildVars)
@ -80,11 +83,7 @@ def defineBuildEnvironment():
appendVal(env,'OPTIMIZE', 'CCFLAGS', val=' -O3')
appendVal(env,'DEBUG', 'CCFLAGS', val=' -ggdb')
# setup search path for Lumiera plugins
appendCppDefine(env,'PKGLIBDIR','LUMIERA_PLUGIN_PATH=\\"$PKGLIBDIR/:ORIGIN/modules\\"'
,'LUMIERA_PLUGIN_PATH=\\"ORIGIN/modules\\"')
appendCppDefine(env,'PKGDATADIR','LUMIERA_CONFIG_PATH=\\"$PKGLIBDIR/:.\\"'
,'LUMIERA_CONFIG_PATH=\\"$DESTDIR/share/lumiera/:.\\"')
# NOTE: could define optional compile features here....
Options.prepareOptionsHelp(buildVars,env)
buildVars.Save(OPTCACHE, env)

1
admin/setVersion
View file

@ -40,5 +40,6 @@ rewrite doc/devel/Doxyfile 'PROJECT_NUMBER\s*=' "$VER"
rewrite doc/devel/Doxyfile.browse 'PROJECT_NUMBER\s*=' "$VER"
rewrite admin/scons/Setup.py 'VERSION\s*=' "\'$VER\'"
rewrite README 'Version:' "$VER"
rewrite NEWS 'Version:' "$VER"
echo -e "\nSUCCESSFULLY rewritten version $VER\ncheck git diff\n\n"

4
data/SConscript
View file

@ -21,5 +21,9 @@ config = ( env.ConfigData('config','setup.ini', targetDir='$ORIGIN')
+ env.ConfigData('config','dummy_lumiera.ini')
)
#further resources...
env.Install('$SHARE/applications/' , 'desktop/lumiera.desktop')
env.Install('$SHARE/icons/hicolor/scalable/apps/', 'desktop/lumiera.svg')
Export('icons config')

13
data/desktop/lumiera.desktop Normal file
View file

@ -0,0 +1,13 @@
[Desktop Entry]
Type=Application
Version=1.5
Name=Lumiera
Comment=Video editing and compositing (unfinished; development preview)
GenericName=VideoEditor
Exec=lumiera
TryExec=lumiera
Icon=lumiera
Terminal=false
Categories=AudioVideo;Video;AudioVideoEditing;
Keywords=media;film;editing;compositing;fx;

146
data/desktop/lumiera.svg Normal file
View file

@ -0,0 +1,146 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
id="svg2"
sodipodi:version="0.32"
inkscape:version="1.4 (e7c3feb100, 2024-10-09)"
width="48"
height="48"
version="1.0"
sodipodi:docname="lumiera.svg"
inkscape:output_extension="org.inkscape.output.svg.inkscape"
inkscape:export-xdpi="96"
inkscape:export-ydpi="96"
style="display:inline"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns="http://www.w3.org/2000/svg"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<title
id="tit">Lumiera Icon</title>
<metadata
id="metadaz">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<cc:license
rdf:resource="http://creativecommons.org/licenses/by-sa/4.0/" />
<dc:title>Lumiera Icon</dc:title>
<dc:date>August 2009</dc:date>
<dc:creator>
<cc:Agent>
<dc:title>Thorsten Wilms</dc:title>
</cc:Agent>
</dc:creator>
<dc:rights>
<cc:Agent>
<dc:title>CC By SA</dc:title>
</cc:Agent>
</dc:rights>
<dc:publisher>
<cc:Agent>
<dc:title>Lumiera project</dc:title>
</cc:Agent>
</dc:publisher>
<dc:source>Lumiera Logo</dc:source>
<dc:description>After the Lumiera Logo contest, several flavours were created for use on posters, T-shirts and desktop icons</dc:description>
<dc:contributor>
<cc:Agent>
<dc:title>Raffaella Traniello, Thorsten Wilms, Odin Hørthe Omdal, Ichthyoste</dc:title>
</cc:Agent>
</dc:contributor>
</cc:Work>
<cc:License
rdf:about="http://creativecommons.org/licenses/by-sa/4.0/">
<cc:permits
rdf:resource="http://creativecommons.org/ns#Reproduction" />
<cc:permits
rdf:resource="http://creativecommons.org/ns#Distribution" />
<cc:requires
rdf:resource="http://creativecommons.org/ns#Notice" />
<cc:requires
rdf:resource="http://creativecommons.org/ns#Attribution" />
<cc:permits
rdf:resource="http://creativecommons.org/ns#DerivativeWorks" />
<cc:requires
rdf:resource="http://creativecommons.org/ns#ShareAlike" />
</cc:License>
</rdf:RDF>
</metadata>
<defs
id="defz" />
<sodipodi:namedview
inkscape:window-height="974"
inkscape:window-width="1592"
inkscape:pageshadow="2"
inkscape:pageopacity="1"
guidetolerance="10000"
gridtolerance="10.0"
objecttolerance="10.0"
borderopacity="1.0"
bordercolor="#666666"
pagecolor="#ffffff"
id="base"
showgrid="false"
showguides="false"
inkscape:guide-bbox="true"
inkscape:zoom="11.313708"
inkscape:cx="20.85965"
inkscape:cy="16.83798"
inkscape:window-x="0"
inkscape:window-y="25"
inkscape:current-layer="icon"
showborder="true"
inkscape:snap-global="false"
inkscape:object-nodes="true"
inkscape:snap-bbox="true"
inkscape:showpageshadow="2"
inkscape:pagecheckerboard="0"
inkscape:deskcolor="#d1d1d1"
inkscape:window-maximized="0">
<inkscape:grid
type="xygrid"
id="pxGrid"
visible="true"
enabled="true"
originx="0"
originy="0"
spacingy="1"
spacingx="1"
units="px" />
</sodipodi:namedview>
<g
inkscape:groupmode="layer"
id="icon"
transform="translate(-564.01849,-192.09436)"
style="display:inline">
<g
id="Logo">
<path
id="table"
sodipodi:nodetypes="cccccc"
d="m 564.5112,210.98141 v 0.45786 l 19.5433,18.66438 26.77877,-15.57248 v -0.35188 z"
style="fill:black;fill-opacity:1;stroke:none" />
<path
id="film"
sodipodi:nodetypes="ccccc"
d="m 564.5112,210.98141 27.27689,-8.35278 19.04518,11.55066 c -10.81551,6.23715 -16.4368,10.39168 -26.15309,10.50704 -7.5443,-2.32704 -11.57683,-5.26501 -20.16898,-13.70492 z"
style="fill:#d1d1d1;fill-opacity:1;stroke:none" />
<path
id="perfL"
d="m 571.21142,210.13188 c -0.0729,0.006 -0.15313,0.0206 -0.23949,0.043 l -2.4955,0.77977 c -0.2756,0.0849 -0.46039,0.33284 -0.27813,0.53982 0.36725,0.36067 0.72241,0.70885 1.08164,1.05397 0.27562,0.27689 0.61822,0.34566 1.05846,0.19708 l 2.54958,-0.86546 c 0.23006,-0.076 0.29825,-0.32835 0.0231,-0.56553 -0.37225,-0.3197 -0.74512,-0.63606 -1.13572,-0.97684 -0.17853,-0.15388 -0.34521,-0.22051 -0.56399,-0.20565 z m 4.31112,3.67603 c -0.0885,0.003 -0.1894,0.022 -0.30905,0.0515 l -2.5882,0.95113 c -0.37945,0.17432 -0.41664,0.41959 -0.15452,0.64267 0.41082,0.35306 0.82326,0.69947 1.23615,1.03682 0.3253,0.27284 0.69325,0.36426 1.17435,0.18852 l 2.51867,-0.994 c 0.26139,-0.11106 0.35321,-0.32978 0.0155,-0.6255 -0.403,-0.3185 -0.81248,-0.64841 -1.23615,-0.994 -0.23472,-0.16739 -0.39114,-0.26801 -0.65672,-0.25705 z m 4.84418,3.68456 c -0.13115,-0.002 -0.27234,0.0253 -0.44037,0.0686 -0.81978,0.32109 -1.64079,0.64721 -2.47232,0.96828 -0.33839,0.12938 -0.40659,0.43576 -0.10818,0.64264 0.46137,0.31986 0.95271,0.61389 1.44477,0.9083 0.43164,0.25825 0.81122,0.26759 1.26707,0.10279 0.76545,-0.28673 1.52634,-0.58079 2.28689,-0.87401 0.22929,-0.10256 0.36223,-0.4228 0.054,-0.64266 -0.4836,-0.32072 -0.96137,-0.64731 -1.43703,-0.97684 -0.1915,-0.12324 -0.37631,-0.19421 -0.5949,-0.19709 z m 5.40048,3.63317 c -0.14118,-0.006 -0.29493,0.0273 -0.4713,0.0857 -0.72968,0.24146 -1.35533,0.34032 -2.23279,0.5741 -0.23134,0.0615 -0.34924,0.35275 0.007,0.53983 0.54359,0.2849 1.1162,0.6196 1.80789,0.84831 0.3715,0.12283 0.74511,0.13789 1.21297,0.0686 0.785,-0.11635 1.67732,-0.25709 2.09374,-0.43701 0.41645,-0.17993 0.36535,-0.32115 0.12363,-0.46272 -0.53078,-0.31087 -1.33393,-0.64861 -1.83105,-0.94256 -0.26835,-0.16655 -0.4755,-0.26603 -0.7108,-0.27421 z"
style="fill:black;fill-opacity:1;stroke:none" />
<path
id="perfR"
d="m 591.39172,203.79956 c -0.0494,0.003 -0.10106,0.0183 -0.15453,0.0342 l -1.6688,0.52269 c -0.1848,0.0549 -0.21341,0.22229 -0.0387,0.3342 l 1.29796,0.83974 c 0.15821,0.10145 0.39519,0.13142 0.66444,0.0515 l 1.61473,-0.53983 c 0.16063,-0.0478 0.15627,-0.21697 0,-0.31705 l -1.26707,-0.77976 c -0.16472,-0.10543 -0.30005,-0.15622 -0.4481,-0.14565 z m 4.26475,2.57919 c -0.0823,-0.002 -0.16408,0.0232 -0.26268,0.0686 l -1.62247,0.59981 c -0.11529,0.0738 -0.20069,0.25346 -0.007,0.37704 l 1.38297,0.89113 c 0.25457,0.16303 0.47642,0.17999 0.76485,0.0943 l 1.64564,-0.64265 c 0.11287,-0.0518 0.11599,-0.23121 -0.0851,-0.35989 l -1.38294,-0.84831 c -0.16435,-0.10521 -0.29572,-0.17595 -0.43267,-0.17995 z m 4.65877,2.9648 c -0.0691,0.006 -0.13877,0.0198 -0.21633,0.043 -0.54147,0.22256 -1.08053,0.4462 -1.62246,0.66837 -0.14527,0.0667 -0.14777,0.30413 0.0464,0.42843 l 1.51431,0.97685 c 0.27785,0.17793 0.58465,0.25893 0.84985,0.13709 0.55604,-0.23607 1.11254,-0.47583 1.66881,-0.7112 0.14402,-0.0661 0.14542,-0.26015 -0.0773,-0.40274 l -1.59928,-0.9854 c -0.17828,-0.11417 -0.3566,-0.17156 -0.56399,-0.15424 z m 5.08369,3.13618 c -0.0704,0.007 -0.14072,0.0289 -0.20859,0.0601 -0.53685,0.25639 -1.06191,0.50994 -1.58383,0.76263 -0.15347,0.1306 -0.12594,0.37642 0.11589,0.53126 l 1.67653,1.07967 c 0.34068,0.21815 0.60303,0.25405 0.8576,0.1371 0.5128,-0.28638 1.034,-0.57794 1.56837,-0.88259 0.16221,-0.10393 0.0826,-0.34647 -0.13907,-0.48842 l -1.64564,-1.00255 c -0.21055,-0.13481 -0.42985,-0.21819 -0.64126,-0.19708 z"
style="fill:black;fill-opacity:1;stroke:none" />
</g>
</g>
</svg>
Side by side

After

Width:  |  Height:  |  Size: 7.8 KiB

5
doc/SConscript
View file

@ -8,9 +8,10 @@ Import('env')
doxydoc = env.Doxygen('devel/Doxyfile')
env.Clean(doxydoc, doxydoc + ['devel/,doxylog','devel/doxygen-warnings.txt'])
# env.Install(dir = '$DESTDIR/share/doc/lumiera$VERSION/devel', source=documentation)
env.Clean (doxydoc, doxydoc + ['devel/,doxylog','devel/doxygen-warnings.txt'])
# HTML-documentation: this is a *placeholder* (eventually we'll build a user manual via Asciidoc)
env.DocFile('devel', 'LumieraHelpLandingPage.html', 'manual-html/index.html')
Export('doxydoc')

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

@ -98,7 +98,7 @@ within the engine independently, relying on worker jobs and a thread pool.
Initialisation and Lifecycle
----------------------------
After some discussion,footnote:[See the
link:{ldoc}/devel/rfc/GlobalInitialization.html[GlobalInitialisation] RfC
link:{rfc}/GlobalInitialization.html[GlobalInitialisation] RfC
from spring 2008. In the beginning, we all agreed to ``keep matters simple''
and build an `init()` function within one central piece of code everyone knows
and hooks into. However, while the outline of the application emerged, there

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

@ -10,6 +10,6 @@ The Lumiera application uses two quite different sources for configuration
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.
-> see also the link:{ldoc}/technical/vault/ConfigLoader.html[Config Loader brainstorming from 2008] (implementation details)
-> see also the link:rfc/ConfigLoaderDraft2008.html[Config Loader brainstorming from 2008] (implementation details)

12
doc/design/architecture/ETD.txt
View file

@ -1,7 +1,7 @@
External Tree Description
=========================
:Author: Ichthyostega
:Date: Fall 2015
:Date: Autumn 2015
@ -17,11 +17,11 @@ Any collaboration requires, as an underlying, some kind of common understanding.
And any formalised, mechanical collaboration requires to represent that common point of attachment --
at least as _symbolic representation._ The »External Tree Description« is shaped to fulfil this need:
_in theory,_ the whole field could be represented, symbolically, as a network of hierarchically
structured elements. Yet, _in practice,_ all we need is to conceive the presence of such a representation,
structured elements. Yet, _in practice,_ all we need is to presuppose the presence of such a representation,
as a backdrop to work against. And we do so -- we work against that symbolic representation,
by describing *changes* made to the structure and its elements. Thus, the description of changes,
the link:{ldoc}/technical/library/DiffFramework.html[diff language], refers to and partially embodies
such symbolically represented elements and relations.
by describing *changes* made to the structure and its elements. And so the description of changes,
the link:{ldoc}/technical/library/DiffFramework.html[diff language], thus refers to and partially
embodies such symbolically represented elements and relations.
Elements, Nodes and Records
---------------------------
@ -29,7 +29,7 @@ We have to deal with _entities and relationships._
Entities are considered the building blocks, the elements, which are related by directional links.
Within the symbolic representation, elements are conceived as *generic nodes* (`GenNode`),
while the directed relations are impersonated as being attached or rooted at the originating side,
so the target of a relation has no traces or knowledge of being part of that relation. Moreover, each
so that the target of a relation has no knowledge of being part of that relation. Moreover, each
of our nodes bears a _relatively clear-cut identity._ That is to say, within the relevant scope in question,
this identity is unique. Together, these are the building blocks to represent any *graph*.

16
doc/design/architecture/playRender.txt → doc/design/architecture/Playback.txt
View file

@ -3,7 +3,7 @@ Design: Playback and Render Control
:Author: Ichthyostega
:Date: 5/2011
//MENU: label Player subsystem
//MENU: label Playback
**************************************************************************************
This part of the architecture is concerned with how to initiate, coordinate and control
@ -24,10 +24,12 @@ discussions and brainstorming sessions.
* discussions regarding time values and timecode handling shed some light on the requirements
to be fulfilled by a player subsystem
- link:http://article.gmane.org/gmane.comp.video.lumiera.general/2116[Timecode Widget and Framerates]
- link:http://article.gmane.org/gmane.comp.video.lumiera.general/2109[Time, Time-spans, Quatisation and Timecode]
- link:{l}/wiki/renderengine.html#TimeQuant[Definition of Time entities]
from the implementation notes in the TiddlyWiki
- https://lists.lumiera.org/pipermail/lumiera/2010-July/001984.html[Timecode formats and time widget]
- https://lists.lumiera.org/pipermail/lumiera/2010-December/002197.html[Timecode Widget and Framerates]
- https://lists.lumiera.org/pipermail/lumiera/2010-December/002190.html[Time, Time-spans, Quatisation and Timecode]
* at the _framework level_ a set of definitions has been created to handle
link:/x/TimeUsage.html[time values and quantisation].
Reasoning Behind the Player Subsystem's Structure
@ -152,8 +154,8 @@ reconfigure the vault layer services.
Frame quantisation
^^^^^^^^^^^^^^^^^^
link:../TimeQuant.html[Quantisation] is a kind of rounding; like any kind of rounding, quantisation is
a dangerous operation because it kills information content.
link:/x/TimeQuant.html[Quantisation] is a kind of rounding; like any kind of rounding,
quantisation is a dangerous operation because it kills information content.
Thus, there are three fundamental guidelines when it comes to rounding:

9
doc/design/architecture/index.txt
View file

@ -5,7 +5,6 @@ Design Documents: Lumiera Architecture
// Menu : prepend child Subsystems
// Menu : prepend child ArchitectureSummary
// Menu : attach child TimeQuant after TimeUsage
This section will feature some rather high-level considerations regarding
the architecture of the application.
@ -14,6 +13,12 @@ the architecture of the application.
See link:ArchitectureSummary.html[here] for a short summary of the core architecture
ideas of the envisioned Lumiera Application.
.Time and Time-code
link:time/[Handling of time values] and link:time/TimeCode.html[Time Code] is
essential for an editing application and requires some forethought to avoid
some of the common inconsistencies and pitfalls; precision can be a challenge,
given the extremely large range of time scales to cover.
.Rendering and Playback Control
This part of the architecture is concened with how to initiate, coordinate and control
the calculation processes necessary to generate visible / audible data from our source
@ -21,6 +26,6 @@ media. This design is _not so much_ concerned with the actual calculations; inde
takes on an ``bird eye's view'', treating the actual render engine mostly just as an
opaque entity providing some service.
-> link:playRender.html[Design: Playback and Rendering]
-> link:Playback.html[Design: Playback and Rendering]

13
doc/design/architecture/time/TimeCode.txt Normal file
View file

@ -0,0 +1,13 @@
Handling of Time Code Formats
=============================
.A Design draft
Since handling of time values and time code formats is of uttermost importance
for editing film, a draft concept was created in the early phase of Lumiera design.
The chosen approach relies heavily on a framework for representation of temporal data
developed for this purpose in the Lumiera support library. However, the implementation
of various actual time code formats was deferred for later -- while the viability of
this design yet needs to be validated by actual usage.
Detailed analysis and planning can be found in the
link:/x/fwd/DevWiki.TimeCode.html[DevWiki: TimeCode].

48
doc/design/architecture/time/TimeMutation.txt Normal file
View file

@ -0,0 +1,48 @@
Modify Quantised Time Values
============================
.Challenges
Temporal data can be complex and given in several flavours; a request to _modify_
some given time data adds a further layer of complexity, since the required modification
can itself be specified in various forms. And on top of that, the temporal data can be
quantised, or can be represented through a quantised view, while also the modification
can be given in any form of quantification, even based on a different time grid.
When it comes to resolving this kind of multi-layered complexity, it is crucial
to stick to the principles of logically sound reasoning; furthermore, especially
the situation where several disjoint time grids are involved may require some
additional decision rule to determine which grid has to take priority.
.Problematic choices of design
While the Lumiera developers immediately recognised the danger of code quality problems,
there was no consensus how to approach these difficulties. Should everything in the
Render Engine be based on frame counts? Can questions of grid alignment be pushed out
to the system's boundaries? Is grid alignment mostly a problem of UI representation?
An attempt was made to base time handling on simple integral data types, with a plain-C
library to provide quantisation and timecode functions -- which however could not prevent
the proliferation of ad-hoc computations at various places, given that temporal data
seems to be ``just simple numbers''. In an attempt to get this situation under control
before problems start to accumulate and spread, _Ichthyo_ pushed for a radical approach
to rely on the _C++ type system_ and use _opaque_ entities with controlled arithmetic.
Unfortunately, those basic time entities were also defined to be _immutable_ -- following
a trend towards functional programming, which became increasingly popular at that time.
This new framework proved itself successful as a device to identify and eliminate ad-hoc
solutions -- yet state, being a part of the real world, can not be eliminated by dictum,
and will claim it's right sooner or later.
- very soon, a `TimeVar` datatype was introduced, since ``pure'' functional concepts
can never compete with the _intuitivity_ of ``just using numbers''
- from a users point of view, the GUI exposes time-related entities which can be
manipulated -- notably the playback position. An attempt was made, to _encapsulate_
these manipulations as a `time::Control`
In this (slightly compromised) form, the new framework was able to support all
time-data related tasks encountered for the first (GTK-2) version of the UI.
Some more technical explanations can be found in the
link:/x/fwd/DevWiki.TimeMutation.html[DevWiki: TimeMutation].
In hindsight, using opaque types was very successful -- while the immutability seems
to be a mistake and induces a lot of unnatural complications. A design change to
rectify the situation was planned and documented as
link:/x/ticket/1261.html[#1261 »reconsider (im)mutability of time entities«]

12
doc/design/architecture/TimeQuant.txt → doc/design/architecture/time/TimeQuant.txt
View file

@ -44,7 +44,7 @@ changing time::
Time values are _immutable,_ like numbers.
+
Only a *time variable* can be changed -- yet some of the special time entities
can recieve link:TimeMutation[mutation messages], allowing e.g. for
can receive link:/x/TimeMutation.html[mutation messages], allowing e.g. for
adjustments to a time interval selection from the GUI
''''
@ -99,7 +99,7 @@ frame count::
timecode::
Quantisation also is the foundation of all kinds of formalised time specifications
actually even a frame count is some kind of (informal) timecode -- other timecodes
employ a standardised format. //Every// presentation of time values and every
employ a standardised format. _Every_ presentation of time values and every
persistent storage and exchange of such values is based on time codes.
Yet quantisation and time code aren't identical: a given quantised time value
typically can be cast into multiple timecode formats.
@ -202,11 +202,9 @@ There is a common baseclass `TCode` though, which can be used as marker
or for _type erasure._
-> more on link:TimeUsage.html[usage situations]
////
// TODO integrate those cross links
+
-> Timecode link:TimecodeFormat[format and quantisation]
-> Timecode link:/x/TimeCode.html[format and quantisation]
+
-> Quantiser link:QuantiserImpl[implementation details]
////
-> Quantiser link:/x/imp/TimeQuantiser.html[implementation details]

18
doc/design/architecture/TimeUsage.txt → doc/design/architecture/time/TimeUsage.txt
View file

@ -8,7 +8,7 @@ Time Usage Situations
the following collection of usage situations helps to shape the details of the
time values and time quantisation design. +
-> see also link:TimeQuant.html[more about time quantisation]
-> see also link:/x/TimeQuant.html[more about time quantisation]
time position of an object::
indeed the term ``time position'' encompasses two quite different questions
@ -45,7 +45,7 @@ updating the playback position::
possible loop positions are way finer than the processing block size)
dispatching individual frames for calculation::
when a link:PlayProcess[render or playback process] is created, at some point
when a link:/x/PlayProcess.html[render or playback process] is created, at some point
we need to translate this logical unit (``calculation stream'') into individual
frame job entries. This requires to break continuous time into individual
frames, and then ennumerating these frames.
@ -113,7 +113,7 @@ desirable somehow to move these distinctions out of the scope of this design and
offload them onto the client (code using these time classes).
Another closely related problem is *when to allow mutations*, if at all (-> see
link:TimeMutation[more here...]). We can't completely do away with mutations,
link:/x/TimeMutation.html[more here...]). We can't completely do away with mutations,
simply because we don't have a pure functional language at our disposal. The
whole concept of _reference semantics_ doesn't play so well with immutable
objects. The Lumiera high-level (session) model certainly relies on objects
@ -140,8 +140,8 @@ in this case quantised values and quantisation are approached in the reverse
direction, compared with the other uses. Here, after establishing a start point
on the time scale, we proceed with ennumerating distinct frames and later on
need to access the corresponding raw time, especially to find out about the
link:Segmentation[timeline segment] to address, or for retrieving parameter
automation. -> link:FrameDispatcher[see frame dispatching].
link:/x/Segmentation.html[timeline segment] to address, or for retrieving parameter
automation. -> link:/x/FrameDispatcher.html[see frame dispatching].
Note that the *display window might be treated as just an independent instance
of quantisation*. This is similar to the approach taken above for modifying
@ -176,11 +176,11 @@ closing the circle.
substantial problems to be solved
---------------------------------
* how to link:TimeGridAlignment[align multiple grids]
* how to integrate link:TimeMutation[modifications of quantised values]. ([green]#✔ solved#)
* how to align multiple grids -- what grid to use for playback?
* how to integrate link:/x/TimeMutation.html[modifications of quantised values]. ([green]#✔ solved#)
* how to isolate the Time/Quantisation part from the grid MetaAsset in the
session -> we use the link:Advice[Advice] system ([green]#✔ solved#)
session -> we use the link:/x/Advice.html[Advice] system ([green]#✔ solved#)
* how to design the relation of Timecode, Timecode formatting and Quantisation
-> link:TimecodeFormat[more here] [yellow-background]#WIP#
-> link:/x/TimeCode.html[more here] [yellow-background]#WIP#

21
doc/design/architecture/time/index.txt Normal file
View file

@ -0,0 +1,21 @@
Time Handling
=============
// Menu : sort children
// Menu : attach child TimeQuant after TimeUsage
// Menu : append child TimeMutation
While Lumiera will be able to handle various kinds of different content and data,
the task of _editing_ implies to arrange elements into a temporal dimension.
Thus representation of time and expression of relations in time plays a pivotal role.
At first sight, time seems to we well-known, commonplace and trivial to understand --
which however is a deception, since anything related to time, timings, duration and
time scales is notoriously difficult to spell out with precision and tricky to
handle in the practice of programming. A high-level discussion should thus
- start with an analysis of link:TimeUsage.html[usage situations]
- alignment to a pre-determined grid scale, the so called
link:TimeQuant.html[Time Quantisation] requires careful attention
- formal representation of link:TimeCode.html[Time Code] is central to film editing.

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

@ -55,8 +55,7 @@ Requirement analysis of playback modes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For the task of editing a piece of media, the following modes of playback presentation can be determined +
See also the more
link:wiki/renderengine.html#NonLinearPlayback%20PlayService%20PlayProcess%20CalcStream%20FrameDispatcher%20OutputManagement[
technical discussion of playback in the TiddlyWiki]
link:imp/NonLinearPlayback.html[technical discussion of non-linear playback]
regular playback::

11
doc/design/engine/PlayProcess.txt Normal file
View file

@ -0,0 +1,11 @@
Playback and Render Processing
==============================
.Prototyping and Exploration
On a conceptual level, this topic reaches far beyond the mere data processing
and is undeniably one of the most complex and interwoven aspects of Lumiera.
As of 2025, most structures in this realm are in a state of prototyping --
many topics are in flux and what works well needs to be figured out yet.
Many detailed notes can be found in the
link:/x/fwd/DevWiki.PlayProcess.html[DevWiki: PlayProcess].

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

@ -2,5 +2,5 @@ Design Documents: Renderengine
==============================
This section contains design documents regarding the overall workings of the Render Engine,
and the handling of output generation and output connections.
data processing and the handling of output generation and output connections.

12
doc/design/governance/integration.txt
View file

@ -6,12 +6,12 @@ Towards Integration
//Menu: label Integration
The Lumiera project creates innovative software, geared towards professional, high-quality work;
it aims at high flexibility, offering user-control over a broad spectrum of configurable parameters,
and with smooth workflows that scale well to larger and more intricate projects. Building such
software involves some degree of exploration and search for adequate methods to reconcile
conflicting goals. There is no ready-made blueprint that just needs implementation -- rather,
we have to resort to a sequence of integration efforts, aimed at establishing core tenets
of the envisioned architecture.
it is characterised by comprehensive flexibility, allowing precise control of a wide range of
parameters, as well as seamless workflows capable of handling even large and complex projects.
Building such software involves some degree of exploration and the search for suitable ways to
reconcile sometimes conflicting goals. There is no ready-made blueprint that simply needs to be
implemented -- rather, we have to resort to a sequence of integration efforts, to establish the
core tenets of our envisioned architecture.
Vertical Slices

2
doc/design/gui/GuiDiscussion/ConceptProposals/AkhiL.txt
View file

@ -10,5 +10,5 @@ Wiring nodes within the timeline
In fall 2007, rather then using an external node editor, AkhiL proposed to do wiring
of effect nodes directly within the timeline. He did the following Mockup:
image::{imgg}/AkhiL.proposal.png[]
image::{imgg}/proposal.AkhiL.png[]

2
doc/design/gui/GuiDiscussion/ConceptProposals/Alcarinque.txt
View file

@ -35,7 +35,7 @@ and add new functions. Of course this modules I am talking about, are not the
modules described in the architecture overview. This is the gui, which is an
abstraction of the real program.
image::{imgg}/Alcarinque.proposal.png[Alcarinque's GUI proposal]
image::{imgg}/proposal.Alcarinque.png[Alcarinque's GUI proposal]
Here I made a sample of the architecture of the UI. Please don't take this too
seriously, it is just a draft so you can understand the workflow. I haven't

10
doc/design/gui/GuiDiscussion/ConceptProposals/Barnes.txt
View file

@ -3,7 +3,7 @@ GUI Proposal by Clay Barnes
:Author: R. Clayton Barnes (»rcbarnes«)
:Date: 2008-05-21
-> https://www.hci-matters.com/blog/2008/05/21/archives/41/[original blog entry]
-> https://web.archive.org/web/20120128160238/https://www.hci-matters.com/blog/2008/05/21/archives/41/[original blog entry]
.About the Author
***********************************************************************************************************
@ -17,15 +17,15 @@ I’ve pulled together some drafts of my ideas for the design of the timeline po
of the Lumiera non-linear video editor (hopefully, the successor to http://cinelerra-cv.wikidot.com[Cinelerra]).
The un-annotated version::
image:{imgg}/Barnes.proposal.png[
image:{imgg}/proposal.Barnes.png[
"Lumiera UI proposal",width=300,
link="{imgg}/Barnes.proposal.png"] +
link="{imgg}/proposal.Barnes.png"] +
(click to enlarge)
The annotated version::
(explaining some of the finer points)
image:{imgg}/Barnes.proposal-annotated.png[
image:{imgg}/proposal.Barnes-annotated.png[
"Lumiera UI proposal (annotated)",width=300,
link="{imgg}/Barnes.proposal-annotated.png"]
link="{imgg}/proposal.Barnes-annotated.png"]

2
doc/design/gui/GuiDiscussion/ConceptProposals/RichardSpindler.txt
View file

@ -25,4 +25,4 @@ represent another View, and the connection from the timeline to the
compositing nodes will be by Name, and not by arrows. Default Names
would be "Video Track #1", etc.
image::{imgg}/RichardSpindler.proposal.png[]
image::{imgg}/proposal.RichardSpindler.png[]

279
doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt
View file

@ -5,9 +5,8 @@ GUI Brainstorming Reviewed
State of the GUI
----------------
image:{l}/media/img/design.gui/screenshot090124-resources.jpg[Screenshot 090124]
image::{imgg}/screenshot2009-01.jpg[title="Screenshot 2009-01",width="80%"]
Updated 18/01/09
Done
@ -20,7 +19,8 @@ One Window can be tiled (horizontally/vertically) giving areas where screen elem
* Multiple windows +
Can open multiple windows on one head and (optionally) tile them as above
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
+
ct:: '2008-02-07T20:42:54Z'
* My personal preference would be to produce the GUI in C++ with Gtkmm. Gnome is the most popular desktop for Linux, and GTK now has good support both for Win32, Mac and KDE (except that GTK on Mac still needs X11, probably for some more time)
@ -42,7 +42,8 @@ High Priority
* A good entry level gui together with an advanced key driven system like about blender (not so much the ui)
- Yes Blender's UI isn't that great a model to follow (though there is some good stuff in there). I agree about good keyboard support. A good place to start would be the standard <Modkeys>+<Letter> accelerators, as well as context menu mnemonics. We should be able cover the entire command set with the these. I don't see us needing anything more advanced than that.
-- link:JoelHoldsworth[] [[DateTime(2008-07-22T20:48:03Z)]]
+
JoelHoldsworth:: '2008-07-22T20:48:03Z'
Medium Priority
@ -50,17 +51,25 @@ Medium Priority
* Fullscreen Support +
Windows can be made fullscreen with no decorations (but tiling left intact)
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
+
ct:: '2008-02-07T20:42:54Z'
- Comment: This can be done with relative ease. We should add this feature.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
joelholdsworth:: '2008-07-21T21:58:48Z'
--
* Work well with tiling window managers +
I propose that the future Lumiera GUI is designed without too much (or anything) about the user's screen apart from what is acceptable based on the X11 protocol(?) in order to work well with tiling window managers. The main problem to watch out for is assuming specific dimensions. The nature of tiling window managers is that most of the time, the windows without focus are dramatically downsized in one or two dimensions. This causes poorly designed GUIs to behave strangely, sometimes as bad as constantly jumping between layouts and thus causing unnecessary CPU load.
-- link:MichaelPloujnikov[] [[DateTime(2008-04-14T22:29:12Z)]]
+
MichaelPloujnikov:: '2008-04-14T22:29:12Z'
- Comment: As much as anything this is a case for good testing on tiling window managers. People who use them need to do this, and file bugs, or better yet patches. It would be good for me to start using one as well, I think.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
joelholdsworth:: '2008-07-21T21:58:48Z'
--
* Window configurations can be stored/restored in customizable presets and are part of the project (see blender again)
@ -68,19 +77,25 @@ I propose that the future Lumiera GUI is designed without too much (or anything)
A jog tool is a sliding ui element that when clicked and held, will play the video at a certain rate as the mouse drags left or right. As the mouse drags the the left the video plays forward faster (It should advance very slowly at first.). It acts the same way when the mouse drags to the right, except that the video plays in reverse. Again, it can be tedious trying to make frame-accurate cuts to long video files. Without a jog tool it makes it more tedious to get to the exact frame you want to cut on because you must scan through, then click the next frame button half a dozen times. A jog tool would remedy this because one could easily vary the playback rate, even reverse it, zeroing in on the frame much more quickly. Together these two features could really increase the speed at which one can edit precisely in Cinelerra.
- Comment: This idea seems feasible, it could be worked together with cehteh shuttle slider proposal.
-- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]]
+
joelholdsworth:: '2008-07-19T19:42:04Z'
* most numeric value entries (sliders, spinbuttons) can be changed when hovering the mouse over it and turn the scroll wheel (maybe with an additional modifier key?) -- The scroll wheel is accelerated depending on how fast it is operated by the user, snapping it slowly gives frame/interval precise increments, turning it faster will exponentially increases the increment (2,4,8.. frames per click)
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
+
ct:: '2008-02-07T20:42:54Z'
* "Render AS" +
The *process for creating a DVD* where Video and Audio have to be rendered separately is laborious. A script could easily handle this, and make the use of the program so much easier, attractive, inviting, productive, time efficient, bla bla. All the user needs to do is set the parameters and file name (once) and then "do". Many commonly used formats for saving could be saved as presets that completely avoid all the questions (say in the "File" drop down menu, as a customizable "Render AS" choice). This could also be done for HDTV, iPod, Ringtones, VCD, Various formats that give the best performance for uploading to Youtube and all the other video sharing sites.
+
When a whole magazine article(s) can be written about the task of exporting a file to make a DVD, you know the process is a long one. mmm ... Any well paid journalists out there want to sponsor programmed task efficiency? - "NO?" - oh well.
-- link:Tree[] [[DateTime(2008-05-07T16:44:00Z)]]
+
Tree:: '2008-05-07T16:44:00Z'
- This could probably be solved by having a series of format presets in the Render dialog. The default set could contain settings for the values you mention. We could even allow the user to save their own presets. Cinelerra already has this functionality - these are called profiles, but it doesn't come with a default set at all.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:13:28Z)]]
+
--
JoelHoldsworth:: '2008-07-24T16:13:28Z'
--
* Reduced quality previews +
There needs to be a way of giving the user the choice to see the movie at full quality - computationally expensive, or at reduced quality for times when full framerate would be impossible.
@ -89,14 +104,21 @@ There needs to be a way of giving the user the choice to see the movie at full q
Let the user have more flexibility over the track view height. Some tracks can be set to minimal, others to visible (but basically iconic), others enough to see features, and one or two to good resolution. Some may even be blanked.
+
The track view height could be individually selectable , for example, by changing the "draw media" icon from toggle mode to drop down menu. The drop down selection options could include "don't show", followed by track sizes as per the drop down menu at the bottom of track view.
-- link:Tree[][[DateTime(2008-05-07T17:30:00NZ)]]
- Comment: Yes, I was thinking about this idea myself. At first I was thinking of just allowing the user to expand or collapse the track with a +/- button. But then I wondered if it would be good to have the track completely sizable. My current thinking is the best way would be to have it sizable but with a kind of snap-to-grid behaviour so the whole thing doesn't become really messy.
-- link:JoelHoldsworth[] [[DateTime(2008-08-04T16:03:24Z)]]
+
Tree:: '2008-05-07T17:30:00NZ'
+
--
* Ardour provides an example for this: the track height can be changed (by buttons or with the mouse wheel + modifyer key), but there is only a fixed set of possible track heights, some of which have a preconfigured layout. For example, in "smallest" size the track head shows only the track label without any buttons and the track is reduced to a tiny waveform.
-- link:Ichthyostega[] [[DateTime(2008-08-08T15:18:31Z)]]
** Comment: Yes, I was thinking about this idea myself. At first I was thinking of just allowing the user to expand or collapse the track with a +/- button. But then I wondered if it would be good to have the track completely sizable. My current thinking is the best way would be to have it sizable but with a kind of snap-to-grid behaviour so the whole thing doesn't become really messy.
+
--
JoelHoldsworth:: '2008-08-04T16:03:24Z'
--
** Ardour provides an example for this: the track height can be changed (by buttons or with the mouse wheel + modifyer key), but there is only a fixed set of possible track heights, some of which have a preconfigured layout. For example, in "smallest" size the track head shows only the track label without any buttons and the track is reduced to a tiny waveform.
+
--
Ichthyostega:: '2008-08-08T15:18:31Z'
--
--
@ -106,29 +128,37 @@ Low Priority
* Multi Head +
Can open Windows on different heads of the same server, and is aware of the existence of different physical monitors (ie. Xinerama-aware)
- Comment: Xinerama seems to be a decreasingly popular way of doing multi-monitor. This probably could be implemented, but I don't have a Xinerama based setup, and I've never talked to anyone who does. I use link:TwinView[], and it seems like a more practical way of doing dual screen to me. Surely RandR based multi-monitor is the main need today.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
- Comment: _Xinerama_ seems to be a decreasingly popular way of doing multi-monitor. This probably could be implemented, but I don't have a _Xinerama_ based setup, and I've never talked to anyone who does. I use _TwinView_, and it seems like a more practical way of doing dual screen to me. Surely _RandR_ based multi-monitor is the main need today.
+
joelholdsworth:: '2008-07-21T21:58:48Z'
+
--
* Multi-Head != Xinerama ... This is very important and quite common, We want to support monitors driven at the native Video Format (resolution, framerate, interlacing, overscan, ....). For a professional setup this is really required!
-- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]] +
Xinerama and twinView test comparison http://www.phoronix.com/scan.php?page=article&item=387&num=1[]
+
ct:: '2008-07-22T07:11:11Z'
* Xinerama and twinView test comparison -> https://www.phoronix.com/review/387[see @Phoronix...]
--
* Automatic Clip Creation based on video content. +
When scanning through an hour long video clip, it can be tedious to go through it all making clips. It would allow the user to get right to work if Lumiera could split the video into clips based on scene changes. Each clip would begin at precisely the frame the current shot begins and end at the last frame before the next shot. As long as the user could then edit these clips on the timeline, this would decrease the time spent sifting through the raw footage.
- Comment: This seems like a good idea, and quite easy to implement. I think that when we get the video-capture and media manager code working this would a be a good subproject for someone to take on.
-- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]]
+
joelholdsworth:: '2008-07-19T19:42:04Z'
* Import and Export SMIL files +
Many current cinelerra users probably use kino for their capturing of DV. it uses less resources, so less system demand during capture. Good display monitor while capturing. Open Movie Editor is a good multitrack editor that can share Kino's SMIL files. A good progression in complexity of editing is start with kino, move to OME, then cinelerra (lumiera). A really convenient way to assist stepping up from Kino is to handle the SMIL files.
+
Automatic scene detection is a great feature in Kino. The simpler editors make it easy for less skilled people to look after the selection of preliminary clips, while lumiera is used by the folks who put it all together, and finish it off.
--link:Tree[][[DateTime(2008-05-09T15:10:00NZ)]] .
+
Tree:: '2008-05-09T15:10:00NZ'
- Comment: SMIL is quite cool technology. It's not just a Kino thing. It'd be quite good to be able to import this standard format.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:41:02Z)]]
+
--
JoelHoldsworth:: '2008-07-24T16:41:02Z'
--
More Discussion Needed
@ -141,40 +171,66 @@ Timeline
Make the timeline view _sparse_, that means the time on top is not continuous anymore but \'boring' sequences get omitted and \'interesting' sequences get displayed, probably even stretched to cover at least a single thumbnail.
+
This needs an ui (menu or whatever) to turn this feature on and some selection which events the user is interested in (scene cuts, transitions begin/end/mids, keyframes (begin/mid), labels, ...)
-- link:ct[] [[DateTime(2008-05-21T13:46:51Z)]]
- Comment: Do you think we could use view splitting to accomplish this? You can see this sort of thing OpenOffice.org calc. Where you drag a splitter out from the ends of the scrollbar, this allows you compare 2 or 4 parts of a big spreadsheet at the same time. Implementing something like that might be reasonably doable. But if you're talking about hiding periods on the timeline, that sounds a lot less easy to me, and it feels like a bit a bit of an odd thing to do. What do you think ct?
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
* No, view-splitting is something different, usually one splits the timeline to few places (2 or 3). Managing those splits requires a lot manual interaction (resizing the splits, zooming into the right time resolution, scrolling to the desired range, ...). In contrast this 'sparse' timeline does that all automatically by possibly adding hundreds of those split points (there should be no split bar on the gui). One just has to select POI's with some menu or such. Well and the timeline ruler needs to adapt to it, that might be tricky
-- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]]
ct:: '2008-05-21T13:46:51Z'
--
** Comment: Do you think we could use view splitting to accomplish this? You can see this sort of thing OpenOffice.org calc. Where you drag a splitter out from the ends of the scrollbar, this allows you compare 2 or 4 parts of a big spreadsheet at the same time. Implementing something like that might be reasonably doable. But if you're talking about hiding periods on the timeline, that sounds a lot less easy to me, and it feels like a bit a bit of an odd thing to do. What do you think ct?
+
--
joelholdsworth:: '2008-07-21T21:58:48Z'
--
*** No, view-splitting is something different, usually one splits the timeline to few places (2 or 3). Managing those splits requires a lot manual interaction (resizing the splits, zooming into the right time resolution, scrolling to the desired range, ...). In contrast this 'sparse' timeline does that all automatically by possibly adding hundreds of those split points (there should be no split bar on the gui). One just has to select POI's with some menu or such. Well and the timeline ruler needs to adapt to it, that might be tricky
+
--
ct:: '2008-07-22T07:11:11Z'
--
* "Sparse Timeline" is in Trackview" - see Track view section lower down the page +
This is the kind of features I have suggested in the Trackview section lower down the page. I like the name you give it - "Sparse" because it allows the user to not have to bother viewing OR scrolling past all the stuff in between two end points (or more items) just to tweak the ends of a segment. But I would emphasize that instead of reducing the width of the timeline because of the narrow time span needs for the one task, that more tasks can be carried out in the same view. This is because the view just misses out all the stuff in between, for each task.
+
I am playing around with a few thoughts and maybe might attach an image of how it might work. But in conjunction with "tabbed views" it would result in the convenient ability to display all the work areas in a concentrated display, meaning a whole lot less scrolling around, and clicking to bring windows to the foreground.
-- link:Tree[][[DateTime(2008-05-23T16:59:00NZ)]]
- Comment: See above. With regards to tabbed based UI in the timeline view, I do have this in mind, and it seems reasonably straightforward to allow two tabs which contain views of the same timeline - just scrolled to different places.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
* Clip Mode +
This would be a clone of the clip mode in Apple's iMovie. In this mode, users would be working with discreet (read untrimable) clips. Dragging a new clip into the sequence would cause it to be inserted between two clips, not overwriting them. Once all of the clips are layed out to the users satisfaction, they could then switch to the normal multitrack mode and trim the heads and tails of the clips from there. -- link:rexbron[]
+
The advantage to this sort of work flow is that it allows an editor to very quick create an assembly cut of a film. During this phase of editing, the editor and director are examining the takes and deciding on which ones they like best. As such, it makes sense to be able to easily change the order of clips and add new ones to see how the shots fit together.
--
Tree:: '2008-05-23T16:59:00NZ'
--
- Comment: This sounds a bit odd in some ways. But I'd be interested to find out more. I'll probably do some research into it at some stage. Maybe you can post some screenshots.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
** Comment: See above. With regards to tabbed based UI in the timeline view, I do have this in mind, and it seems reasonably straightforward to allow two tabs which contain views of the same timeline - just scrolled to different places.
+
--
joelholdsworth:: '2008-07-21T21:58:48Z'
--
* Clip Mode
+
This would be a clone of the clip mode in Apple's iMovie. In this mode, users would be working with discreet (read untrimable) clips. Dragging a new clip into the sequence would cause it to be inserted between two clips, not overwriting them. Once all of the clips are layed out to the users satisfaction, they could then switch to the normal multitrack mode and trim the heads and tails of the clips from there.
+
rexbron:: '2008-05'
+
--
* The advantage to this sort of work flow is that it allows an editor to very quick create an assembly cut of a film. During this phase of editing, the editor and director are examining the takes and deciding on which ones they like best. As such, it makes sense to be able to easily change the order of clips and add new ones to see how the shots fit together.
** Comment: This sounds a bit odd in some ways. But I'd be interested to find out more. I'll probably do some research into it at some stage. Maybe you can post some screenshots.
+
--
joelholdsworth:: '2008-07-21T21:58:48Z'
--
--
* I propose an assembly system where the source material is left untouched where effects are added on the fly similar to html and dtp packages. In this system the system is linked together using an node system similar to gstreamer and jack.
- Comment: Yes the core of lumiera will work on a scen graph of connected nodes, and we want to provide the user with a way of using that power. We need to discuss how node wiring and the timeline-track tree go together. Note that node wiring only seems to make good UI when the node graph is fixed for the duration of the whole project timeline. We need to work out how this fits together with the timeline tree, and if metaclips help this problem at all.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
Comment to all those sparse timeline and clip mode proposals: The benefits of those are obvious, as they directly correspond to the working with storyboards. Almost every serious movie uses storyboards to quite some extent. But for the implementation, I'd propose not to see it as an alternative view/mode of the timeline. Rather, I'd treat it like a media/asset folder. Probably we'll have the ability for the user to group the media asset into various "bins" (virtual sub folders). Moreover, pre-cut clips appear as clip assets as well (similar in Cinelerra and most other video editors). Thus, we just need a function to "play" such a clip bin. It could be implemented by defining a ordering on the clips in the bin (from top to bottom and from left to right?). Then, this function would create an transient EDL on-the-fly, containing just these clips, and hand it over to the engine for building/playback. Thus, the user can see his "draft-cut" played back in real time, and thats all what is really needed. When satisfied, he could mark the clips in the bin and drag them to the timeline, which would add them in the same order starting at the current position. I don't think we need to go though all the pain of creating an separate, dedicated UI for this purpose.
-- link:Ichthyostega[] [[DateTime(2008-07-27T23:20:19Z)]]
** Comment: Yes the core of lumiera will work on a scen graph of connected nodes, and we want to provide the user with a way of using that power. We need to discuss how node wiring and the timeline-track tree go together. Note that node wiring only seems to make good UI when the node graph is fixed for the duration of the whole project timeline. We need to work out how this fits together with the timeline tree, and if metaclips help this problem at all.
+
--
joelholdsworth:: '2008-07-21T21:58:48Z'
--
*** Comment to all those sparse timeline and clip mode proposals: The benefits of those are obvious, as they directly correspond to the working with storyboards. Almost every serious movie uses storyboards to quite some extent. But for the implementation, I'd propose not to see it as an alternative view/mode of the timeline. Rather, I'd treat it like a media/asset folder. Probably we'll have the ability for the user to group the media asset into various "bins" (virtual sub folders). Moreover, pre-cut clips appear as clip assets as well (similar in Cinelerra and most other video editors). Thus, we just need a function to "play" such a clip bin. It could be implemented by defining a ordering on the clips in the bin (from top to bottom and from left to right?). Then, this function would create an transient EDL on-the-fly, containing just these clips, and hand it over to the engine for building/playback. Thus, the user can see his "draft-cut" played back in real time, and thats all what is really needed. When satisfied, he could mark the clips in the bin and drag them to the timeline, which would add them in the same order starting at the current position. I don't think we need to go though all the pain of creating an separate, dedicated UI for this purpose.
+
--
Ichthyostega:: '2008-07-27T23:20:19Z'
--
Widgets
@ -182,7 +238,7 @@ Widgets
* Generalized Fader
+
image:images/fader.png[fader.png]
image:{imgg}/mock.Fader-ct2008-02.png[title="fader proposal"]
+
All faders are the same kind of custom widget, that is:
@ -203,43 +259,69 @@ All faders are the same kind of custom widget, that is:
--
+
for the application all faders provide a float (or double) value, nothing else.
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
+
ct:: '2008-02-07T20:42:54Z'
- Comment: I think making some kind standardized fader widget is probably going to be necessary for this project. We need a good way of combining together the artistic "genstural" elements of a slider widget with the precise numerical behavior of an edit widget, and it needs to be compact - the UI will have a lot of these. I'm not sure how often we'll need to see a level meter with these. Most of the time a control is either an input or a readout - very rarely both. Generally speaking I'm against the idea of having a popup menu to configure this widget. I believe that it should be configured to work in a way which is user friendly by default. There may be many of these widgets and asking the user to configure each of these before they behave well seems a bit unfair to me.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
* I agree, the defaults should be reasonable set per-item, that will be that the meter is in most cases off and the spinner will be off on many cases too. I tried to show whats needed for the most generic case with all bells and whistles. When we generalize this we need to support all eventualities even if turned off by default. Note that some things could be done in tooltips, see below "about tooltips and statusbar", the above fader is just an early proposal/brainstorm
-- link:ct[] [[DateTime(2008-07-23T09:41:25Z)]]
joelholdsworth:: '2008-07-21T21:58:48Z'
+
** I agree, the defaults should be reasonable set per-item, that will be that the meter is in most cases off and the spinner will be off on many cases too. I tried to show whats needed for the most generic case with all bells and whistles. When we generalize this we need to support all eventualities even if turned off by default. Note that some things could be done in tooltips, see below "about tooltips and statusbar", the above fader is just an early proposal/brainstorm
+
--
ct:: '2008-07-23T09:41:25Z'
--
--
* Magnifying Glass for the Faders +
Faders should have a "magnifying glass" mode, which can be activated by a key combination or modifier key. When activated, you can fine tune the current value: The step increment is lowered ideally to the real limit of the underlaying parameter, or, if this is too much, at least it should be much smaller than anything you get by dividing the possible value range by the fader length in screen pixels. In this mode, the fader doesn't cover the whole range, rather it is centered at the current value. Changing the value by these small increments should give an obvious visible feedback. Ideally, an accompanying automation curve display will switch to the extreme vertical zoom as well. And it's important that you don't have to zoom, you enter/leave with one keypress.
+
Partially, this is covered by the Adaptive Mouse Wheel too; but, especially when working with sound, the problem is that the parameter range cover several orders of magnitude. For example, even 16bit PCM sound has a volume parameter which can be adjusted in 32768 steps, and yes, there are situations when these fine steps make an audible difference, while most software faders give you not much more then a view hundred subdivisions even under optimal circumstances.
-- link:Ichthyostega[] [[DateTime(2008-02-07T22:34:08Z)]]
- Comment: This is definitely a problem we need a solution to. Is modifier keys the most discoverable way of doing it - I'm not sure. We need ideas for this (see below).
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
- This concept of "magnifying faders", is well explained in http://thorwil.wordpress.com/2007/05/01/fan-sliders/[Thorsten Wilms Fan-sliders Article], the Article also links to an implementation.
-- link:oracle2025[] [[DateTime(2008-02-08T00:40:05Z)]]
- Comment: In one sense this is bad because it's so incredibly non-standard. Bun in other ways it seems to me like a rather ingenious solution to the problem. Aparently Ardour has these. I must investigate.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
Ichthyostega:: '2008-02-07T22:34:08Z'
--
** Comment: This is definitely a problem we need a solution to. Is modifier keys the most discoverable way of doing it - I'm not sure. We need ideas for this (see below).
+
--
joelholdsworth:: '2008-07-21T21:58:48Z'
--
+
*** This concept of "magnifying faders", is well explained in https://thorwil.wordpress.com/2007/05/01/fan-sliders/[Thorsten Wilms Fan-sliders Article], the Article also links to an implementation.
+
--
oracle2025:: '2008-02-08T00:40:05Z'
--
+
**** Comment: In one sense this is bad because it's so incredibly non-standard. Bun in other ways it seems to me like a rather ingenious solution to the problem. Aparently Ardour has these. I must investigate.
+
--
joelholdsworth:: '2008-07-21T21:58:48Z'
--
Scripting
^^^^^^^^^
* Usability (ease of use) - mouse clicks and motions, inputs decisions, etc required to achieve tasks. Macros are really handy for allowing the user to speed up repetitive tasks that the program designers have not anticipated and made easy to do from the outset. Macros can be shared on a central web site. Plus developers can look and see what the macros are being used for, as this gives a very important indication of where vital tasks are.
-- link:Tree[][[DateTime(2008-05-07T16:44:00NZ)]]
+
--
Tree:: '2008-05-07T16:44:00NZ'
--
- Comment: We need to have some discussion about scripting. To do macro scripting we'll need to implement a DOM interfaces etc. into 2 or even all 3 layers of the system. If we want to do this, then we'll need to begin planning for it early. We have talked already about making scripting the movie itself AviSynth style. Both are worth talking about.
-- link:JoelHoldsworth[] [[DateTime(2008-07-22T21:58:22Z)]]
+
- See also rcbarnes compound filters proposal.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:25:57Z)]]
--
JoelHoldsworth:: '2008-07-22T21:58:22Z'
--
** See also rcbarnes compound filters proposal.
+
--
JoelHoldsworth:: '2008-07-24T16:25:57Z'
--
Others
@ -247,10 +329,14 @@ Others
* Time estimates for lengthy Tasks before committing to the action. +
Handy to have time estimates for lengthy task indicated even before committing to the task. Also an estimate for the % increase or reduction in time of adjusting parameters. So you can make a good tradeoff between the result and and the time taken to get it. When a task is carried out, measurements are made to improve the accuracy of future guesses.
--link:Tree[][[DateTime(2008-05-07T21:34:00NZ)]]
+
Tree:: '2008-05-07T21:34:00NZ'
- Comment: This would be quite a nice feature if we can do it. Though it's often hard to know how long something will take until you start doing it. For example estimating the time to render a 1000 frame animation might involve rendering the first 10 frames, then multiplying that time by 100. Problem is that could potentially be quite complex to set up - especially when we're working with render farms. The backend guys would need to think about this I think.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:24:50Z)]]
+
--
JoelHoldsworth:: '2008-07-24T16:24:50Z'
--
Joelholdsworth is Skeptical
@ -258,40 +344,58 @@ Joelholdsworth is Skeptical
* Multi server +
Display GUI components on different Xservers, some critical components (GL rendering etc) might be only supported on local displays
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
+
ct:: '2008-02-07T20:42:54Z'
- Comment: This doesn't seem like a very common use case. I can't see any immediate advantage in doing this, and I'm struggling to think of a scenario where this would be helpful.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
* Having more than one workstation each driving a display on its own, getting more bang. But I agree this is not a important feature and rather a corner case.
-- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]]
joelholdsworth:: '2008-07-21T21:58:48Z'
+
** Having more than one workstation each driving a display on its own, getting more bang. But I agree this is not a important feature and rather a corner case.
+
--
ct:: '2008-07-22T07:11:11Z'
--
--
* 3x3 Menus +
Have a mostly quadratic 3x3 dialpad like popup menu poping up so that the center is the mouse position (adjusted when near screen corners). The middle field is always the close/cancel functionality and the 8 fields around offer the menu entries. Navigation can be done by mouse, cursor keys or numpad! Menu entries can open 3x3 submenus again, either incremental so that closing brings you up to the higher menu or exclusive that closing aborts the whole menu.
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
+
ct:: '2008-02-07T20:42:54Z'
- Comment: Cehteh really want this feature. Personally I'm skeptical. It seems clumsy and non-standard to me, and not good in terms of command discoverability, so I don't want to implement it. But then he does seem to want it pretty badly, so I'm a bit cautious about putting it straight in the "Won't Implement" category.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
* not only me, but ichthyo and simav too and anyone i talked with liked this idea but you
-- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]]
joelholdsworth:: '2008-07-21T21:58:48Z'
+
** not only me, but ichthyo and simav too and anyone i talked with liked this idea but you
+
--
ct:: '2008-07-22T07:11:11Z'
--
--
* User Precautions get built out of user interface and into program.+
* User Precautions get built out of user interface and into program.
+
When attaching such and such effect to a track, disable "play" before attaching it, then re-enable play aft attaching it. (we don't tell you this before hand, and we never will, unless you ask the question and search the net, then you might find out in the "secrets manual", And you'll have to remember this (always)!! If there are circumstances that apply to an effect (or for that matter any other part of the program), then the feature could have a flag in it that warns the system to take note of it, and it then reports what its requirement or tweak feature is, so the system can automatically handle it the best way. (A sort of OO process handler). This not only saves potential lengthy wastes of time, but saves concentration on sideline issues, speeds up work, adds to reliability and good time user experience.
--link:Tree[][[DateTime(2008-05-07T21:34:00NZ)]]
+
Tree:: '2008-05-07T21:34:00NZ'
- Comment: I'm not sure I quite understand what this is about. Your explanation is a bit hard to read.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:24:50Z)]]
+
--
* I wouldn't even be skeptical, I am against such a proposal. Any feature we add should just work, without crashing the application and trashing the users efforts. If a feature doesn't work, it needs to be fixed, instead of automatically warning the user that this feature is broken. The fact that for Cinelerra you need the "secrets" tells quite a lot about the state of affairs regarding Cinelerra, and because we wanted to change this, Lumiera was born. ;-)
-- link:Ichthyostega[] [[DateTime(2008-07-27T23:04:42Z)]]
--
JoelHoldsworth:: '2008-07-24T16:24:50Z'
+
** I wouldn't even be skeptical, I am against such a proposal. Any feature we add should just work, without crashing the application and trashing the users efforts. If a feature doesn't work, it needs to be fixed, instead of automatically warning the user that this feature is broken. The fact that for Cinelerra you need the "secrets" tells quite a lot about the state of affairs regarding Cinelerra, and because we wanted to change this, Lumiera was born. ;-)
+
--
Ichthyostega:: '2008-07-27T23:04:42Z'
--
--
May Implement Some Day
~~~~~~~~~~~~~~~~~~~~~~
@ -299,14 +403,19 @@ May Implement Some Day
* Widget overlay/Fullscreen +
Some Widgets can be made half transparent and overlay video giving a head up display editing while the video is at native resolution in background.
Window configurations can be stored/restored in customizable presets and are part of the project (see blender again)
-- link:ct[] [[DateTime(2008-02-07T20:42:54Z)]]
+
ct:: '2008-02-07T20:42:54Z'
- Comment: This is difficult to do. XVideo and Gtk don't really mix. But I can't think of any controls that need to be overlaid.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
* Would be nice but not a primary feature. I'd rather think about some some special on-screen-menu overlay, not necessary gtk (libosd?) maybe this can be implemented with OpenGL overlay or so. As noted before, having a monitor which runs on the native Video resolution is a requirement. Giving this Monitor some (limited) GUI features, like mask editing or other simple manipulations gains extra points. Not a primary/important feature but I'd rather like it seen as "Will implement _someday_" The window configuration customization should be its own point, I think thats easy with GTK (Gimp does that) adding a small Configuration management GUI shouldn't be hard.
-- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]]
joelholdsworth:: '2008-07-21T21:58:48Z'
* Would be nice but not a primary feature. I'd rather think about some some special on-screen-menu overlay, not necessary gtk (libosd?) maybe this can be implemented with OpenGL overlay or so. As noted before, having a monitor which runs on the native Video resolution is a requirement. Giving this Monitor some (limited) GUI features, like mask editing or other simple manipulations gains extra points. Not a primary/important feature but I'd rather like it seen as "Will implement _someday_" The window configuration customization should be its own point, I think thats easy with GTK (Gimp does that) adding a small Configuration management GUI shouldn't be hard.
+
--
ct:: '2008-07-22T07:11:11Z'
--
--

162
doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt
View file

@ -7,14 +7,24 @@ GuiBrainstorming Reviewed - Won't Implement
Sometimes help files and tutorials are improvable. Keeping track of which help is to which amount useful for a majority of users will provide data about which help files are improvable. It will also provide data about which features most often users use help and might be candidate for usability consideration. like: []solved my problem []got me on the right way []needed to find help elsewhere []problem not solved
- This is surprisingly hard to implement (I think), and in a sense it's already obvious to us whether the docs are quality - filled with nice graphics, simple steps, and lots of clear information or whether they need improvement. This feature might have some use on the website.
-- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:47:35Z)]]
+
--
JoelHoldsworth:: '2008-07-23T20:47:35Z'
--
* Suggest an improvement Feature - for users to help improvement +
Just like the "Help" feature suggested elsewhere, in which the user can edit the help file as they go, so could the user be able to make suggestions to improve the program. Able to get a panel or window grab, and draw arrows lines to show "where" they are talking about. Online linking - There could also be the facility to click on an email link to send a request for help (want to engage in dialog, rather than just notify - without need for response). Or a relevant search is automatically generated for the forum, chat room, faqs, helpdesk, documentation. Or get sent to a link:BrainStorming[] page like this one (specifically for the panel they were in).
-- link:Tree[][[DateTime(2008-05-26T12:01:00NZ)]]
Just like the "Help" feature suggested elsewhere, in which the user can edit the help file as they go, so could the user be able to make suggestions to improve the program. Able to get a panel or window grab, and draw arrows lines to show "where" they are talking about. Online linking - There could also be the facility to click on an email link to send a request for help (want to engage in dialog, rather than just notify - without need for response). Or a relevant search is automatically generated for the forum, chat room, faqs, helpdesk, documentation.
Or get sent to a ``BrainStorming'' page like this one (but marked specifically for the panel they were in).
+
--
Tree:: '2008-05-26T12:01:00NZ'
--
- This isn't really a GUI issue - much of this is more for the website, which the GUI will probably link to from an item in the help menu.
-- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:45:00Z)]]
+
--
JoelHoldsworth:: '2008-07-23T20:45:00Z'
--
* Help System - rolling tips and tutorials +
Sometimes, when a beginner is using the program, they just sit back and look at the general picture. It's a behaviour that gets down naturally. It looks like a "break", but going through their minds are questions like ; "Am I doing this efficiently?", "What would make this easier, and is there already an easy way to do it in the program?", "How long do I think this will take, and what can I do to make it in time?", and much more. Sit back, look at the whole screen, maybe cruise around the menu, conceptualise the project and steps involved - it's a kind of task oriented learning - on the job (self) training.
@ -26,66 +36,117 @@ Because of the creative effort needed when composing video projects, there is qu
If it was context sensitive, then it would provide relevant information, similar to having a tutor or an expert leaning over your shoulder, explaining further possibilities and applications.
+
Video tips and Tutorials could be available via Youtube, which also doubles as promotion for the project. Users could choose to download groups of videos on selected topics.
-- link:Tree[][[DateTime(2008-06-11T17:04:00NZ)]]
+
--
Tree:: '2008-06-11T17:04:00NZ'
--
- If the user stops to thing I think we should give them some peace while they get their thoughts together. I'm sure if they want help they'll ask for it. Remember how annoying Clippy was in MS Office? :-P
-- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:45:00Z)]]
+
--
JoelHoldsworth:: '2008-07-23T20:45:00Z'
--
* Help and visual prompts use GIFs for visual cue as to time behaviour of feature. +
Icons are handy when they portray some sort of cue for the task that they do. A number of tasks in video editing are time related. It would be handy to have some form of visual que as to what the time related task does. Since Gifs can show motion, they would be very good for this task. PNGs could also do it it they were timed to cycle through their images. Example uses would be to show the difference between "track" and "stabilise" in motion tracker - a strip showing a pogo stick going along a footpath would be suitable to show the differences between track and stabilise (and could also be used to show the differences between the forms of vector calculation. GIFs could also be used to show editing functions that involve several important steps.
--link:Tree[][[DateTime(2008-05-26T08:45:00NZ)]]
+
--
Tree:: '2008-05-26T08:45:00NZ'
--
- If we did want animated icons we'd be better off with MNG or a PNG image strip because then we'd get transparency. There are 2 reasons why I think this is a bad idea. 1. There's an aweful lot of drawing to be done. We already need to produce perhaps 100 high quality tango style icons for the user interface. If they're animate someone would have to draw 1000s of these, with all the quality control problems that go with it. 2. I'm not sure it's something people will find very helpful. Even if the animation only begins when we hover over the icon, it could even be quite annoying and distracting.
-- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:39:36Z)]]
+
--
JoelHoldsworth:: '2008-07-23T20:39:36Z'
--
* Help System - available for user improvement +
_Similar to tool tip and status bar suggestion above._ A *"hover" hint / help* facility would be a major bonus. Just make the function available, the box can start with an index number, and users can type in their own help comments (either in a *help text entry management* section, or directly into the pop-up hover box - in optional help edit mode).
+
These can be pooled at a central web site in to languages, and brevity/completeness (options to links to further help, links to examples, links to video tutorials). So the developers do not have to spend time writing help files - just make it possible for the users to. The developers might like to add a few comments to the verbose files at some later point, or clear up inaccuracies. translators can also do the work for other languages. Very quickly the supporting documentation's usefulness would add to the attractiveness of the program.
-- link:Tree[][[DateTime(2008-05-07T16:44:00NZ)]]
+
--
Tree:: '2008-05-07T16:44:00NZ'
--
- A wiki style approach is often an effective way to get community input on documentation. This may be a good way to get people working on it. But it's best for us to publish a tidied up documentation set and ship that, instead of creating a complex editable help system - which is vulnerable to vandalism.
-- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:29:25Z)]]
+
--
JoelHoldsworth:: '2008-07-23T20:29:25Z'
--
* User selectable Experience Level - Task Oriented Layout +
The user could be asked to choose their experience level, and more complex options then get greyed out. The user could be asked the common tasks that the want to do, and other options could be greyed out. They can choose whether they want "grayed" out options to be available, or viewable, or not. The options which are advanced (or 2 levels greater than their current expertise level) could be "dark grayed" out and the user could have similar choices about their display).
--link:Tree[][[DateTime(2008-05-09T20:50:00NZ)]]
+
--
Tree:: '2008-05-09T20:50:00NZ'
--
- Comments: I can't see any good reason for this. The user interface ought to be usable for everyone. The problem is that we want to enable everyone to be an "expert" by making power intuitively available even to beginners. The other problems is that light users might use only 10% of the functionality - but different light users use a different 10% from each other. So hiding things doesn't actually help make things simpler. It's much better to have things tidily arranged with clear descriptions etc. to help the user understand what a command might do - rather than hiding the command from them.
-- link:JoelHoldsworth[] [[DateTime(2008-07-22T22:25:58Z)]]
+
--
JoelHoldsworth:: '2008-07-22T22:25:58Z'
--
* SVG-based GUI elements (buttons and chevrons) could allow for easy GUI skinning and function calls since one would just have to mod an xml file to create new skins. It also means you could use code from the Webkit project for rendering the interface maybe. My practical reasoning is that if the devs wanted to work on the refining cinelerra/lumeira core technology or add plug-ins to extend its functionality, adding the GUI elements of those plug-ins might be less of a chore. It also may be a practical image format for a node-based compositing interface(if desired) because it supports embedded grouping of vector expressions. It could also be used as the basis for drawing things like masks and vector objects in the compisitor and the xml vector-values of those drawn objects could be communicated back to the programs core for updating events. (Similar to the way some more popular editor/compositors use PostScript to draw objects and place values.) It also the SVG spec supports transparency bluring and the ability to interpolate these events over time...things that can be incorperated into program beyond the the gui. Sorry for the long post...felt I needed to explain my reasoning better.
-- jb [[DateTime(2008-07-21T21:58:48Z)]]
-- jb '2008-07-21T21:58:48Z'
- Comment: I am hoping that we can implement a simple set of skins for Lumiera. But we will be using the GTK based styles system, which is the standard. This allows theming to be done with a simple script file. These styles files are the more natural choice for UI theming, because WebKit is designed primarily for web, and would add a lot of unnecessary bloat to the app. Icons will be drawn as SVGs; a good choice for drawing the graphics, but these will be prerendered into PNGs at compile time as is standard practice for most free-desktop apps.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
joelholdsworth:: '2008-07-21T21:58:48Z'
--
* Client / Server Model +
The server process will act as the master coordinator for the system, and will accept input from multiple GUI clients, and dictate tasks to multiple slave processes (even on separate physical servers). The GUI client application could be multi-platform. File transfer and communication could take place over SSH and make use of SVN for project management. Proxy editing will be the norm, due to the higher resolutions of final videos (the RED Epic will handle 5K). The entire system could easily work on a single Linux workstation, for easy adaptibility from handling home videos to expand to editing cinema films (which could benefit from dedicated GUIs to handle video, sound, etc.).
- Comment: Because the different parts of a project are so tightly integrated, it won't be possible to have one instance of the GUI that only has audio, and another that only does video etc. Moreover, the controller PC will hold the source video data. It is true that we plan to make a distributed backend, but the core and GUI layers will remain on the controller PC. It's very hard to make a distributed GUI, and even harder to make lumiera have both a distributed front and backend.
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
joelholdsworth:: '2008-07-21T21:58:48Z'
--
* Navigation Systems +
There may be several methods to make menu selections, and other choices. The Gui could be made quite adaptable/customisable. Using a "skin" approach to the Gui, would provide a system for users who are not programmers, to help develop improved user interfaces. Mouse "gestures" (may be patent considerations) are another option. The way that options are communicated with the program functions could be made so that even as yet undesigned "user chooser systems" can be added.
-- link:Tree[] [[DateTime(2008-05-14T08:40:00NZ)]]
- Comment: Allowing customization is good in some ways. But every customization has a cost; in terms of development effort, debugging, maintenance, user support etc. so one must weight up the cost/benefit of allowing the user to reprogram the UI. IMO it's better for the UI to be right rather than to allow the user to reprogram it. If there's something sub-optimal about the UI then it should be fixed - for everyone. So we should be encouraging users with programming skills to contribute the code to us rather than them all making their own little customizations for themselves. That way lumiera becomes better for everyone!
-- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+
--
* I completely agree, while I have to add that we can't know about all possible workflow scenarios. In sense of workflow Lumiera should be customizeable/scriptable somehow. This might be more intrusive/costly than just customizing a theme but should be less than hacking in the C++ source and have to o recompile.
-- link:ct[] [[DateTime(2008-07-22T07:11:11Z)]]
Tree:: '2008-05-14T08:40:00NZ'
--
** Comment: Allowing customization is good in some ways. But every customization has a cost; in terms of development effort, debugging, maintenance, user support etc. so one must weight up the cost/benefit of allowing the user to reprogram the UI. IMO it's better for the UI to be right rather than to allow the user to reprogram it. If there's something sub-optimal about the UI then it should be fixed - for everyone. So we should be encouraging users with programming skills to contribute the code to us rather than them all making their own little customizations for themselves. That way lumiera becomes better for everyone!
+
--
joelholdsworth:: '2008-07-21T21:58:48Z'
--
*** I completely agree, while I have to add that we can't know about all possible workflow scenarios. In sense of workflow Lumiera should be customizeable/scriptable somehow. This might be more intrusive/costly than just customizing a theme but should be less than hacking in the C++ source and have to o recompile.
+
--
ct:: '2008-07-22T07:11:11Z'
--
* Burst frames to graphics card. +
I am not sure how the current video play system works, but speed might be increased if several frames got sent to the video card at once. The video card can act as a video cache and play them as required. The number of interrupts to the process is reduced, to much less than one per frame, freeing up more CPU time for calculating the effects etc..
--link:Tree[][[DateTime(2008-07-18T18:18:00NZ)]].
+
--
Tree:: '2008-07-18T18:18:00NZ'
--
- Comment: Good idea, but not really necessarily. Firstly because XVideo is pretty fast, and the bottle neck is in rendering not drawing. Second, we can't get direct access to video RAM anyway because X abstracts it away.
-- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]]
+
--
joelholdsworth:: '2008-07-19T19:42:04Z'
--
* GUI development - flexible approach - using "Skin Methods" +
* GUI development
+
--
- flexible approach
- using "Skin Methods"
--
+
In developing a GUI, the approach would normally be for the developers to design the Gui as the project progresses, and it comes out at the end. This is not bad, especially as there is a GUI to be had. But if there is a desire (which there appears to be a healthy desire here) to try new things, and look at options, then it would be quite useful to have a development method that allows for experimentation with options, side by side comparisons and assessments. Assessments by users and developers.
+
GUI design could be available for release for whoever wants to do a spin-off project re-GUI. So a GUI gets made by default by the development team, but the _skin kit_, and _methods of activating/interaction with the "engine"_ are made available. Users can then run their own tests and some sort of concensus arrived at later as to what is considered to work well, in what sorts of different user situations (newbie, small, large/expert).
@ -93,10 +154,16 @@ GUI design could be available for release for whoever wants to do a spin-off pro
If there is vibrant enthusiasm for teams to work on alternative GUIs, then the developers may even avoid the need to do much of the work on GUI, and just announce what the interface requirements are - the (choices of) GUIs for some sections could be ready before the program is finished. The GUIs could be developed and discussed concurrently (or advance of) the respective program code. On the other hand the GUIs could lag behind the developemnt of the engine, but not hold the engine up. Some GUI groups could be ahead of others in some parts of the program and behind in others - the user could even choose to the GUI (widget appearance) from one theme for one part of the interface, and GUI from another theme for other parts.
+
There could be agreement between GUI teams working on different themes, to cover separate parts of the interface first, so that there is at least some type of theme for the GUI for the whole program ASAP.
--link:Tree[] [[DateTime(2008-06-05T20:33:00NZ)]]
+
--
Tree:: '2008-06-05T20:33:00NZ'
--
- Comment: To achieve that sort of thing one would normally expect the project to be forked. If our architecture is any good (and I think it will be), then a Lumiera fork would have no problem attaching a different UI to the system because there will be clear separation between the layers. But I can't see any good reason to help people fragment the project. If there are problems with the standard UI then we should fix them for everyone. If people want to write code for better UI they should contribute it patches. We really don't want to encourage people to fork any part of Lumiera.
-- link:JoelHoldsworth[] [[DateTime(2008-07-22T20:56:07Z)]]
+
--
JoelHoldsworth:: '2008-07-22T20:56:07Z'
--
* About Tooltips and Statusbar +
Tooltips are really valuable items, they should not be wasted for simple things like brief help texts. Instead they might display the actual state of the underlying widget in a textual form (numeric+unit) with _maybe_ some hints. Long time ago I proposed for Cinelerra to add a special mode to make tooltips editable, that is with a shortcut the actual tooltip becomes a small text input field where the user can enter exact values for some things, this value is committed with the return key and leaving this mode should be really easy (as simple as just moving the mouse, ESC key).
@ -104,17 +171,26 @@ Tooltips are really valuable items, they should not be wasted for simple things
The Status bar can show more information but isn't directly in the users view, here we may play help infos like available options on the mouse buttons, important keyboard shortcuts etc. take a look at \'qcad' .. xfig has also static area where it shows available (mouse) options, just not a status bar but in the upper right of the screen.
+
This might be a bit different to some common other user interfaces (M$...) but I think this is much more valuable.
-- link:ct[] [[DateTime(2008-04-08T01:26:06Z)]]
- Comment:The thing about tooltips is that one usually uses them to aid the user in figuring out what a toolbar button (which would otherwise be a crytic icon bitmap) actually does - and so in this sense they're not a waste - they help users figure out how the application works. Users expect to find those hints in tooltips, and so it's rather unkind to the user to do something different and unexpected, and so we should avoid breaking the norms if we can. The actual state of the widget should be visible to see straight off and editing that value should be allowed straight off. That functionality should not be hidden inside a tooltips. People will find it really counter-intuitive to have to edit a value inside a tooltip in order to make a change.
-- link:JoelHoldsworth[] [[DateTime(2008-07-22T21:42:32Z)]]
+
--
* My argument is, that the \'figure out' thing could be done in the status bar, thats slightly less convinient but a user who searches for help will discover it (xfig, qcad and other programs do such kinds of dedicated help places instead tooltips). Popping up Tooltips only help _very_ early beginners, for someone who is even marginally used to the programm they don't add any value anymore, yet to be at a very prominent screenspace, right at your cursor. I think thats really a waste. I want interactive tips and help, but please where they are disciverable for help, but don't waste screen estate with information one might not really need. In contrast, the numeric value of a fader is a very important thing to know, at least when you want to alter it (cinelerra does that with its round knobs). And having a direct enter mode would be even more powerful for experienced users while not disturb anyone else. This might only complement the 'generalized fader' fader above, means when the fader is configured to show only a small scroller entry (to safe screen space) then displaying the numeric value and/or offer to edit it in a tooltip would be a good way to make it precise, without needing to reconfigure the fader, taking more screen space.
-- link:ct[] [[DateTime(2008-07-23T09:41:25Z)]]
ct:: '2008-04-08T01:26:06Z'
--
* Default settings after install set to most reliable and least requirements +
** Comment:The thing about tooltips is that one usually uses them to aid the user in figuring out what a toolbar button (which would otherwise be a crytic icon bitmap) actually does - and so in this sense they're not a waste - they help users figure out how the application works. Users expect to find those hints in tooltips, and so it's rather unkind to the user to do something different and unexpected, and so we should avoid breaking the norms if we can. The actual state of the widget should be visible to see straight off and editing that value should be allowed straight off. That functionality should not be hidden inside a tooltips. People will find it really counter-intuitive to have to edit a value inside a tooltip in order to make a change.
+
--
JoelHoldsworth:: '2008-07-22T21:42:32Z'
--
*** My argument is, that the ``figure out'' thing could be done in the status bar, thats slightly less convinient but a user who searches for help will discover it (xfig, qcad and other programs do such kinds of dedicated help places instead tooltips). Popping up Tooltips only help _very_ early beginners, for someone who is even marginally used to the programm they don't add any value anymore, yet to be at a very prominent screenspace, right at your cursor. I think thats really a waste. I want interactive tips and help, but please where they are disciverable for help, but don't waste screen estate with information one might not really need. In contrast, the numeric value of a fader is a very important thing to know, at least when you want to alter it (cinelerra does that with its round knobs). And having a direct enter mode would be even more powerful for experienced users while not disturb anyone else. This might only complement the 'generalized fader' fader above, means when the fader is configured to show only a small scroller entry (to safe screen space) then displaying the numeric value and/or offer to edit it in a tooltip would be a good way to make it precise, without needing to reconfigure the fader, taking more screen space.
+
--
ct:: '2008-07-23T09:41:25Z'
--
* Default settings after install set to most reliable and least requirements
+
The program may be tweaked to get performance on PC with great graphics systems, plenty of Ram and good hard drive speed. For people with lower spec'd gear, there may be some tuning needed, just to get going. There is the likelihood that people with low spec'd gear are not so able or inclined to read up on their hardware, and "search" for help on their video editor, to find out the solution to a problem (which they may not even have much idea of what the problem is). Consequently, they are likely to give up and not use the program.
+
Everybody enjoys a program that can be easily installed, and is ready to run. Few are upset by a program that is easy to install, setup, and is ready to run. But quite a few have nothing but disappointment with a program that is relatively easy to install, no idea how to set up, won't run or crashes, and not much clue about where to get help which is much further away than a click.
@ -132,16 +208,28 @@ A similar colour coding for speed could be used ; blue for low speed, green for
This colour coding for the two parameters (reliability and speed) means that when new driver/setup options are available that provide a speed increase, (yet are unreliable or unknown reliability at the time), the user has a very easy visual prompt to help them make decisions, and adapt their trial and error path to optimisation.
+
Feature to save different hardware settings, with notes in the hardware specs, and share them. Upload to Lumiera web site, so that better first guesses for new users are available. And if an intelligent system is used for hardware detection in future, then the information for best choices will already be available.
-- link:Tree[] [[DateTime(2008-05-28T09:41:00NZ)]]
+
--
Tree:: '2008-05-28T09:41:00NZ'
--
- Comment: The problem is that unlike games, in movie editors there isn't very much that can be done in the way of tweaking. With video editing, by and large there are no shortcuts. So the calculations that must take place to render a video on a Quad Core workstation are the same as the ones that need to happen on an EeePC. Lumiera needs to be intelligent about how much RAM it uses etc. but that sort of thing ought to be automatic. The only thing that this could apply to is reduced quality previews, which I've put in the blueprint list.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:34:20Z)]]
+
--
JoelHoldsworth:: '2008-07-24T16:34:20Z'
--
* Menu Bar disconnectable from track view +
The menu bar could be made disconnected from the track view. This would allow the track view to be covered by a window, but the menu still kept on top. The menu bar could by default start at the top left and run across the screen. It could remain on top view. It could include easy single click tabs to jump from one window view to another.
+
The menu items that are specific to track view could be separated out and left as dedicated menu attached to the top of the track view.
-- link:Tree[][[DateTime(2008-05-07T21:06:00NZ)]]
+
--
Tree:: '2008-05-07T21:06:00NZ'
--
- Comment: Actually if you look at the state-of-ui you can see that the menu bar will be shown at the top of workspace. We might make it detachable, but actually it's not very useful to be able to attach the menu bar to the sides or bottoms of windows.
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:47:08Z)]]
+
--
JoelHoldsworth:: '2008-07-24T16:47:08Z'
--

2
doc/design/gui/GuiDiscussion/MenuAndShortcuts.txt → doc/design/gui/GuiDiscussion/PieMenu.txt
View file

@ -4,7 +4,7 @@ Menu and Shortcuts
:Date: 2008-05-14
link:Lumiera/GuiBrainstorming/MenuAndShortcuts[] should explain most heavily discussed GUI features being related to Lumiera's GUI.
This pace is a place where to discuss some of the more controversial GUI features proposed for Lumiera's GUI.
3x3 Menus, Version 1

0
doc/design/gui/GuiDiscussion/scrolling.txt → doc/design/gui/GuiDiscussion/Scrolling.txt
View file

26
doc/design/gui/GuiDiscussion/TimelineDiscussion.txt → doc/design/gui/GuiDiscussion/Timeline.txt
View file

@ -1,15 +1,19 @@
Timeline: Discussion
====================
Timeline: Extended Discussion
=============================
:Author: Joel Holdsworth
:Date: Fall 2008
This is Joel Holdsworth's attempt to amalgamate all the ideas from all the brainstorming to one consistent idea that makes sense, can be implemented, and seems like it would be nice to use. Comments are welcome.
This is Joel Holdsworth's attempt to amalgamate all the ideas from all the brainstorming
to one consistent idea that makes sense, can be implemented, and seems like it would be nice to use.
Comments are welcome.
* Avid vs FCP 2006 - http://www.fini.tv/articles/avidfcp2006.html[]
Archived 2008 from https://web.archive.org/web/20071211184722/http://www.fini.tv/articles/avidfcp2006.html[fini.tv]
* Final Cut Pro 5 - A First Look - http://www.kenstone.net/fcp_homepage/fcp_5_new_martin.html[]
* SpeedEdit Tutorials - http://www.newtek.com/speededit/tutorials/index.php[]
* SpeedEdit Tutorials +
'http://www.newtek.com/speededit/tutorials/index.php' ~[red]#dead link#~
Brainstorming
@ -220,14 +224,14 @@ Christian asked "why then not also controlling plugin parameters by placement?".
I must admit, both of you have a point. Christians proposal goes even beyond
what I proposed. It is completely straight forward when considered structurally,
but it is also clearly beyond the meaning of the term/idea/concept "placement".
But what, if we re-adjust the concepts and think in terms of ''Advice'' ?
But what, if we re-adjust the concepts and think in terms of _Advice_ ?
Thus, a placement would bind an media object into the session/sequence and also attach additional advice?
As an example, to apply this re-adjusted Idea to the gain control: When a track
group head has an gain/fade control this would just denote an advice to set the
gain. It does ''not'' mean that signal data has to flow "through" this
track/track group, it does ''not'' mean the gain is actually applied at this
point and it does ''not'' mean that any routing decision is tied to this gain.
gain. It does _not_ mean that signal data has to flow "through" this
track/track group, it does _not_ mean the gain is actually applied at this
point and it does _not_ mean that any routing decision is tied to this gain.
Even signal chains being routed to quite different master busses can receive
this advice, given the source clips are placed within the scope of this track
group. The only difference needed on the GUI to implement this approach would be
@ -292,7 +296,7 @@ otherwise just normal effects in a master sequence)?
Regarding effects, I should point out that in our concept, mask, "camera" and
"projector" (Cinelerra's terms) are just some specific effects. Given that, it
is clear that effects need to be applicable ''both'' pre transition and post
is clear that effects need to be applicable _both_ pre transition and post
transition. But the following limitation seems reasonable to me and seems to
match the actual use:
@ -312,14 +316,14 @@ Btw. I very much agree with you that putting clips on group head tracks would be
rather confusing, while I think placing an effect at a group head track is OK
and feels natural. It will just be applied post-transition to all media within
the covered range. And, note again the power of the placement+advice concept:
this does ''not'' mean the data need to be merged together and piped through the
this does _not_ mean the data need to be merged together and piped through the
effect at this point. Rather, it means that each signal processing chain in the
covered range will get an instance of this plugin wired in at a position
equivalent to the place the effect is found on the group track with respect to
the track hierarchy. I.e. after wiring in the transition(s), instances for
effects placed at tracks are wired in order and ascending the track tree, and
finally the connection will be made to the mixing step or output destination
according to the output advice found for ''this individual'' object (but in most
according to the output advice found for _this individual_ object (but in most
cases this output destination advice will be inherited from the context, i.e.
some root track)

50
doc/design/gui/GuiDiscussion/Workspaces.txt
View file

@ -7,7 +7,7 @@ Workspaces
After some debate on IRC last night, it emerged that there are some differing ideas about how projects, sessions, panels and main-windows should work together, and it seems that there are different paradigms for workspaces.
I have my personal preferences, but my thinking is definitely incomplete - I don't think any of us have yet groked all the ramifications of the different ideas, so I'm hoping this will help us elucidate the differences.
I have my personal preferences, but my thinking is definitely incomplete -- I don't think any of us have yet groked all the ramifications of the different ideas, so I'm hoping this will help us elucidate the differences.
Paradigm 1: Super-IDE Style
@ -18,7 +18,7 @@ The end result would be like getting multiple Xnests of Ion, and bear some simil
This would make sense if the normal workflow would involves many projects, and a lot of inter-project work.
There are some plusses:
There are some pluses:
* It's very orthogonal, and it lets the user configure their window layout to be exactly what they want. Lots of flexibility.
@ -48,7 +48,7 @@ joelholdsworths's Conclusion
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I favour this paradigm #2. The freedom from paradigm #1 enables some extra possibilities for window arrangement, but at the cost of a lot of extra complexity, and at the cost of allowing some pretty ugly configurations that both the programmer and the user would rather not have to think about. It seems to me that if you're doing a lot of inter-project work, you can drag windows into a formation - that's pretty normal for this rare case.
I wonder what the proffessional video editors think. Please leave comments.
I wonder what the professional video editors think. Please leave comments.
@ -57,48 +57,64 @@ Comments
--------
Basically I agree/you convinced me with #2, Initially I was more after #1 but you pointed out some problems. But still
I would like to make some execptions from the rule, because I see viable use-cases.
I would like to make some exceptions from the rule, because I see viable use-cases.
As you suggest, a window is related to a project, I would like to have a \'import' feature there where one can
include/dock a component from another project. This then becomes a \'real' import which means the first project notes
"display the timeline of project 2 in my window". This gives clean semantics for working with projects and windows and
gives a clean abstraction of an \'import' we can even store in the session down. This imported components are then not
part of project 2's session. Usecases are side by side comparsion and work on 2 or more pojects, arrange timelines for
easier drag and drop operations, make this config a project setting (you dont have to open all dependent projects and
part of project 2's session. Use-cases are side by side comparison and work on 2 or more projects, arrange timelines for
easier drag and drop operations, make this config a project setting (you don't have to open all dependent projects and
arrange a multitude of windows). Prolly the same (to a lesser extent) counts for importing the \'resources' of another
project (hey have you thought about some collection of boilerplace footage, logos, intro sequence etc as clips stored
in a site-wide project withot timeline, but then you have all your production companies \'default' resources at
in a site-wide project without timeline, but then you have all your production companies \'default' resources at
hand?). Next sharing viewers in one window, possible fullscreen on a 2nd monitor then you can have a 2x2 tiling or
such for all kinds of previews, even external projects. +
-- link:ct[] [[DateTime(2009-01-29T03:03:22Z)]]
ct:: '2009-01-29T03:03:22Z'
- Agreed. A nice "include" feature, so one project could refer to another would cover most of what you could
imagine to do with multiple projects +
-- link:Ichthyostega[] [[DateTime(2009-01-29T03:36:08Z)]]
+
Ichthyostega:: '2009-01-29T03:36:08Z'
Ah just to have it noted, I told that often on irc: Dock windows shall not be a second class citizen. You mentioned
that you want one able to open more windows for a project, undocking a pane shall just do that too. All windows can
then be treated equal, can have a (toggleable) menu, toolbar and statusbar etc. Especially when working with big
and/or multiple monitors it becomes really ugly when you have to move the mouse over your whole desktop setup just to
reach a menu entry. (same for looking around to check information on the status bar, which shall represent the status
of the window which has focus anyways). And last but not least, the current GDL docks implement thir own drag handles,
of the window which has focus anyways). And last but not least, the current GDL docks implement their own drag handles,
moving windows around has a big performance problem with some window managers, moving windows shall be the job of the
window manager and not the job of the application, the only thing the application may do is hinting positions to the
WM. These second class dock windows are neither ICCCM conforming (http://tronche.com/gui/x/icccm/[]) nor do they add any
WM. These second class dock windows are neither https://tronche.com/gui/x/icccm/[ICCCM] conforming nor do they add any
extra user experience, instead the user has to learn a new kind of window class. +
-- link:ct[] [[DateTime(2009-01-29T03:15:03Z)]]
ct:: '2009-01-29T03:15:03Z'
To chime in with the commenting... this comparison rather strengthened my preference for paradigm #2 _for our situation here._
But I think we should try to exploit some of the extended possibilities which you usually rather find in those Super-IDE type applications:
perspectives, freely configurable pannels, multiple top level windows, something like palettes or tiling.
perspectives, freely configurable panels, multiple top level windows, something like palettes or tiling.
When you compare the situation when working on software with the situation when working on a feature film, it seems to me that the situation
don't match up. The rationale of having multiple software projects opened is (a) "lets see how I solved the same problem 2 months ago there..."
and (b) working on a larger software compound, comprised of multiple parts, which may even be deployed distributed.
I think none of these applies to film editing. (Maybe the situation is a bit different for putting together a TV show)
According to my own editing experiences, both film and sound, the "bringing in media into the project"-phase makes only a very small percentage of the overall time spent with a given project. Initially, after bringing in the raw footage, for me there is a long lasting phase where I just explore the material, i.e. I am viewing (or listening) to the footage and maybe try out some possible cuts and combinations in a throwaway fashion, just to get a feeling about the material. Then I build up the backbone of the cut rather quickly (and this is the only time where I could imagine having muliple projects opened at the same time). What follows is a long fine tuning and augmenting phase. So, for me, setting things up so I can work comfortably in a rather focussed and limited part of the application couold be more important then exploring multiple projects at the same time. +
-- link:Ichthyostega[] [[DateTime(2009-01-29T03:31:54Z)]]
According to my own editing experiences, both film and sound, the ``bringing media into the project''-phase makes only a very small percentage
of the overall time spent with a given project. Initially, after bringing in the raw footage,
for me there is a long lasting phase where I just explore the material, i.e. I am viewing (or listening) to the footage
and maybe try out some possible cuts and combinations in a throw-away fashion, just to get a feeling about the material.
Then I build up the backbone of the cut rather quickly (and this is the only time where I could imagine having
multiple projects opened at the same time). What follows is a long fine tuning and augmenting phase.
So, for me, setting things up so I can work comfortably in a rather focused and limited part of the application could be
more important then exploring multiple projects at the same time. +
Another important thing: Do not automatically pop up windows. Creating a new window (even dialog boxes) must always be a consequence an user action. Even error conditions shall _NOT_ pop up an window (with one exception, that is fatal errors which will block the application until resolved). Otherwise the \'error' window shall be some log (perhaps with filtering capabilities) similar to cinelerra, but when an error happens some big red ERROR might blink in the status bar instead and only clicking on that will open the error log. +
-- link:ct[] [[DateTime(2009-02-01T09:40:08Z)]]
Ichthyostega:: '2009-01-29T03:31:54Z'
Another important thing: Do not automatically pop up windows. Creating a new window (even dialog boxes)
must always be a consequence an user action. Even error conditions shall _NOT_ pop up an window
(with one exception, that is fatal errors which will block the application until resolved).
Otherwise the \'error' window shall be some log (perhaps with filtering capabilities) similar to Cinelerra,
but when an error happens some big red ERROR might blink in the status bar instead and only clicking on that will open the error log.
ct:: '2009-02-01T09:40:08Z'

55
doc/design/gui/GuiDiscussion/archive/rawGuiBrainstorming.moinmoin
View file

@ -10,7 +10,8 @@
= State of the GUI =
attachment:Lumiera/GuiBrainstorming/screenshot090418.jpg
`attachment:Lumiera/GuiBrainstorming/screenshot090418.jpg`
img:{imgg}/screenshot2009-04.jpg[]
Updated 18/04/09
@ -204,7 +205,8 @@ Some people contributed drafts/sketches/ideas/brainstorming...
* ["alcarinque"] has an idea about defining the '''gui''' in '''different modules'''.[http://telniratha.atspace.com/spec.html see here] Feedback appreciated.
* Pablo Lizardo made a mockup for the timeline based in the Cinelerra UI elements.[http://farm4.static.flickr.com/3067/3003432151_e30258be3e_o.png see here] .
== Toward a Concrete Sketch ==
See this sketch [attachment:GtkGUI-0.1.png attachment:GtkGUI-0.1.png]
See this sketch +[attachment:GtkGUI-0.1.png]+
image:{imgg}/lum_gui_mockup-2008.png
The sketch is certainly not complete by any means - this is a v0.1. There are many Avid and Cinelerra features that ought to feature in the final product. However it shows a few ideas that I think would be good.
@ -290,7 +292,7 @@ All the controls are built around the side(s)(perimeter) of the (magnifying) vie
The layout of the keys make sit very easy to move both hands up and down the keyboard, choosing more and less. In the first pass of '''''live adjustments''''', they may not give perfect results, but they certainly make it plain to the user, what it was they were wanting to do, when they return to edit the strip later (in non-linear static time mode). Other toggle/mode of use buttons can be built into the tool. Local "preview"-er can be attached and be of any size. Transition and effects selector can also be attached, if wanted in the set-up set. The user could select actions (buttons/purposes of sliders) to be included in the tool's perimeter, and save the setup (gets named - and can determine what situations it gets used as the assumed default set-up to use) for future re-use. Some attached tools like previewer and resources could be set to minimise when the mouse is moved away from the locality of the tool.
attachment:Screenshot-Cinelerra_trackview-crosshairs_widget_01.jpg
img:{imgg}/mock.Cinelerra_trackview-crosshairs_widget-tree2008-09.jpg
Widgets can be'''''"connected" in their influence''''', so that adjustments made in one widget are also made (and maybe scaled) in other "connected" widgets at other locations. Edits made within widgets can be saved and re-applied at later times in other places and projects (just another way to collect input data similar to the use of "undo"/macro feature). The track/thumbnail height and width within the magnifier may be increased, and toggeld/switched between levels of magnification.
@ -1186,21 +1188,22 @@ Not only may the view layouts be customizable, but the number of times they appe
All the general program '''''menu items''''''''''''''''''''''''''''' would be '''''placed''''' above the tabs bar. All the process specific menu items (including what might be specific to "some" other processes), get placed below the tab bar, in the process window. Editing widgets can be of common design in each process - e.g. track fine timeline editing, track size. Methods of retrieving nodes designs, transitions and effects.
. attachment:Screenshot-Cinelerra_nodes-view-tree-02.jpg
. img:{imgg}/mock.Cinelerra_nodes-view-tree2008-05.jpg
. Notes on Node display.
* The node situation is display vertically across the tracks on the timeline in trackview.
* The node tab can be viewed in short form iconic mode, or expanded network-pipe view mode.
* The node tab can be used in an edit mode, where the tracks can be selected as input, and output, and effects are added by dragging and dropping from a master list, or local project toolbox, or (right) click and choose what to insert from a drop down list).
* The node tab is assigned a name (in the example above it is simply a Nxx number). Hovering over the tab name can show the description. The local toolbox/kit of effects is shown even when the '''''tab is displayed in short form (as in N17)''''' , and this allows easy drag and drop to insert and connect the effects. The short form display shows which effects ra ebeing used (and which of the toolbox are not), and roughly to which tracks they are being aplied.
* The '''''edit mode''''' allows an input or effects "box"/icon to be (right) clicked on to open up the parameters to be altered. There can be an option to allow the alterations to apply to only that clip, the group of clips, or update the node set to apply to the whole project whwere ever it is used, or save as a new option set. An effect (the purple one with the tick) has been selected for adjustment in N16. Nodes junctions can be re-ordered, bypassed (set to null), routes split or deleted by clicking and dragging the connection lines.
* The '''''camera and projector areas of the inputs''''' can be roughly set directly within the window of the node editor, to allow for fast general concept/sketch of the layout. But can be (right) clicked on to bring up an enlarged view for more accurate positioning (and settings) at a later stage of production.
* The '''''node settings can be managed''''' by being saved, given a name, description and metatags to assign when assigning the nodeset, so that the effects can be easily applied time and again to clips/timestrips (drag and drop, or select from menu, toolbar, toolbox, drop down list - from full main set or local project kit).
* The tab can be scrolled along the timeline, and the parameters in the node tab can be shown to vary with time.
* The node tab shows which tracks are used for input and which are used for output - there is no assumption or forcing the upper tracks to have priority the lower tracks. Each node does not have to send their output to the same output track as other nodes.
* More than one node tab can be active at any point in time. (a check would be needed that no eternal loops are created when more than one node tab is active at once).
* The same node tab could be viewed at once in several locations on the timeline, just like keyframes, so the user can immediately see how the states have changed at each of the chosen points in time time.
* The node tabs used anywhere in the project can all be created,edited, stored and managed in a view tab for nodes management, and could be quickly accessed by some tabs down the right hand side of the track view.
* The video editor has '''''similarites to an audio mixer''''' . An audio mixer has inputs on left, effects on each channel running down, buses horizontally, and outputs on right. The '''''video editor is similar but rotated sideways''''' . So inputs are on top, effects are applied to tracks or subclips at times (can either be applied to clips/sets, or time positions), output are at bottom, and so '''''nodes/busses''''' which show the path from selected inputs to outputs would sensibly be vertical (as shown above). '''''Groups''''' (as in sets of tracks that get edited, "trimmed" or "moved" as a set from time to time as desired), are also connected vertically, but are probably better placed on the left side, where Cinelerra has previously allowed manual and temporary selection of (one) group (needed to be changed every time you wanted a different combination for a group, and couldn't be saved to easily return to a previous group). ecah groups could be a horizontal tab (choose which groups to be shown as tabs), or as a single column but column title area has a drop down menu to allow user to select which group is currently active. The group management/dropdown list also has options to save, assign name, add description, delete current group, create new group.
* The node situation is display vertically across the tracks on the timeline in trackview.
* The node tab can be viewed in short form iconic mode, or expanded network-pipe view mode.
* The node tab can be used in an edit mode, where the tracks can be selected as input, and output, and effects are added by dragging and dropping from a master list, or local project toolbox, or (right) click and choose what to insert from a drop down list).
* The node tab is assigned a name (in the example above it is simply a Nxx number). Hovering over the tab name can show the description. The local toolbox/kit of effects is shown even when the '''''tab is displayed in short form (as in N17)''''' , and this allows easy drag and drop to insert and connect the effects. The short form display shows which effects ra ebeing used (and which of the toolbox are not), and roughly to which tracks they are being aplied.
* The '''''edit mode''''' allows an input or effects "box"/icon to be (right) clicked on to open up the parameters to be altered. There can be an option to allow the alterations to apply to only that clip, the group of clips, or update the node set to apply to the whole project whwere ever it is used, or save as a new option set. An effect (the purple one with the tick) has been selected for adjustment in N16. Nodes junctions can be re-ordered, bypassed (set to null), routes split or deleted by clicking and dragging the connection lines.
* The '''''camera and projector areas of the inputs''''' can be roughly set directly within the window of the node editor, to allow for fast general concept/sketch of the layout. But can be (right) clicked on to bring up an enlarged view for more accurate positioning (and settings) at a later stage of production.
* The '''''node settings can be managed''''' by being saved, given a name, description and metatags to assign when assigning the nodeset, so that the effects can be easily applied time and again to clips/timestrips (drag and drop, or select from menu, toolbar, toolbox, drop down list - from full main set or local project kit).
* The tab can be scrolled along the timeline, and the parameters in the node tab can be shown to vary with time.
* The node tab shows which tracks are used for input and which are used for output - there is no assumption or forcing the upper tracks to have priority the lower tracks. Each node does not have to send their output to the same output track as other nodes.
* More than one node tab can be active at any point in time. (a check would be needed that no eternal loops are created when more than one node tab is active at once).
* The same node tab could be viewed at once in several locations on the timeline, just like keyframes, so the user can immediately see how the states have changed at each of the chosen points in time time.
* The node tabs used anywhere in the project can all be created,edited, stored and managed in a view tab for nodes management, and could be quickly accessed by some tabs down the right hand side of the track view.
* The video editor has '''''similarites to an audio mixer''''' . An audio mixer has inputs on left, effects on each channel running down, buses horizontally, and outputs on right. The '''''video editor is similar but rotated sideways''''' . So inputs are on top, effects are applied to tracks or subclips at times (can either be applied to clips/sets, or time positions), output are at bottom, and so '''''nodes/busses''''' which show the path from selected inputs to outputs would sensibly be vertical (as shown above). '''''Groups''''' (as in sets of tracks that get edited, "trimmed" or "moved" as a set from time to time as desired), are also connected vertically, but are probably better placed on the left side, where Cinelerra has previously allowed manual and temporary selection of (one) group (needed to be changed every time you wanted a different combination for a group, and couldn't be saved to easily return to a previous group). ecah groups could be a horizontal tab (choose which groups to be shown as tabs), or as a single column but column title area has a drop down menu to allow user to select which group is currently active. The group management/dropdown list also has options to save, assign name, add description, delete current group, create new group.
-- ["Tree"][[DateTime(2008-05-07T20:54:00NZ)]] updated [[DateTime(2008-09-01T18:29:54:00NZ)]]
== Transition, Levels or Effects Widget remains on top while swapping windows between track view and composer ==
@ -1341,7 +1344,8 @@ The track can be played underneath the dockable cross tools, or they can be drag
It might be possible to have more than one per track, so the end points of a stretch of video can be worked on, withou having to jump through several labels, or remembering where to "go to". These tools would act as a means to identify areas that are "being" worked on. Very easy for the user to "park" a task and work elsewhere, then come back.
. attachment:Screenshot-Cinelerra_trackview-crosshairs_tool-other_way-synchro_mode-undocked-tree-02.jpg
img:{imgg}/mock.Cinelerra_trackview-crosshairs_tool-tree2008-05.jpg
'''Notes on Mouse Ergonomics'''
1) In the GUI shown above, the buttons in the small camera and projector view are small. They are clickable, but fiddly. These ease of targeting them is improved, by making use of the fact that to their left are'''''"nearby regions that do not need to be active"'''''. The area used to detect the cursors vertical position, can therefore be extended well towards the left of the buttons. This allows for horizontal inaccuracy of the mouse, while concentrating on the targeting the vertical position.
@ -1842,7 +1846,7 @@ The motion tracker boxes and vectors are not colour code (or line styled) to hel
== Motion Tracker - Concept for improved features and GUI ==
The following image is an example of how the panel)s) for the motion tracker could be improved. Note the tabs for workflow left to right. Note the order of decisions from top to bottom. 3 axis separation, reduced confusion as to what setting to use for what purpose.
attachment:motion_tracker-tree_version_03.jpg
img:{imgg}/mock.motion_tracker-tree2008-05.jpg
. --["Tree"][[DateTime(2008-05-25T23:32:00NZ)]] .
== Motion Tracker - alternative to manual use of "Blur" and "Histogram" effects to improve result ==
@ -2028,12 +2032,13 @@ Not shown in the example;
In the tab label or near the top of the tab strip, there could be some icons for easy access to tasks such as ;
1. dump this transition from the queue.
1. execute this transition NOW
1. move this transition up the queue.
1. move this transition down the queue
1. open this transition for viewing and editing The tools, look and feel is in keeping with the rest of the program, and is very similar to the node designer, and usual transition & effects editor.
attachment:Screenshot-Cinelerra_live-capture-view-tree-01.jpg
. dump this transition from the queue.
. execute this transition NOW
. move this transition up the queue.
. move this transition down the queue
. open this transition for viewing and editing The tools, look and feel is in keeping with the rest of the program, and is very similar to the node designer, and usual transition & effects editor.
+
img:{imgg}/mock.Cinelerra_live-capture-view-tree2008-09.jpg
''--["Tree"][[DateTime(2008-09-03T12:58:00NZ)]] .''

25
doc/design/gui/GuiDiscussion/index.txt
View file

@ -1,11 +1,18 @@
GUI Design and Feature Discussion
=================================
//Menu: prepend child GuiBrainstormingWontImplement
//Menu: prepend child GuiBrainstormingReviewed
//Menu: put child ConceptProposals after GuiBrainstormingWontImplement
//Menu: put child TimelineDiscussion after ConceptProposals
//Menu: put child GuiDiscussion/Timeline after ConceptProposals
In the early days of the Lumiera project, there was a lot of debate regarding
GUI concepts, -features and proposals.
In the early days of the Lumiera project, there was an extended debate regarding
GUI concepts and -features, including many proposals from the community.
Bearing in mind that we have meanwhile gained a clearer understanding what wee
need to build for the GUI, this _brainstorming phase_ is completed.
However, a more focused discussion regarding »Workflow«
link:/x/Verweijlen.html[ensued in 2025].
GUI Brainstorming::
We got a lot of proposed cool features. In order to channel this great influx of ideas,
@ -22,13 +29,15 @@ GUI Proposals::
* link:ConceptProposals/Alcarinque.html[Alcarinque]
* link:ConceptProposals/Barnes.html[Clay Barnes]
* link:ConceptProposals/RichardSpindler.html[Richard Spindler]
Feature discussion::
Some topics spurred some heightened interest and (controversial) discussion
* link:Workspaces.html[about Workspace organisation]
* link:scrolling.html[about scrolling..]
* link:MenuAndShortcuts.html[Ideas for menus and shortcuts]
* link:Scrolling.html[about scrolling..]
* link:PieMenu.html[menu / shortcuts]
Timeline Discussion::
In 2008, Joel reviewed all the available proposals and distilled a more coherent vision
especially about the timeline, which certainly is at the heart of any video editor.
This page with link:TimelineDiscussion.html[Conclusions by Joel Holdsworth] is
_must read_ for anyone engaged into Lumiera GUI development.
especially about the timeline, which certainly is at the heart of any video editor. +
💡 Note the link:Timeline.html#_joel_conclusions[Conclusions by Joel Holdsworth] as a summary.

34
doc/design/gui/index.txt
View file

@ -1,20 +1,38 @@
Design Documents: GUI
=====================
In the early stages of the project, there was a lot of debate regarding
GUI concepts and -features and proposals.
//MENU: append child GuiDiscussion
link:GuiDiscussion/index.html[Here] is a collection of documents from these early
In the early stages of the project, there was a lot of debate regarding
GUI concepts and -features and proposals. Extended discussions ensued on
the Mailinglist and several people provided concept drawings.
-> link:GuiDiscussion/index.html[Here] is a collection of documents from these early
discussions.
''''
In the current phase of the project, the UI conception focuses on a way
to build the interface in a systematic way, to support complex workflows
with low friction. The following questions need to be addressed:
- How to use _Perspectives_, Views, Docking Panels and Layout
- how to adapt the Layout, ranging from a single Laptop screen to multiple monitors
- how to allocate and place new views and property panes intelligently
- how to allow for a coherent navigation scheme that works seamlessly
and intuitively over a mixture of several _Control Systems_.footnote:[The term »Control System«
refers to one technical realisation of an human-computer-interface, which is used coherently and
can coexist with other such interfaces
-> link:/x/InteractionControl.FoundationConcepts.html[more here]... +
The most relevant control systems are: Mouse, keyboard, pen, hardware controls, ...]
- how to build such a link:/x/InteractionControl.html[Layer of Interaction-Control]
without interfering with the evolution of the underlying UI toolkit ⚠ ...
.[red]#TODO# more contributions please... ;-)
We had several additional discussions and contributions on the mailinglist,
several people did even concept drawings. Collect these and add them here
NOTE: We use the term *Workflow* in our discussions to denote the more integral
concerns of how to achieve given tasks within the application in the most
suitable and stringent fashion. We tend to separate those more global
considerations from the discussion of individual GUI features.
-> link:../workflow/index.html[read more here...]
considerations from the discussion of individual GUI features. +
-> link:/x/Workflow.html[more about Workflow...]

21
doc/design/model/Segmentation.txt Normal file
View file

@ -0,0 +1,21 @@
Segmentation of Timeline
========================
.A junction between the models
The term ``Segmentation of the Timeline'' describes both a data structure and a step in the
build process, which translates the structures of the *high-level-Model* into a corresponding
graph of Render Nodes. The latter is also known as the *low-level-Model* and can be seen
as a set of preconfigured render pipelines. When such a pipeline is ``pulled''. the render
computations are invoked. The _access points_ to all these pipelines are hooked into a
_backbone_ data structure, designated as the *Fixture* -- which breaks down each top-level
Timeline into a sequence of temporal segments: what differentiates these segments is the
topology of the Render Nodes in the pipeline; whenever a change in this topology is
necessary, a new segment is started. Such a change might e.g. be caused by a transition
between two clips, which has to cover a range of some frames.
As of 2025, this part of the model is only roughly drafted, mostly using placeholder code
to achieve some level of functional integration.
Detailed design planning and explanations can be found in the
link:/x/fwd/DevWiki.Segmentation.html[DevWiki: Segmentation].

2
doc/design/model/index.txt
View file

@ -2,5 +2,5 @@ Design Documents: Model
=======================
* two models: high-level and low-level
* RfC: link:{rfc}/../rfc/ProcHighLevelModel.html[high-level model basics]
* RfC: link:{rfc}/ProcHighLevelModel.html[high-level model basics]

4
doc/design/workflow/Verwijlen/FrosconMeeting.txt
View file

@ -21,7 +21,7 @@ Points discussed
----------------
We agreed upon the importance of a link:WorkflowProposals.html#\_tracks_vs_trackless[magnetic timeline],
as introduced by Final Cut X.
However, our link:{ldoc}/devel/rfc_final/ProcPlacementMetaphor.html[Placement concept (2008)]
However, our link:{rfc}/ProcPlacementMetaphor.html[Placement concept (2008)]
which predates FCPX's release,footnote:[Final Cut Pro X was
link:https://en.wikipedia.org/wiki/Final_Cut_Pro#Final_Cut_Pro_X[released in 2011], and the »Magnetic
Timeline« is generally considered a novel concept introduced with this update. The initial reception
@ -30,7 +30,7 @@ shares similar goals but its scope is more far-reaching. We consider _Magnetic T
important advancement to legacy track oriented GUI schemes; but it is more mouse confined and does
not support several Control Systems footnote:[The term »Control System« refers to one technical
realisation of an human-computer-interface, which is used coherently and can coexist with other
such interfaces -> link:{ldoc}/design/gui/InteractionControl.html#_foundation_concepts[more]. +
such interfaces -> link:/x/InteractionControl.FoundationConcepts.html[more]. +
The most relevant control systems are: Mouse, keyboard, pen, hardware controls, ...]
on an equal footing, which is our vision.

6
doc/design/workflow/Verwijlen/WorkflowProposals.txt
View file

@ -37,11 +37,11 @@ I've seen different editors using different ways of working.
So if the aim for Lumiera is to be a general purpose video editing application, then we can
not force any specific way of doing things and instead we should support many different
workflows, in other words: provide a platform with possibilities for each editor to make it
their own (which will arguably be a harder goal to achieve). Instead of a "we know what's
best for you" approach I propose a "smart defaults with many options for configuration"
their own (which will arguably be a harder goal to achieve). Instead of a ``we know what's
best for you'' approach I propose a ``smart defaults with many options for configuration''
approach.
* A big question is: who is "the user"? We aim to create a tool for professionals, but there are
* A big question is: who is »the user«? We aim to create a tool for professionals, but there are
many types of professionals working in entirely different parts of the media industry or in
other fields. In the previous paragraph it was mentioned that different types of content
require different types of workflows. How to accommodate all of these different people who

3
doc/design/workflow/index.txt
View file

@ -11,6 +11,7 @@ so we tend to treat it as a distinct effort, separate from the design of individ
* link:LumieraWorkflowOutline.html[Workflow/Requirements outline by BJMR]
* link:InterfaceConcept_Varga.html[Interface Concept by Christoph Varga]
* link:/x/Verweijlen.html[Workflow Proposals by Wouter Verweijlen]
-> see also link:../gui/index.html[general GUI discussion...]
-> see also link:/x/GuiDiscussion.html[general GUI discussion...]

3
doc/devel/Doxyfile
View file

@ -157,7 +157,8 @@ REFERENCES_LINK_SOURCE = NO
SOURCE_TOOLTIPS = YES
USE_HTAGS = NO
VERBATIM_HEADERS = NO
CLANG_ASSISTED_PARSING = YES
#CLANG_ASSISTED_PARSING = YES
CLANG_ASSISTED_PARSING = NO
CLANG_OPTIONS = -DDEBUG -DEBUG_ALPHA
#---------------------------------------------------------------------------

109
doc/devel/DoxygenLayout.xml
View file

@ -2,42 +2,43 @@
<!-- Navigation index tabs for HTML output -->
<navindex>
<tab type="mainpage" visible="yes" title="Lumiera API Documentation"/>
<tab type="user" url="http://Lumiera.org/documentation/user/intro/intro.html" title="Intro"/>
<tab type="user" url="http://Lumiera.org/documentation/technical/overview.html" title="Overview"/>
<tab type="modules" visible="yes" title="" intro="Subsystems"/>
<tab type="classes" visible="yes" title="">
<tab type="classlist" visible="yes" title="" intro=""/>
<tab type="classindex" visible="$ALPHABETICAL_INDEX" title=""/>
<tab type="hierarchy" visible="no" title="" intro=""/>
<tab type="classmembers" visible="yes" title="" intro=""/>
<tab type="user" url="/documentation/user/intro/intro.html" title="Intro"/>
<tab type="user" url="/documentation/technical/overview.html" title="Overview"/>
<tab type="topics" visible="yes" title="" intro="Subsystems"/>
<tab type="classlist" visible="yes" title="Classes" intro=""/>
<tab type="usergroup" title="Index">
<tab type="filelist" visible="yes" title="Files" intro=""/>
<tab type="namespacelist" visible="yes" title="Namespaces" intro=""/>
<tab type="concepts" visible="yes" title="Concepts"/>
<tab type="structlist" visible="yes" title="" intro=""/>
<tab type="exceptionlist" visible="yes" title="" intro=""/>
<tab type="classindex" visible="$ALPHABETICAL_INDEX" title="Class Idx"/>
<tab type="interfaceindex" visible="$ALPHABETICAL_INDEX" title="Interfaces"/>
<tab type="classmembers" visible="yes" title="Members" intro=""/>
</tab>
<tab type="namespaces" visible="yes" title="">
<tab type="namespacelist" visible="yes" title="" intro=""/>
<tab type="namespacemembers" visible="yes" title="" intro=""/>
<tab type="pages" visible="yes" title="" intro="Other">
<tab type="examples" visible="yes" title="" intro=""/>
<tab type="user" url="/documentation/design/" title="Design Topics"/>
</tab>
<tab type="files" visible="yes" title="">
<tab type="filelist" visible="yes" title="" intro=""/>
<tab type="globals" visible="yes" title="" intro=""/>
</tab>
<tab type="pages" visible="yes" title="" intro=""/>
<tab type="examples" visible="yes" title="" intro=""/>
</navindex>
<!-- Layout definition for a class page -->
<class>
<briefdescription visible="no"/>
<includes visible="$SHOW_INCLUDE_FILES"/>
<includes visible="$SHOW_HEADERFILE"/>
<allmemberslink visible="yes"/>
<detaileddescription title="Description"/>
<memberdecl>
<nestedclasses visible="yes" title=""/>
<publictypes title=""/>
<services title=""/>
<interfaces title=""/>
<publicslots title=""/>
<signals title=""/>
<publicmethods title=""/>
<publicstaticmethods title=""/>
<publicstaticattributes title=""/>
<publicattributes title=""/>
<nestedclasses visible="yes" title=""/>
<publicstaticmethods title=""/>
<publicmethods title=""/>
<friends title=""/>
<properties title=""/>
<events title=""/>
@ -62,13 +63,15 @@
<membergroups visible="yes"/>
</memberdecl>
<memberdef>
<constructors title=""/>
<inlineclasses title=""/>
<typedefs title=""/>
<enums title=""/>
<inlineclasses title=""/>
<constructors title=""/>
<functions title=""/>
<properties title=""/>
<interfaces title=""/>
<variables title=""/>
<services title=""/>
<events title=""/>
<related title=""/>
</memberdef>
@ -84,12 +87,18 @@
<detaileddescription title="Description"/>
<memberdecl>
<nestednamespaces visible="yes" title=""/>
<typedefs title=""/>
<interfaces visible="yes" title=""/>
<concepts visible="yes" title=""/>
<typedefs visible="yes" title=""/>
<enums title=""/>
<classes visible="yes" title=""/>
<functions title=""/>
<variables title=""/>
<exceptions visible="yes" title=""/>
<sequences title=""/>
<dictionaries title=""/>
<membergroups visible="yes"/>
<constantgroups visible="yes" title=""/>
</memberdecl>
<memberdef>
<typedefs title=""/>
@ -97,24 +106,41 @@
<inlineclasses title=""/>
<functions title=""/>
<variables title=""/>
<sequences title=""/>
<dictionaries title=""/>
</memberdef>
<authorsection visible="yes"/>
</namespace>
<!-- Layout definition for a concept page -->
<concept>
<briefdescription visible="yes"/>
<includes visible="$SHOW_HEADERFILE"/>
<detaileddescription title=""/>
<definition visible="yes" title=""/>
<authorsection visible="yes"/>
</concept>
<!-- Layout definition for a file page -->
<file>
<briefdescription visible="no"/>
<briefdescription visible="yes"/>
<sourcelink visible="yes"/>
<detaileddescription title="Description"/>
<includes visible="$SHOW_INCLUDE_FILES"/>
<memberdecl>
<classes visible="yes" title=""/>
<namespaces visible="yes" title=""/>
<interfaces visible="yes" title=""/>
<concepts visible="yes" title=""/>
<defines title=""/>
<typedefs title=""/>
<enums title=""/>
<defines title=""/>
<classes visible="yes" title=""/>
<functions title=""/>
<variables title=""/>
<namespaces visible="yes" title=""/>
<exceptions visible="yes" title=""/>
<sequences title=""/>
<dictionaries title=""/>
<constantgroups visible="yes" title=""/>
<membergroups visible="yes"/>
</memberdecl>
<memberdef>
@ -134,14 +160,19 @@
<group>
<briefdescription visible="no"/>
<detaileddescription title="Description"/>
<groupgraph visible="yes"/>
<memberdecl>
<nestedgroups visible="yes" title=""/>
<dirs visible="yes" title=""/>
<files visible="yes" title=""/>
<modules visible="yes" title=""/>
<namespaces visible="yes" title=""/>
<concepts visible="yes" title=""/>
<classes visible="yes" title=""/>
<defines title=""/>
<typedefs title=""/>
<sequences title=""/>
<dictionaries title=""/>
<enums title=""/>
<enumvalues title=""/>
<functions title=""/>
@ -160,6 +191,8 @@
<inlineclasses title=""/>
<defines title=""/>
<typedefs title=""/>
<sequences title=""/>
<dictionaries title=""/>
<enums title=""/>
<enumvalues title=""/>
<functions title=""/>
@ -172,10 +205,28 @@
<properties title=""/>
<friends title=""/>
</memberdef>
<groupgraph visible="$GROUP_GRAPHS"/>
<authorsection visible="yes"/>
</group>
<!-- Layout definition for a C++20 module page -->
<module>
<briefdescription visible="yes"/>
<exportedmodules visible="yes"/>
<memberdecl>
<concepts visible="yes" title=""/>
<classes visible="yes" title=""/>
<enums title=""/>
<typedefs title=""/>
<functions title=""/>
<variables title=""/>
<membergroups title=""/>
</memberdecl>
<detaileddescription title=""/>
<memberdecl>
<files visible="yes"/>
</memberdecl>
</module>
<!-- Layout definition for a directory page -->
<directory>
<briefdescription visible="yes"/>

16
doc/devel/LumieraHelpLandingPage.NOTICE Normal file
View file

@ -0,0 +1,16 @@
NOTE: this is a placeholder -- the intention is to build a user Manual via Asciidoc
As of 2025, Lumiera is not usable, and thus only a placeholder HTML page is provided
for the DEB-Package. The content on this page is identical to the "User-Manual" page:
https://Lumiera.org/documentation/user/manual.html
For the delivery
- this page has been rendered with Asciidoc
- the resulting HTML has been processed with the "Print Edit WE" plugin of Firefox,
which inlines any resources (CSS, images)
This page will be installed by the Lumiera SCons build into $prefix/share/doc/lumiera
(see doc/SConsscript)
Hint: for updates, re-render the Asciidoc and then use git/diff to combine the
new or changed content with the embedded inline images (base64 data)

699
doc/devel/LumieraHelpLandingPage.html Normal file
View file

File diff suppressed because one or more lines are too long

41
doc/devel/meeting_summary/2008-02-01.txt
View file

@ -18,24 +18,35 @@ __Participants__
* Velmont
Discuss the open points in [Lumiera/DesignProcess] --- do we need this formalism?
---------------------------------------------------------------------------------
At start of the project last summer, Cehteh made a http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process proposal]. We will keeping this up, not for every implementation detail, but for major plans, wishes and design decisions. One point in the agenda of future meetings will be to work through proposals in the queue
Discuss the open points in the link:/x/DesignProcess.html[Design Process]
-------------------------------------------------------------------------
* proposals in the "idea" state are not complete, can be just brainstorming or need further discussion. Comments please to the proposal page.
* proposals in the "draft" state are ready for conclusive discussion and will be treated in one of the next meetings
* "final" proposals are either "accepted" or "dropped". We don't differentiate the latter, but should write a short note why it was dropped.
Do we need this formalism? --
At start of the project last summer, _Cehteh_ made a link:{rfc}/LumieraDesignProcess.html[»Design Process« proposal].
We will keeping this up, not for every implementation detail, but for major plans, wishes and design decisions.
One point in the agenda of future meetings will be to work through proposals in the queue.
* proposals in the `Idea' state are not complete, can be just brainstorming or need further discussion. Comments please to the proposal page.
* proposals in the `Draft' state are ready for conclusive discussion and will be treated in one of the next meetings
* `Final' proposals are either `Accepted' or `Dropped'. We don't differentiate the latter, but should write a short note why it was dropped.
* if there is need for more or finer grained categories, we'll extend the page and the template as needed or provide different views
The development model
---------------------
We employ a distributed model based on GIT. We want this repository to be as complete as possible, including documentation in embedded TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a "Mob GIT", i.e. anonymously pushable git (which is untrusted of course). Cehteh is currently working on a git web frontend which makes the codebase in the mob-repo web-editable like a wiki.
Will we need a stable version or an official branch? not yet &mdash; as long as the team is small it will work more painless without. At some point, when the project is more mature, we will define an official branch. Later on we will have automated builds and regression test runs. As we do test-driven development anyways, it's just a question of someone setting up all the infrastructure, then we'll do it.
Ichthyo proposes a new requirement: All devs should ensure the "master" branch of their respective repositories always passes the compiler and the test suite. Work-In-Progress should be done on branches. Rationale: it is sufficient to pull from the master branches, and you can be sure the version you pulled worked for the originator.
A note on dependencies: it will be hard to target minimal dependencies for such a project, but we shall try not to bloat it unnecessarily. Sometimes it can be sensible to rather re-invent a feature &mdash; esp. when it fits into the core focus of the project &mdash; instead of depending on difficult to build and not sufficiently maintained external projects. But we should avoid reinventing things like GUI toolkits.
We employ a distributed model based on Git. We want this repository to be as complete as possible, including documentation in embedded TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a ``Mob GIT'', i.e. _anonymously pushable Git_ (which is untrusted of course). _Cehteh_ is currently working on a Git web frontend (``webgit'') which makes the codebase in the mob-repo web-editable like a wiki.
Will we need a stable version or an official branch? not yet -- as long as the team is small it will work more painless without. At some point, when the project is more mature, we will define an official branch. Later on we will have automated builds and regression test runs. As we do test-driven development anyways, it's just a question of someone setting up all the infrastructure, then we'll do it.
Ichthyo proposes a new requirement: All devs should ensure the `master' branch of their respective repositories always passes the compiler and the test suite. Work-In-Progress should be done on branches. Rationale: it is sufficient to pull from the master branches, and you can be sure the version you pulled worked for the originator.
A note on dependencies: it will be hard to target minimal dependencies for such a project, but we shall try not to bloat it unnecessarily. Sometimes it can be sensible to rather re-invent a feature -- esp. when it fits into the core focus of the project -- instead of depending on difficult to build and not sufficiently maintained external projects. But we should avoid reinventing things like GUI toolkits.
And, pretty much obvious, we try to stick to modern programming standards. Read: modules have interfaces, interfaces need some (minimal) documentation, and it is not allowed to bypass the interfaces and tangle everything in a wild fashion.
Currently, the project can be separated into three layers, which could evolve into sub-projects: Backend, Proc-Layer, GUI. For each part, the dev most deeply involved and most knowledgeable will take on the sometimes necessary leadership and have the last word in case of quarrels. Currently, Cehteh cares for the Backend and Ichthyo headed for the Proc-Layer. We have postponed any work on the GUI for now and don't participate in GUI toolkit discussions. If there is a dev willing to care for the GUI, collect proposals, care for usability and the users needs and finally code it up, then he will the one to decide what toolkit to use.
We plan to make the discussion about GPL v3 a point on the agenda of the next meeting.
@ -43,11 +54,11 @@ Monthly meetings
----------------
* make it thursday, not friday
* time for now 21:00 GMT &mdash; if some (potential) participants have problems with this time, please speak up (maybe alternating times?)
* time for now 21:00 GMT -- if some (potential) participants have problems with this time, please speak up (maybe alternating times?)
* write a short status report for each mayor part *prior* to the meeting (saves us time). Maybe add an TODO list there
* go through the open issues for the design process drafts
* publish a protocol of each meeting on the (Cinelerra-CV, LibOpenvideo) Mailinglists, in the link:TiddlyWiki[] and on pipapo.org
* News, Protocols and the agenda of the next meeting can be found at link:MonthlyMeetings[this page here]
* publish a protocol of each meeting on the (Cinelerra-CV, LibOpenvideo) Mailinglists, in the TiddlyWiki and on `pipapo.org`
* News, Protocols and the agenda of the next meeting can be found at link:{ldoc}/devel/meeting_summary/index.html[Monthly meetings page]
* next meeting on first Thursday in March (6.3.2008)
@ -71,11 +82,11 @@ Since the render nodes are stateless they can be driven in multiple threads (but
The naming discussion
---------------------
The discussion looks healthy so far... People can add new proposals on the http://www.pipapo.org/pipawiki/Lumiera/Names[pipawiki]. Interesting names are still coming in, so we should just let the name-choosing game go on for a while. And, btw, we _can_ depart from beeing similar to "Cinelerra" ;-)
The discussion looks healthy so far... People can add new proposals on the [pipawiki]. Interesting names are still coming in, so we should just let the name-choosing game go on for a while. And, btw, we _can_ depart from beeing similar to "Cinelerra" ;-)
Let's say, we need a person volonteering to guide/moderate the selection, going over the list and scratching inammprobiate ones. Criteria for good names being:
* should not be an existing project
* should be "googleable"
* should be ``googleable''
* should not be offensive
* should have one of the free top level domains (.net, .org)
* should be compatible with educational institutions (sorry, no pr0nedit :)

143
doc/devel/meeting_summary/2008-03-06.txt
View file

@ -26,8 +26,8 @@ Boilerplate
Organization of this meeting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* cehteh writes the protocol
* hermanr does chairman
* _Cehteh_ writes the protocol
* _Hermanr_ does chairman
Leftovers from last meeting
@ -41,80 +41,93 @@ Go through Ideas and Drafts in design process
Idea: time_handling
~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/time_handling[]
link:{rfc}/TimeHandling.html[time handling]
Point 1 is superseded by using gavl.
Point 1 is superseded by using Gavl.
Points 2 and 3 are still valid.
Ichthyo asked gmerlin if there are any problems according gavl for the points 2 (position of frames) and 3 (position for keyframes and automation). Gmerlin acknowledges that he doesnt see any problems.
_Ichthyo_ asked _Gmerlin_ if there are any problems according Gavl for the points 2 (position of frames) and 3 (position for keyframes and automation).
_Gmerlin_ acknowledges that he does not see any problems.
Oracle2025 brings interlacing on topic "are you aware that automations and keyframes could/should also apply to fields?". We agree that this must be handled "in interlacing, a frame is a pair of 2 subsequent fields".
_Oracle2025_ brings interlacing on topic ``are you aware that automations and keyframes could/should also apply to fields?''.
We agree that this must be handled ``in interlacing, a frame is a pair of 2 subsequent fields''.
Conclusion:
Refactor the proposal according to the discussion and work it out, make it draft then. Discuss about it on the next meeting
Conclusion:: Refactor the proposal according to the discussion and work it out, make it draft then. Discuss about it on the next meeting
Idea: Unit tests in Python
~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/UnitTests_Python[]
link:{rfc}/UnitTests_Python.html[RfC: Unit Tests in Python]
We have a testsuite based on cehtehs 'test.sh' which superseedes this proposal.
We have a testsuite based on _Cehtehs_ `test.sh` which superseeds this proposal.
Conclusion:
Drop it.
Conclusion:: Drop it.
Idea: Todo Lists
~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/TodoLists[]
link:{rfc}/TodoLists.html[Todo Lists] to organise tasks to be done....
This Idea is in a very early state an not yet mature.
Cehteh explains: "I want something which doesn't need much human care and i want one big \'milestones' thing and a small \'mini-task' thing". Ichthyo refines this as "Roadmap" and "Near time task list". We agree that this shall not be too strict. There are some ideas floating, like adding this things to the testsuite or use the wiki. Ichthyo shows how he uses the tiddlywiki's task macro (http://ichthyostega.de/cin3/wiki/renderengine.html#PlanningNodeCreatorTool[]). He likes it but doubts its usefulness when it is used without guessing the hours/days of work.
This idea is in a very early state an not yet mature.
Cehteh explains: ``I want something which doesn't need much human care and i want one big »milestones«
thing and a small »mini-task« thing''. Ichthyo refines this as »Roadmap« and »Near time task list«.
We agree that this shall not be too strict. There are some ideas floating, like adding this things
to the testsuite or use the wiki. _Ichthyo_ shows how he uses the TiddlyWiki's `task macro`.
He likes it but doubts its usefulness when it is used without guessing the hours/days of work.
Conclusion:
We use the Tiddlywiki task macro thing for now.
Conclusion:: We use the TiddlyWiki task macro thing for now...
Draft: CCodingStyleGuide
~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/CCodingStyleGuide[]
link:{rfc}/CCodingStyleGuide.html[C-coding style guide]
Ichthyo tells that the discussion on the wiki page made this clear now. Cehteh explains that he uses this style with success for diffrent projects. We make clear that this is meant for C, in C++ we use namespaces. Overall we agree that code shall be self-documenting.
_Ichthyo_ tells that the discussion on the wiki page made this clear now.
_Cehteh_ explains that he uses this style with success for different projects.
We make clear that this is meant for C, in C++ we use namespaces.
Overall we agree that code shall be self-documenting.
Conclusion:
Make it final.
Conclusion:: Make it final.
Draft: DevelopmentFramework
~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DevelopmentFramework[]
link:{rfc}/DevelopmentFramework.html[Development Framework]
Cehteh explains that he will transfer this propoal to a tiddlywiki covering compatibility guides and dependencies. We conclude that this wiki must reflect the actual practice (NoBug, Doxygen, test.sh) despite the proposal is not concrete yet.
_Cehteh_ explains that he will transfer this propoasl to a TiddlyWiki covering compatibility guides and dependencies.
We conclude that this wiki must reflect the actual practice (NoBug, Doxygen, test.sh) despite the proposal is not concrete yet.
A short discussion about build systems came up, we still use autotools and scons in parallel, delaying the decision later. oracle2025 mentioned that scons could be used for development and autotools for release. No decision about that everyone has different opinions. But we agree that it works as is.
A short discussion about build systems came up, we still use Autotools and SCons in parallel, delaying the decision later.
_Oracle2025_ mentioned that SCons could be used for development and Autotools for release.
No decision about that everyone has different opinions. But we agree that it works as is.
Conclusion:
Conclusion::
Cehteh will make the proposed wiki which shall be maintained to reflect the state and this topic will be finalized by that.
Draft: Skills Collection
~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/SkillsCollection[]
link:{rfc}/SkillsCollection.html[RfC: Collection of Skills]
This might be only useful if there are more developers working on the project.
Conclusion:
Conclusion::
Leave in draft state for now.
Draft: Architecture Overview
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[]
link:{rfc}/ArchitectureOverview.html[Architecture Overview]
Ichthyo drawn a diagram showing the planned architecture. Cehteh raises concerns about codecs/plugins/effects in backend. After that there was some discussion about details. Cehteh suggests to place plugins in a extra box, gmerlin suggests that \'plugins' don't fit into the diagram, there should be "filters", "sources",..; Followed by some more discussion, showing that we basically agree and understand the design but the drawing needs some refinements.
_Ichthyo_ has drawn a diagram to show the planned architecture.
_Cehteh_ raises concerns about codecs/plugins/effects in backend.
After that there was some discussion about details.
_Cehteh_ suggests to place plugins in a extra box, _Gmerlin_ suggests that ``plugins'' don't fit into the diagram,
there should be ``filters'', ``sources'',..;
Followed by some more discussion, showing that we basically agree and understand the design but the drawing needs some refinements.
Conclusion:
Conclusion::
Good idea, needs some refinements, work in progress.
@ -122,47 +135,65 @@ Conclusion:
Call for Design
---------------
Ichthyo explains that the wants the overall design a bit more formalized. He put this topic on the agenda to remind that we have to work it out in link:DesignProcess[] and already started to make some design proposals.
Ichthyo explains that the wants the overall design a bit more formalized.
He put this topic on the agenda to remind that we have to work it out in link:/x/DesignProcess.html[the Design Process]
and already started to make some design proposals.
Conclusion:
Things need to be worked out in link:DesignProcess[], take a look and review it.
Conclusion::
Things need to be worked out as RfC -- take a look and review it.
Naming
------
Raffa, Velmont, goibhniu and others collected and managed proposed names past weeks which finally ended in a community voting. Results are at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_9fad0d1d10c23d38[]
Lumiera won, Lumiera.org is free and no one of in this meeting has objections against this name. Velmont offers to register and pay for the lumiera.org domain which will be hosted on our own server (see topic below). Hermanr raises concerns if it is ok when the name is registered on another site and by another person than the server, cehteh explains that he like this distribution where doable and no one other objects. Ichthyo asks about a short name for Lumiera which will be used for C++ namespaces and such kinds. After a short discussion we agree that we use the full name and no abbreviation. We now have to rename the source and the wiki. Anyone renames the sourcecode where he is responsible for. Cehteh will go over the pipapo.org wiki and rename things.
_Raffa_, _Velmont_, _Goibhniu_ and others collected and managed proposed names past weeks which finally ended in a community voting.
Results are at [purple]#<broken-URL>#. The name *Lumiera* won,
"`Lumiera.org`" is free and no one of in this meeting has objections against this name.
_Velmont_ offers to register and pay for the Lumiera.org domain which will be hosted on our own server (see topic below).
_Hermanr_ raises concerns if it is ok when the name is registered on another site and by another person than the server,
_Cehteh_ explains that he like this distribution of responsibilities where doable and no one other objects.
Ichthyo asks about a short name for Lumiera which will be used for C++ namespaces and such kinds.
After a short discussion we agree that we use the full name and no abbreviation.
We now have to rename the source and the wiki. Anyone renames the source code where he is responsible for.
_Cehteh_ will go over the `pipapo.org` wiki and rename things.
Finally we express our great thanks to the people who put the efforts into the name selection, thanks raffa, Velmont, goibhniu & co.
Finally we express our great thanks to the people who put the efforts into the name selection, thanks _Raffa_, _Velmont_, _Goibhniu_ & co.
Conclusion:
Projectname is Lumiera, we have a lot things to rename.
Conclusion::
Project name is *Lumiera*, we have a lot things to rename.
Project Server, setup, organization, administration
---------------------------------------------------
Some people gathered together and rented a server at http://www.hetzner.de[hetzner.de] which will host some free project pages and personal sites. Cehteh is the one who signed for the server and officially respobsible for it.
Some people gathered together and rented a server at https://www.hetzner.com/[hetzner.de] which will host some free project pages and personal sites.
_Cehteh_ is the one who signed for the server and will be officially responsible for it.
The server is split into isolated \'vservers' which are created as needed. Idea is to work cooperatively to get the best out of its resources.
The server is split into isolated »VServers« which are created as needed. Idea is to work cooperatively to get the best out of its resources.
For our projects (cinelerra.org and lumiera.org) we now need volunteers who help setting it up and administrating things. Velmont offered to help with lumiera.org, hermanr takes care of cinelerra.org, raffa will help with maintaining the webpages. oracle2025 will care for developer chroots, build and test environments. cehteh will make a page on pipapo.org which reflects the current server setup http://www.pipapo.org/pipawiki/RootServerSetup[]. There are still a lot jobs to do!
For our projects (cinelerra.org and lumiera.org) we now need volunteers who help setting it up and administrating things.
_Velmont_ offered to help with Lumiera.org, _Hermanr_ takes care of Cinelerra.org, _Raffa_ will help with maintaining the webpages.
_Oracle2025_ will care for developer `chroots`, build and test environments.
_Cehteh_ will make a page on pipapo.org which reflects the current server setup [purple]#<broken-URL>#. There are still a lot jobs to do!
Cehteh asked about how to manage emergency root access on the host/root server when he is unreachable. There where several suggestions between one root key for all who pay for the server to shared key schemes. We finally agreed that anyone who payed for the server can send a ssh key to ssh to be registered for emergency access.
_Cehteh_ asked about how to manage emergency root access on the host/root server when he is unreachable.
There where several suggestions between one root key for all who pay for the server to shared key schemes.
We finally agreed that anyone who payed for the server can send a ssh key to ssh to be registered for emergency access.
The concrete server setup will be worked out next days. Ideas are one frontend proxy and a shared nameserver. A shared nameserver, A developer vserver shared between all developers. Maybe a shared mail server.
The concrete server setup will be worked out next days. Ideas are one frontend proxy and a shared nameserver. A shared nameserver, A developer VServer shared between all developers. Maybe a shared mail server.
Hermanr asked about how to handle distribution of large media files. There was some discussion about bittorrent vs http. We concluded to work that out as needed.
_Hermanr_ asked about how to handle distribution of large media files. There was some discussion about Bittorrent vs HTTP. We concluded to work that out as needed.
In the forthcoming discussion about cehteh stresses that "it is a public server, if you place confidential information unencrypted on it, its you fault". Ssh keys shall be kept secret by the users but we can't enforce policies on those.
In the forthcoming discussion about security, _Cehteh_ stresses that ``it is a public server, if you place confidential information unencrypted on it, its you fault''.
SSH keys shall be kept secret by the users but we can't enforce policies on those.
Ichthyo asks about how to setup lumiera.org (wiki?), oracle2025 suggests webgit, cehteh explains that webgit isn't ready yet but should be useable in a few days (pipapo.org will use that too). Velmont suggest a \'real' website for the time when non-developers want to use it. Git will be set up on lumiera.org the same way as it is currently set up on pipapo.org.
_Ichthyo_ asks about how to setup lumiera.org (wiki?), oracle2025 suggests webgit, _Cehteh_ explains that webgit isn't ready yet but should be useble in a few days (pipapo.org will use that too).
_Velmont_ suggest a ``real'' website for the time when non-developers want to use it. Git will be set up on lumiera.org the same way as it is currently set up on pipapo.org.
Hermanr asked Velmont about some help moving the bugs.cinelerra.org over, this might be little challenging since it needs an MTA and other things.
_Hermanr_ asked _Velmont_ about some help moving the bugs.cinelerra.org over, this might be little challenging since it needs an MTA and other things.
Ichthyo asks about keeping the Lumiera project pages on pipapo.org until the server is ready, this is ok.
_Ichthyo_ asks about keeping the Lumiera project pages on pipapo.org until the server is ready, _Cehteh_ confirms this is OK.
Conclusions:
Conclusions::
We have our own server which now needs volunteers for maintenance. The projects will slowly move there, until ready Lumiera stays on pipapo.org.
@ -170,10 +201,16 @@ Conclusions:
GPL3 pros cons, license rationale
---------------------------------
Ichthyo and cehteh would like to investigate a license change to GPLv3, neither of us has experience with problems this
might raise. Questions are if we lock us out from potential libraries which are GPLv2 only or lock out possible contributors because of unforeseen patent clauses. The others here thinking that "GPLv2 or later" would be most-compatible. Gmerlin tells that he uses some "GPLv2 only" mplayer code in gavl which is itself "GPLv2 or later". Cehteh explains that "GPLv2 only" code is a problem, where "GPLv2 or later" is not. Ichthyo raises concerns that the Support library may need to be LGPL, cehteh mentions that it would likely be enough if we only apply that to the plugin-loader. After all it turns out that there is a lot of confusion, misunderstanding and interpretation used with licenses and no one of us knows for sure. Finally we conclude that the interpretation and license enforcement is ruled by the copyright owner.
_Ichthyo_ and _Cehteh_ would like to investigate a license change to GPLv3, neither of us has experience with problems this might raise.
Questions are if we lock us out from potential libraries which are GPLv2 only or lock out possible contributors because of unforeseen patent clauses.
The others here thinking that ``GPLv2 or later'' would be most-compatible. _Gmerlin_ tells that he uses some ``GPLv2 only'' MPlayer code in Gavl,
which is itself ``GPLv2 or later''. _Cehteh_ explains that ``GPLv2 only'' code is a problem, where ``GPLv2 or later'' is not.
_Ichthyo_ raises concerns that the Support library may need to be LGPL,
while _Cehteh_ mentions that it would likely be enough if we only apply that to the plugin-loader.
After all it turns out that there is a lot of confusion, misunderstanding and interpretation used with licenses
and no one of us knows for sure. Finally we conclude that the interpretation and license enforcement is ruled by the copyright owner.
Conclusion:
Conclusion::
Learn more about GPLv3, use GPLv2 or later and propose to switch to GPLv3 when we are ready to do public beta releases when possible.
@ -185,5 +222,5 @@ The next meeting will be at thuesday 3rd april 21:00GMT (if not rescheduled see
Ichthyo tells that Martin Ellison wrote he couldn't attend because of the time. So again we made a short discussion about changing/alternating timings to allow people in downunder/japan to attend. They have to speak up an make time suggestions.
Conclusion:
Conclusion::
Next meeting 3rd april 21:00GMT. But Aussies, please speak up if you want the time changed!

112
doc/devel/meeting_summary/2008-04-03.txt
View file

@ -20,7 +20,7 @@ Boilerplate
Organization of this meeting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* sakalli writes the protocol, ichthyo will help reviewing it
* _sakalli_ writes the protocol, ichthyo will help reviewing it
Recurring Topics
@ -32,20 +32,25 @@ Call for volunteers
-------------------
(which tasks are to do, how can we interest people...?)
There was a sense that there are people willing to help but they might need direction or cannot do actual coding. But there is also a lot of tasks that could be done by beginners and non-programmers. These tasks are important and if someone who is not a programmer is willing to take them on that leaves more time for the programmers. Examples of such tasks:
There was a sense that there are people willing to help but they might need direction or cannot do actual coding.
But there is also a lot of tasks that could be done by beginners and non-programmers.
These tasks are important and if someone who is not a programmer is willing to take them on that leaves more time for the programmers.
Examples of such tasks:
* Protocol writing
* maintaining to do lists and isolating tasks
* constant code and documentation review
* unit/functional testing
* header file "task force" - some fundamentals discussed by the developers on libopenvideo should find their way into basic .h files
* header file ``task force'' - some fundamentals discussed by the developers on libopenvideo should find their way into basic `.h` files
* installing and maintaining project tracking and automated builds/tests on the server
See http://www.lumiera.org/wiki/todo.html#Tasks[]
See [purple]#<URL for a TODO wiki used at that time>#
It was also noted that at current phase some basic development is still needed before we can accommodate a large number of coders doing small tasks and for now we need some subsystem owners. For GUI for example.
It was also noted that at current phase some basic development is still needed before we can accommodate
a large number of coders doing small tasks and for now we need some subsystem owners. For GUI for example.
To make it easier for "beginners" to get aquainted with the program it was decided that one *official Lumiera GIT repository* should be established.
To make it easier for ``beginners'' to get acquainted with the program it was decided that
one *official Lumiera GIT repository* should be established. (-> `git://git.lumiera.org/LUMIERA`)
@ -53,7 +58,16 @@ Project announcements/registration
----------------------------------
(freshmeat, gnu, etc...) any takers?
The discussion was about advertising the project on various sites. There were some concerns raised that it is too early to do too much publicity at the moment. That the right time should be shortly before the first public release. But there is also some value in registering to the project in planning/alpha stage to interest people such as prospective coders. It was noted that the http://www.linux.com/feature/126441[article on linux.com] resulted in a lot of people contacting ichthyo and cehteh. http://plot.bek.no/pipermail/piksel/2008-January/003328.html["I believe in Cinelerra"] by Leo Germani also generated a lot of traffic by developers. Some level of presence on mailing lists would be good although not too much just enough to indicate the project is going on.
The discussion was about advertising the project on various sites.
There were some concerns raised that it is too early to do too much publicity at the moment;
the right time should be shortly before the first public release. But there is also some value
in registering to the project in planning/alpha stage to interest people such as prospective coders.
It was noted that the
https://web.archive.org/web/20090601174640/http://www.linux.com/archive/feature/126441[article on Linux.com]
resulted in a lot of people contacting Ichthyo and Cehteh.
https://lists.cinelerra-cv.org/pipermail/cinelerra-skolelinux/2008-January/012806.html[»I believe in Cinelerra«]
by Leo Germani also generated a lot of traffic by developers.
Some level of presence on mailing lists would be good although not too much just enough to indicate the project is going on.
Conclusion: volunteer needed to coordinate publicity (not overly urgent, but helpful)
@ -62,51 +76,76 @@ Conclusion: volunteer needed to coordinate publicity (not overly urgent, but hel
Informal talk about the GUI
---------------------------
Firstly, as SimAV was not able to be present during the meeting a proposal by him was relayed by Ichthyo: GUI and backend should be completely separated and communicate via pipes. It was agreed that the GUI should be detached but some higher level message protocol rather than bare pipes should be used. Some comments:
Firstly, as SimAV was not able to be present during the meeting a proposal by him was relayed by Ichthyo:
GUI and backend should be completely separated and communicate via pipes.
It was agreed that the GUI should be detached but some higher level message protocol rather than bare pipes should be used.
Some comments:
* cehteh standalone gui is a nice to have, but implementation details have to be worked out
* gmerlin Video playback can be separated in a separate X connection
* cehteh suggests to start with an conventional, attached gui and just keep it in mind to make it detachable later
* rgareus IMHO you want to share memory for the video-frame buffer beween the player and backend - with pipes you'll go the video-jack way.
* _cehteh_: standalone gui is a nice to have, but implementation details have to be worked out
* _gmerlin_: Video playback can be separated in a separate X connection
* _cehteh_ suggests to start with an conventional, attached gui and just keep it in mind to make it detachable later
* _rgareus_ IMHO you want to share memory for the video-frame buffer between the player and backend - with pipes you'll go the video-jack way.
joelholdsworth is a new developer in the group and had showed interest in developing the GUI. he stated that he is interested in seeing a GUI that uses popular toolkits and that plays by the standards to create a consistent UI with the rest of the free desktop. For this reason he was advocating using GTKmm. There was no direct objections to GTKmm. Generally, there seems some preference for GTK. (Note this doesn't mean GNOME). Cehteh advocates the idea to use Lua-gtk, i.e. writing the GUI in a clean and lightweight scripting language.
_JoelHoldsworth_ is a new developer in the group and had showed interest in developing the GUI.
He stated that he is interested in seeing a GUI that uses popular toolkits and that plays by the standards
to create a consistent UI with the rest of the free desktop. For this reason he was advocating using GTKmm.
There was no direct objections to GTKmm. Generally, there seems some preference for GTK. (Note this doesn't mean GNOME).
Cehteh advocates the idea to use Lua-gtk, i.e. writing the GUI in a clean and lightweight scripting language.
Cario was suggested to be used for implementing the canvas in the timeline view.
The gui should provide a skeleton. Timeline and canvas should be controllable and extensible by plugins. Tracks can be nested. Use tiling windows and dockeable views and tools palettes. For example some configuration within session/renderpipeline may cause some pluggable elements to be added to the gui. A fader or a toggle/icon and so forth. Some plugins might render additional output (e.g. in previews). A video track renders thumbnails, automation curves on top.
The gui should provide a skeleton. Timeline and canvas should be controllable and extensible by plugins.
Tracks can be nested. Use tiling windows and dockable views and tools palettes.
For example some configuration within session / render-pipeline may cause some pluggable elements to be added to the gui.
A fader or a toggle/icon and so forth. Some plugins might render additional output (e.g. in previews).
A video track renders thumbnails, automation curves on top.
Workflow is another important aspect to take into account in the design. A lot of information needs to come from editors and users in the design process. Different thoughts about the workflow:
Workflow is another important aspect to take into account in the design.
A lot of information needs to come from editors and users in the design process.
Some thoughts about the workflow:
* Should not make a predefined workflow. Just produce a tool that can be adapted to different workflows. It can be predefined, but should not be fixed.
* We dont have the resources to develop a "workflow" in the formal manner, we will go the "propose and comment" route.
* We dont have the resources to develop a »workflow« in the formal manner, we will go the ``propose and comment'' route.
* We should take the best ideas from popular competing products such as Final Cut Pro, AVID, Premiere plus After Effects.
Customisation is deemed important. Some points brought up in the discussion:
* sakalli: would be great if we could provide a fcp configuration and a avid configuration besides the default configuration as well. That could lure a lot of users quickly. On the other side, too much flexibility can be be a problem as well.
* cehteh: yes .. but such things are prolly costly to setup .. we need volunteers for anything optional
* _sakalli_: would be great if we could provide a fcp configuration and a avid configuration besides the default configuration as well. That could lure a lot of users quickly. On the other side, too much flexibility can be be a problem as well.
* _cehteh_: yes .. but such things are prolly costly to setup .. we need volunteers for anything optional
* Customization should be possible without recompile, but not too cheap.
* There should be a working skeleton or some fixed anchor but gui operations should be bound to a scripting language to achieve customization.
* The whole gui in a script with some performance critical widgets coded in C/C++
* Some parts should just be customizable, other parts should be kept fixed.
* cehteh suggested to start out by making a \'high level' description with no language/toolkit in mind .. what widgets do we need etc and after that to work on the skeleton mockup.
* cehteh / hermanr: Lumiera should allow to choose theme independently from desktop .. because what you have as your desktop-theme doesn't suit for video editing in many cases ... see ardour
* cehteh suggested to start out by making a ``high level'' description with no language/toolkit in mind ...
what widgets do we need? etc and after that to work on the skeleton mockup.
* _cehteh_ + _hermanr_: Lumiera should allow to choose theme independently from desktop ...
because what you have as your desktop-theme doesn't suit for video editing in many cases ... see ardour
ichthyo brings up the role of customization for the middle layer and gives an overview of his plans for the new participants.
He had good experiences with a rule based aproach in various projects. He wants to embed a Prolog interpreter that can answer to "configuration queries". There is a "builder" component in the middle layer to derive the render nodes graph based on a "high level model", which is visible to the user (in the GUI) and based on these configuration queries.
_Ichthyo_ brings up the role of customization for the middle layer and gives an overview of his plans for the new participants.
He had good experiences with a rule based approach in various projects. He wants to embed a Prolog interpreter that can answer
to ``configuration queries''. There is a ``builder'' component in the middle layer to derive the render nodes graph based on
a ``high level model'', which is visible to the user (in the GUI) and based on these configuration queries.
Rationale for using prolog is: The rules are very readable because they rather represent facts and relations, not the way "how dings are done" but the way "how things are related". Example: how to configure some effects when the footage is interlaced. Additionally, we want to have some global swithces, which could control these rules, like "I want maximum quality", or "I want as much as possible set up automatically". The prolog rules are stored in the session and can be editd by advanced users. Of course, there is a set of basic rules. This aspect of customisation isn't exactly a GUI issue but it would have consequences for the GUI.
Rationale for using prolog is: The rules are very readable because they rather represent facts and relations,
not the way ``how things are done'' but the way ``how things are related''.
Example: how to configure some effects when the footage is interlaced.
Additionally, we want to have some global switches, which could control these rules,
like ``I want maximum quality'', or ``I want as much as possible set up automatically''.
The prolog rules are stored in the session and can be edited by advanced users.
Of course, there is a set of basic rules. This aspect of customisation isn't exactly a GUI issue
but it would have consequences for the GUI.
some discussion:
* joelholdsworth: so we just need a way of exposing properties. This is reasonably straightforward when all you want is value, colour, string etc.
* _joelholdsworth_: so we just need a way of exposing properties. This is reasonably straightforward when all you want is value, colour, string etc.
* rules within the middle layer/session could bind to some properties exposed in the GUI
* gmerlin joelholdsworth: Agree, but point out that this can become difficult
* cehteh joelholdsworth: skeleton and plugins who attach into some gui areas, so you can add custom widgets
* ichthyo: also the ability to attach "tags" to various objects, so the rules can bind on those tags
* cehteh: maybe a standard set of widgets, not really completely custom ones (gmerlin agrees)
* joelholdsworth: probably you need to be able to do both well
* joelholdsworth in many apps the value/colour/string set works perfectly well, but in luminierra the controls will likely need to be much richer
* _gmerlin_, _joelholdsworth_: Agree, but point out that this can become difficult
* _cehteh_ + _joelholdsworth_: skeleton and plugins who attach into some GUI areas, so you can add custom widgets
* _ichthyo_: also the ability to attach ``tags'' to various objects, so the rules can bind on those tags
* _cehteh_: maybe a standard set of widgets, not really completely custom ones (_gmerlin_ agrees)
* _joelholdsworth_: probably you need to be able to do both well
* _joelholdsworth_ in many apps the value/colour/string set works perfectly well,
but in Lumiera the controls will likely need to be much richer
Some brainstorming points about usability:
@ -116,20 +155,23 @@ Some brainstorming points about usability:
One extra point:
* we have agreed to make all of the big interfaces between the layers as plain C interfaces, because this is the most widely supported common denominator.
* we have agreed to make all of the big interfaces between the layers as plain C interfaces,
because this is the most widely supported common denominator.
GUI CONCLUSION
~~~~~~~~~~~~~~
* joelholdsworth is now the official GUI maintainer for Lumiera!
* sakalli, hermanr, ichthyo announced interest in contributing to discussions about GUI, workflows and usability. gmerlin noted that he knows some gtk secrets and is willing to help out here too.
* _joelholdsworth_ is now the official GUI maintainer for Lumiera!
* _sakalli_, _hermanr_, _ichthyo_ announced interest in contributing to discussions about GUI, workflows and usability.
* _gmerlin_ noted that he knows some GTK secrets and is willing to help out here too.
Froscon application
-------------------
http://www.froscon.org/[Froscon] is a small nice german open source exhibition that is very very technical oriented. Cehteh will be there as well as Ichthyo. Question is wether we should have a booth, perhaps together with some other interested media projects. Could ask Richard and the ffmpeg/mplayer people. End of call for papers is in june.
https://froscon.org/[Froscon] is a small nice german open source exhibition that is very very technical oriented.
Cehteh will be there as well as Ichthyo. Question is whether we should have a booth, perhaps together with some other interested media projects. Could ask Richard and the ffmpeg/mplayer people. End of call for papers is in june.
We made no decision about official presence but most likely there will be a developer meeting if nothing else.
@ -139,7 +181,7 @@ Timecode metadata discussion
----------------------------
This Discussion started out on the libopenvideo list: The question was wether we agree on one uniform format solution from decoder up to app level regarding timecode. And what this format would be: arithmetic or struct type. Regarding metadata (including type of timecode) the question is if we should work out a rather fixed data format, or go the route towards rather open description records.
Conclusion: Gmerlin does it the way it fits best for within the decoder, and Lumiera uses a more uniform time format for representing timecode in the higher app layers. Conversion functions will be concentrated in a library. Regarding metadata we will investigate further.
Conclusion: _Gmerlin_ does it the way it fits best for within the decoder, and Lumiera uses a more uniform time format for representing timecode in the higher app layers. Conversion functions will be concentrated in a library. Regarding metadata we will investigate further.
_A (shortended) digest of the timecode and metadata discussion is attached below_

134
doc/devel/meeting_summary/2008-05-08.txt
View file

@ -24,44 +24,45 @@ Organization of this meeting
Webpage-Infrastructure, Maintenance
-----------------------------------
Cehteh put this on topic because it's really urgent to bring up some
_Cehteh_ put this on topic because it's really urgent to bring up some
infrastructure to manage the information we produce.
The Lumiera pages on pipapo.org were always meant as intermediary
solution. Pipapo.org gets much spam on the moinmoin wiki and cehteh
solution. Pipapo.org gets much spam on the MoinMoin wiki and _Cehteh_
expresses that he wants to move pipapo.org to a new infrastructure
based on asciidoc and git he created
(see http://git.pipapo.org/uWiki.html[]). This system is barely useable
based on Asciidoc and Git he created
(see [purple]#`http://git.pipapo.org/uWiki.html` <broken-URL>#).
This system is barely usable
and needs lots of work to be completed. It would be nice to use it for
Lumiera too, if the others agree. Maintaining and extending
(scripting) needs someone who knows shell scripting and doesn't need
to be done by the core devs freeing their resources to work on
Lumiera. Cehteh expresses that none of the people who proposed to
Lumiera. _Cehteh_ expresses that none of the people who proposed to
help before showed up yet. WesLappy tells he might help (addendum not
this week, because he is busy).
Next there was a suggestion by cehteh to convert the tiddlywikis to
asciidoc. Ichthyo expresses that he likes the tiddlywikis, Joel
Next there was a suggestion by _Cehteh_ to convert the TiddlyWikis to
Asciidoc. Ichthyo expresses that he likes the TiddlyWikis, Joel
mentions that they feel a little odd. Generally we all agree that
they have some problems in sense of workflow and merging.
Ichthyo makes the suggestion to keep the tiddlywikis as scrapbook and
build up \'official' documentation based on their content in
whatever-we-use-then (asciidoc) documentation system. All agree on
_Ichthyo_ makes the suggestion to keep the TiddlyWikis as scrapbook and
build up ``official'' documentation based on their content in
whatever-we-use-then (Asciidoc) documentation system. All agree on
this approach.
Back to the new wiki, cehteh suggests to make stricter access rules to
prevent spam: "There will be a group of \'Validated' people which
following rules: only Validated people can edit general content and
\'Validated' people can add new people to \'Validated' themselves". That
Back to the new wiki, _Cehteh_ suggests to make stricter access rules to
prevent spam: ``There will be a group of `Validated' people which
following rules: only `Validated' people can edit general content and
`Validated' people can add new people to `Validated' themselves''. That
means that we can have a lightweight self-administrating
authentication where new people have to be introduced by someone who
is already there.
Ichthyo suggests to send a reply to Serge G. who send an introduction
_Ichthyo_ suggests to send a reply to Serge G., who send an introduction
to the cinelerra mailing list expressing that he would like to help.
Raffa will take care of content/design as much her time/knowledge permits.
_Raffa_ will take care of content/design as much her time/knowledge permits.
Conclusion
@ -69,25 +70,25 @@ Conclusion
* We really need someone to help with the webpage scripting.
* Documentation needs to be well organized and moved over.
* Content of the pipapo.org moinmoin wiki should be moved over.
* The new website should be well organized with a nice looking frontpage
* Content of the pipapo.org MoinMoin wiki should be moved over.
* The new website should be well organized with a nice looking front page
* All other documentation should be below that
Whats pending in link:DesignProcess[]
-------------------------------------
Whats pending in the DesignProcess / RfC
----------------------------------------
MistakestoAvoid
~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MistakestoAvoid[]
link:{rfc}_dropped/MistakestoAvoid.html[RfC: Mistakes to avoid in the Lumiera Design]
rick_777 wrote a "MistakestoAvoid" page which explains some possible
_rick_777_ wrote a "MistakestoAvoid" page which explains some possible
gotchas. We basically agree with most points there while we already
decided to address some things differently than he suggested. One
noteable difference is that we do not intent to provide a windows
version of Lumiera, which was explained in serveral places. Cehteh
notable difference is that we do not intent to provide a windows
version of Lumiera, which was explained in several places. _Cehteh_
added some comments to the page explaining some things.
@ -96,29 +97,28 @@ nothing more to discuss in \'Ideas', we go over to \'Drafts'
ArchitectureOverview
~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[]
link:{rfc}/ArchitectureOverview.html[RfC: Architecture Overview]
Cehteh suggests to put that drawing under version control, as .fig.
Ichthyo explains that it is already a .SVG and that he does not like
.fig.
_Cehteh_ suggests to put that drawing under version control, as .fig.
Ichthyo explains that it is already a `.SVG` and that he does not favour `.fig`.
Conclusion: We agree to keep it as .SVG, add it to the repository and
Conclusion:: We agree to keep it as `.SVG`, add it to the repository and
improve/complete it.
GitSubmoduleTransistion
~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/GitSubmoduleTransistion[]
link:{rfc}/GitSubmoduleTransistion.html[RfC: Git Submodules]
Another suggestion made by cehteh is to make managing of subprojects
within the sourcetree easier. Joel and ichthyo oppose that it is not
really needed now and needs more understanding of git. Ichthyo
suggests that the documentation might be separated into its own git,
Another suggestion made by _Cehteh_ is to make managing of subprojects
within the sourcetree easier. _Joel_ and _Ichthyo_ object that it is not
really needed now and needs more understanding of Git. _Ichthyo_
suggests that the documentation might be separated into its own Git,
he further explains that the things are not settled yet and we don't
know if we will some rearrangements and movements of files between
modules.
Conclusion: We transform the documentation to a submodule and see how
Conclusion:: We transform the documentation to a submodule and see how
it works. Other things will be decided much later.
@ -126,19 +126,19 @@ it works. Other things will be decided much later.
GlobalInitialization
~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/GlobalInitialization[]
link:{rfc}/GlobalInitialization.html[RfC: Global Init]
This topic is discussed and agreed on the link:DesignProcess[] page already.
This topic is discussed and agreed on the RfC page already.
Conclusion: finalize it
Conclusion:: finalize it
MasterRepositorySetup
~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MasterRepositorySetup[]
link:{rfc}/MasterRepositorySetup.html[RfC: Shared Master Repository]
Setting up an master repository was decided on the last meeting.
cehteh now set one up which also does some automatic, but intended
_Cehteh_ now set one up which also does some automatic, but intended
fragile merging from subsystem maintainer branches.
1. it updates automatically for the maintainers repo for conflict
free fast-forwards
@ -146,7 +146,7 @@ fragile merging from subsystem maintainer branches.
The others agree on the setup.
Ichthyo stresses that maintainers shall watch that their \'master'
Ichthyo stresses that maintainers shall watch that their `master'
branch should compile cleanly and pass the testsuite always, test
which are not operational should be tagged as PLANNED. We all
agree, while cehteh's master is currently in a broken state (note:
@ -155,9 +155,9 @@ fixed now).
Then a short discussion about building and synchronizing the docs
follows. Problem is that docs build in maintainer branches are
different for each branch, rsyncing them up to the server will always
change a lot of things. We agree that the \'official' docs shall be
build from the LUMIERA/master repository, preferably on the \'devel'
vserver which has to be set up.
change a lot of things. We agree that the ``official'' docs shall be
build from the LUMIERA/master repository, preferably on the "devel"
VServer which has to be set up.
Conclusions: Make this final, setup build environment in the devel
server and build docs there.
@ -166,28 +166,28 @@ server and build docs there.
NoBugFlags
~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/NoBugFlags[]
link:{rfc}/NoBugFlags.html[RfC: NoBug flags]
Defining a debugging control hierarchy. This is work in progress and
cehteh explains that he works it out and deploys it, this depends on
the link:GlobalInitialization[] decided earlier.
_Cehteh_ explains that he works it out and deploys it, this depends on
the link:{rfc}/GlobalInitialization.html[GlobalInitialization] decided earlier.
Conclusion: accepted, finish and finalize it.
Conclusion:: accepted, finish and finalize it.
Further Technical Discussion
----------------------------
Ichthyo asks how the GUI will be pulled up. Since he didn't attend IRC
_Ichthyo_ asks how the GUI will be pulled up. Since he didn't attend IRC
discussions recently he has no information yet whats going on. We
explain him that we already made some discussions. Integrate the GUI
into the build system probably linked as library, nothing finally
decided yet. Communication will go over the plugin/interface facility
(Plain C API). This things should be worked out and documented in
link:DesignProcess[].
link:/x/DesignProcess.html[RfCs].
Cehteh made a small tool `./admin/headercheck` which will gradually
_Cehteh_ made a small tool `./admin/headercheck` which will gradually
extended to proof that headers are sufficiently selfstanding.
@ -195,42 +195,42 @@ extended to proof that headers are sufficiently selfstanding.
Progress
--------
Cehteh finished low level file handling and working in mmaping and
_Cehteh_ finished low level file handling and working on mmapping and
frameprovider next. When thats finished, the finalization of the
Plugin loader and interface definition things is the most urgent thing.
Ichthyo works on the builder internals and next on some sort of
"connection manager".
_Ichthyo_ works on the builder internals and next on some sort of
``connection manager''.
Joel goes on with GUI programming and integrating it into the source
_Joel_ goes on with GUI programming and integrating it into the source
tree next.
Gmerlin and cehteh discuss about how to handle the index files which
avdecoder uses internally. cehteh would like to manage them in the
_Gmerlin_ and _cehteh_ discuss about how to handle the index files which
avdecoder uses internally. _cehteh_ would like to manage them in the
Lumiera backend to, because filehandles are a precious resource.
Gmerlin explains that this index files are just loaded and kept in
_Gmerlin_ explains that this index files are just loaded and kept in
memory. So this poses no problem for filehandle exhaustion. We will
discuss this further via email.
Cehteh suggests that we should think about some kind of
_Cehteh_ suggests that we should think about some kind of
preferences/registry sometime next to store default configs.
Following a discussion about how messages are passed between GUI and
A a discussion followed about how messages are passed between GUI and
core. Generally we will use the interfaces defined by the plugin
system. Gmerlin says that he uses message queues in \'gmerlin', Joel
system. _Gmerlin_ says that he uses message queues in `gmerlin', _Joel_
requests that a lot of things should be done synchronous and he wants
to avoid message queues. Cehteh suggests to use use the scheduler for
to avoid message queues. _Cehteh_ suggests to use use the scheduler for
GUI things too. For the parts where the GUI interacts with the high
level proc model ichthyo and joel agree on working something
(synchronous) out. Ichthyo stresses that the edit core is not
level proc model _ichthyo_ and _joel_ agree on working something
(synchronous) out. _Ichthyo_ stresses that the edit core is not
threadsafe by design and relies on the backends scheduler.
The underlying builder might sometimes to expensive for synchronous
calls (ichthyo plans a rule system there) this needs to be worked out.
calls (_ichthyo_ plans a rule system there) this needs to be worked out.
Ichthyo explains that the builder needs to detect cycles and check if
_Ichthyo_ explains that the builder needs to detect cycles and check if
the high level model is translateable into the low level model (in
case plugins git removed and so on). Parts in the render graph which
are not \'doable' should be flagged as erroneous but not dropped since
are not ``doable'' should be flagged as erroneous but not dropped since
one doesn't want to loose project information when loading a project
on a machine with different installed plugins. In any case it should be
possible that the GUI gets immediate synchronous feedback for such

46
doc/devel/meeting_summary/2008-06-06.txt
View file

@ -23,41 +23,61 @@ Discuss Ideas and Drafts in design process
------------------------------------------
There are no new design proposals and no proposals that can be finalized.
Ichthyo points out that he's about to work out the details of some of his proposals, which are currently in "idea" state. Following that, most of the meeting is spent on discussing the details of two of these proposals.
Ichthyo points out that he's about to work out the details of some of his proposals, which are currently in `Idea' state.
Following that, most of the meeting is spent on discussing the details of two of these proposals.
Idea: Design the Render Nodes interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DesignRenderNodesInterface[]
link:{rfc}/DesignRenderNodesInterface.html[RfC / Call for a Render Node interface]
*Cehteh* points out that, as we are in the pre-alpha phase, interfaces may be growing on-demand. Later on, interface versions will be numbered. If needed, we could add a special "draft" or "experimental" tag, or, alternatively, use the common numbering scheme, where odd major version numbers denote the development line of an interface.
_Cehteh_ points out that, as we are in the pre-alpha phase, interfaces may be growing on-demand.
Later on, interface versions will be numbered. If needed, we could add a special ``draft'' or ``experimental'' tag,
or, alternatively, use the common numbering scheme, where odd major version numbers denote the development line of an interface.
*Ichthyo* agrees, but adds he also meant "interface" in this proposal in a wider sense, like in "what do we need and require from a processing node". Knowing how generally Lumiera will handle the processing nodes while rendering helps him with defining and implementing the builder
_Ichthyo_ agrees, but adds he also meant ``interface'' in this proposal in a wider sense,
like in ``what do we need and require from a processing node''.
Knowing how generally Lumiera will handle the processing nodes while rendering helps him
with defining and implementing the builder
__Conclusion__: "currently in work". For now, grow interfaces on demand.
Conclusion:: ``currently in work''. For now, grow interfaces on demand.
Idea: Placement Metaphor used within the high-level view of Proc-Layer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor[]
link:{rfc}/ProcPlacementMetaphor.html[RfC: Placement Metaphor]
In the course of the discussion, *Ichthyo* explains the rationale
In the course of the discussion, _Ichthyo_ explains the rationale
* one common mechanism for sticking objects together and putting them into the session
* either specify the "placement"-parameters (time, output destination, track) directly, link to another object's parameters, or derive some or all of those values from the context (up the tree of tracks)
* either specify the ``placement''-parameters (time, output destination, track) directly,
link to another object's parameters, or derive some or all of those values from the context (up the tree of tracks)
* ability to build a system of high-level media objects (clips, effects...) which re-adjust automatically on change
* extensible to handle or derive some parameters based on conditions and rules, e.g. for semi-automatic wiring of the output destination based on tags
* extensible to handle or derive some parameters based on conditions and rules,
e.g. for semi-automatic wiring of the output destination based on tags
*Joelholdsworth* is concerned that this proposal may go too far and tries to tie things together which aren't really connected. While basically it's no problem having the time position of a clip either absolute, or derived by a link to another object, he can't see a clear benefit of controlling sound pan or video layer order from the placement. Pan, for example, is just an parameter value or interpolated curve, similar to colour correction or gamma adjustment. For the gui, he points out, it's probably better to stick to the object metaphor, so start time, output, layer number or sound pan would be properties of the object.
_Joelholdsworth_ is concerned that this proposal may go too far and tries to tie things together which aren't really connected.
While basically it's no problem having the time position of a clip either absolute, or derived by a link to another object,
he can't see a clear benefit of controlling sound pan or video layer order from the placement.
Pan, for example, is just an parameter value or interpolated curve, similar to colour correction or gamma adjustment.
For the gui, he points out, it's probably better to stick to the object metaphor, so start time, output,
layer number or sound pan would be properties of the object.
But that's exactly what Ichthyo wants to avoid. Obviously, this would be the standard solution employed by most current editing apps, and works reasonably well in average cases. But he is looking for a solution which covers this standard case, but also doesn't get into the way when dealing with advanced compositing, working with spatial sound systems (Ambisonics, Wave Field Synthesis) or stereoscopic (3D) video.
But that's exactly what _Ichthyo_ wants to avoid.
Obviously, this would be the standard solution employed by most current editing apps, and works reasonably well in average cases.
But he is looking for a solution which covers this standard case, but also doesn't get into the way when dealing with advanced compositing,
working with spatial sound systems (Ambisonics, Wave Field Synthesis) or stereoscopic (3D) video.
On the whole, there is no conclusion yet. Certainly, this proposal needs more discussion, parts need to be defined much more clear (esp. the "Pro" arguments), maybe parts of the functionality should be separated out.
On the whole, there is no conclusion yet.
Certainly, this proposal needs more discussion, parts need to be defined much more clear (esp. the "Pro" arguments),
maybe parts of the functionality should be separated out.
While in this discussion, several aspects of the cooperation of GUI and Proc layer are considered.
* it is not necessary to make all of the Placement proposal visible to the GUI (and the user). Proc layer may as well provide a simplyfied and hard wired API for the most common properties (layer index, pan) and only use this part of the Placement concept for building and wiring the nodes.
* it is not necessary to make all of the Placement proposal visible to the GUI (and the user).
Proc layer may as well provide a simplified and hard wired API for the most common properties (layer index, pan)
and only use this part of the Placement concept for building and wiring the nodes.
* the adjustment of objects linked together by a placement can be handled as follows:
. GUI notifies Proc of a position/parameter change of one object and gets immediate, synchronous feedback (OK or fail)
. Proc detects the other linked objects affected by the change and notifies GUI (both synchronous and asynchronous is possible) to update information regarding those objects

65
doc/devel/meeting_summary/2008-07-06.txt
View file

@ -23,7 +23,7 @@ Boilerplate
Organization of this meeting
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* dmj726 intends to write the protocol
* ichtyo is chairman
* _Ichthyo_ is chairman
* there is no agenda, so this is a freeform meeting
Leftovers from last meeting
@ -37,18 +37,21 @@ Because there are quite some new participants, an introduction of the project Lu
There are 3 core devs:
* ichthyo: proc layer, render graph, in the middle, C++, he maintains scons
* cehteh: backend serving data (from filesystem and so on), manages threads, using C, Posix System programming, maintains autotools and git
* joelholdsworth: GUI in C++/Gtkm
* _Ichthyo_: proc layer, render graph, in the middle, C++, he maintains SCons
* _Cehteh_: backend serving data (from filesystem and so on), manages threads, using C, Posix System programming, maintains autotools and git
* _JoelHoldsworth_: GUI in C++/Gtkmm
Other people involved:
* rcbarnes: ui designer and coder
* raffa: web content
* Simav: gives a hand when and where he can
* Teld: web infrastructure
The foundations of the design are already done but a lot of detail needs to be worked out. cehteh and ichtyo provide a non exhaustive list.
* _rcbarnes_: ui designer and coder
* _raffa_: web content
* _Simav_: gives a hand when and where he can
* _Teld_: web infrastructure
cehteh:
The foundations of the design are already done but a lot of detail needs to be worked out.
_Cehteh_ and _Ichtyo_ provide a non exhaustive list.
_Cehteh_:
* improvement of the testsuite (simple Bash)
* start of a worker thread manager (Posix knowledge required)
@ -58,35 +61,53 @@ cehteh:
* system administration
* setup of a build/test environment on the server
* setup and maintain postfix/dovecot by a mail administrator
ichtyo:
_Ichthyo_:
* asset management (keeping track of all media files, captures, clips, scenes)
* session loading saving and the issues of compound documents
* session structure related issues to be able to Import/Export/Connect via e.g. OSC (Open Sound Control) or JACK
* flesh out the more high level "edit operations" and the interface to UNDO
* Prolog integration after the first integration round has been reached. The Prolog interpreter will do some of the more advanced configuration (example: if effect XYZ is used, then deinterlace beforehand).
* flesh out the more high level ``edit operations'' and the interface to UNDO
* Prolog integration after the first integration round has been reached.
The Prolog interpreter will do some of the more advanced configuration
(example: if effect XYZ is used, then deinterlace beforehand).
* integration with some sort of production support software (like Celtx)
cehteh emphasizes that Lumiera is an open project, so anybody can jump in where he sees fit as long as he communicates and acknowledges with the persons involved. ichtyo points out that the plugin structure is very important: anything that is not legally completely clean (proprietary), should be factored out into a sister project and be loaded as plugin.
_Cehteh_ emphasizes that Lumiera is an open project, so anybody can jump in where he sees fit
as long as he communicates and acknowledges with the persons involved.
_Ichthyo_ points out that the plugin structure is very important: anything that is not legally completely clean
(e.g. proprietary technology), should be factored out into a sister project and be loaded as plugin.
Issues and questions that come up
---------------------------------
* handling of config errors.
When the configuration has a syntax error, in 90% of the cases there will be no possibility to do anything sane. Therefore, the config system will be built to log a warning and the user code does not need to care. The user just gets an alert and the application continues to work.
* handling of config errors. +
When the configuration has a syntax error, in 90% of the cases there will be no possibility to do anything sane.
Therefore, the config system will be built to log a warning and the user code does not need to care.
The user just gets an alert and the application continues to work.
* scripting language.
There will be a scripting interface. ichtyo does not want scripts everywhere, only at well defined interfaces. That implies also that scripts cannot just do anything, only that what is permitted in a controlled way. The meeting agrees on that. cehteh wants one default language and proposes Lua: light, simple.
+
--
There will be a scripting interface. _Ichthyo_ does not want scripts everywhere, only at *well defined interfaces*.
That implies also that scripts _cannot just do anything,_ only that what is permitted in a controlled way.
The meeting agrees on that. _Cehteh_ wants one default language and proposes Lua: light, simple.
Other members suggestions: Python, Ruby, Scheme. However, Python and Ruby are very slow. Scheme has many variants.
--
* editing on small devices (eeePC)
Problem: video editors GUIs are some of the most elaborate and complicated GUIs. However, basic functions consist of only a few buttons. Proxy editing could be a solution. It is decided that it is not a primary goal now. First the basics have to be implemented.
* editing on small devices (eeePC) +
Problem: video editors GUIs are some of the most elaborate and complicated GUIs.
However, basic functions consist of only a few buttons. Proxy editing could be a solution.
It is decided that it is not a primary goal now. First the basics have to be implemented.
* uWiki.
* uWiki. +
uWiki is the glue between a markup driver (Asciidoc) and revision control (git). Haserl with Bash is used now. Haserl appears to have problems with conditional includes. Its limits have been reached while prototyping. Lua could very well be a valid replacement. It will be investigated. PHP is rejected because it is not stable and suffers from serious security problems.
* \'musical\' timeline in bars and beats
The questions of syncing and linking things together are already on the core agenda: the so-called placement concept. Discussion is still going on, especially with the GUI developer joelholdsworth. See for detailed information: http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor[]
* ``musical'' timeline in bars and beats +
The questions of syncing and linking things together are already on the core agenda: the so-called placement concept.
Discussion is still going on, especially with the GUI developer _JoelHoldsworth_.
See for detailed information: link:{rfc}/ProcPlacementMetaphor.html[RfC Placement Metaphor]
Next meeting

14
doc/devel/meeting_summary/2008-09-04.txt
View file

@ -29,11 +29,11 @@ There are no leftovers
Mailing Lists
-------------
* any improvements should be reported to cehteh
* need volunteers to be moderators. The only volunteers are cehteh and joelholdsworh_
* any improvements should be reported to _cehteh_
* need volunteers to be moderators. The only volunteers are _cehteh_ and _joelholdsworh_
* moderating the ML might not be that big a job - we might not get that much spam
* it's preferable to allow people to post to the mailing list even if they're not subscribed
* cehteh eventually wants the mailing list to interact with uwiki.
* _cehteh_ eventually wants the mailing list to interact with uwiki.
Plugin Interfaces
-----------------
@ -41,7 +41,7 @@ Plugin Interfaces
* this includes enumerating structured data within the plugins. It might sometimes be desirable to store this in a text file, but in this case still the list will be exported through the interfaces. If this were not the case, it would not be possible to make plugins which are wrappers of LADSPA plugins for example.
* For a lumiera plugin there is only one entry point, thats an interface itself which bootstraps all the other interfaces in that plugin.
Lib Dependancy Problems
Lib Dependency Problems
-----------------------
* we've agreed to stick to one compatibility level: Debian/Lenny for perhaps up to 3 years from now
* others will be supported - RedHat etc.
@ -49,7 +49,7 @@ Lib Dependancy Problems
Builds and Buildbot
-------------------
* ichthyo asks for help setting up a test/build server
* We now have build scripts based on scons and autotools.
* We now have build scripts based on SCons and Autotools.
* All current build systems have different problems.
* ichthyo will take care of the Debian packages for Lumiera and NoBug
@ -69,6 +69,6 @@ The next meeting will be held Thursday, 2 oct 21:00 utc.
Comment
~~~~~~~
re "ichthyo asks for help setting up a test/build server" for "Debian"
re ``ichthyo asks for help setting up a test/build server'' for "Debian"
see "Build Server" at http://www.pipapo.org/pipawiki/Lumiera/GuiBrainstorming?action=edit&editor=gui[]
see "Build Server" at [purple]#<broken-URL>#

100
doc/devel/meeting_summary/2008-10-10.txt
View file

@ -11,7 +11,7 @@ __Participants__
* ichthyo
* joelholdsworth
* alcarinque
* !KenSentMe
* KenSentMe
* Plouj
* raffa
* thorwil
@ -30,7 +30,7 @@ The Lumiera Logo
----------------
Summary of the situation: discussion regarding a logo for Lumiera is going on sporadically since quite some time. Several people from the community have made proposals. Also, there was discussion about the criteria a logo would have to fulfil. Especially the core devs raised the bar and required quite some professional level of design. On the contrary, several members of the community were concerned that such a demanding attitude will hinder creativity in a domain which is far off from coding. Moreover, many people complained they are really excited about Lumiera and strongly want to participate in some manner, but find it very difficult in the current phase of the project to give any valuable contribution.
This summer, one of the proposals by http://farm4.static.flickr.com/3060/2927333034_ac94be80ea_b.jpg[Leandro Ribeiro] gained some popularity and especially was embraced by two of the core devs, while the GUI core dev wasn't convinced and http://www.pipapo.org/pipawiki/JoelHoldsworth/LogoThoughts[explained] his reservation. Prior to this meeting some people joined a brainstorming session and came up with http://www.pipapo.org/pipawiki/Lumiera/Logos?action=AttachFile&do=get&target=combo.png[another design] compiled of several proposals, which could meet the acceptance of the core devs. At the same time, Raffa made an argument for conducting a public contest, similar to the one which gave us the name of Lumiera. The situation for Lumiera is somewhat special. Usually, the community builds when the product is already minimally usable; we can't have users for now, but we have a lot of prospective users.
This summer, one of the proposals by link:{imgg}/LumieraLogoLeonardoRiberio.2008.jpg[Leandro Ribeiro] gained some popularity and especially was embraced by two of the core devs, while the GUI core dev wasn't convinced and explained [purple]#<broken-URL># his reservation. Prior to this meeting some people joined a brainstorming session and came up with _another design_([purple]#broken-URL `combo.png`#) compiled of several proposals, which could meet the acceptance of the core devs. At the same time, Raffa made an argument for conducting a public contest, similar to the one which gave us the name of Lumiera. The situation for Lumiera is somewhat special. Usually, the community builds when the product is already minimally usable; we can't have users for now, but we have a lot of prospective users.
Thus, while basically it would be possible for the core devs to shorten the process by just picking a design which is acceptable for all, maybe after augmenting it a little, several of the arguments articulated this far are in favour of a more formal decision by a contest:
@ -48,7 +48,7 @@ Conclusion
There will be a Lumiera Logo contest.
* we should further discuss requirements on the Mailinglist until the end of the next week
* the '''deadline for submissions''' will be the next meeting (Nov 12 2008)
* the *deadline for submissions* will be the next meeting (Nov 12 2008)
* then, after a pre-selection phase, the vote shall be conducted prior to the December meeting.
Some minimal technical requirements will be enforced:
@ -63,7 +63,7 @@ Some minimal technical requirements will be enforced:
Besides, we give some artistic guidelines
* it should be recognisable
* it should contain something like a sign, not just "Lumiera" in a fancy font
* it should contain something like a sign, not just ``Lumiera'' in a fancy font
* it should not rely on transparencies, gradients and subtle shades,
* it should be viable, possibly work well in different presentation styles, able to be simplified as well as graphically augmented
@ -75,22 +75,22 @@ Raffa volunteers to help organizing the contest and the voting.
Recurring Topics: design proposals
----------------------------------
Discussion of open http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process] drafts.
Discussion of open link:/x/DesignProcess.html[design process] drafts.
Mistakes to avoid
~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MistakestoAvoid[Mistakes to avoid in the Lumiera Design]
link:{rfc}/MistakestoAvoid.html[RfC: Mistakes to avoid in the Lumiera Design]
We are carrying this one along since quite some time and we'd like to get rid of it, either by reworking it or by dropping it as-is. Because it contains a mixture of things
* we fully agree to 80% of the statements made there, but we think those statements are so very basic and self-evident as to be considered off-topic here. We are aware of the recurring problems with open source video editing. That's why we are here.
* the proposal draws conclusions on two technically substantial points, at which we don't agree. And it fails to provide sufficient (technically sound) arguments to prove these statements.
* the proposal draws conclusions on two technically substantial points, at which we don't agree. And it fails to provide sufficient (technically sound) arguments to underpin these statements.
While it is certainly ''desirable'' to be cross-platform as much as possible and especially '''target Microsoft Windows''', we don't see much possibilities with today's mainstream technology to build an application which is as technologically demanding as a video editor is. We would end up developing two or even three sister applications, or we are forced to sacrifice performance for portability. When put up to face such options, we have a clear preference to concentrate on a really free and open platform.
While it is certainly _desirable_ to be cross-platform as much as possible and especially *target Microsoft Windows*, we don't see much possibilities with today's mainstream technology to build an application which is as technologically demanding as a video editor is. We would end up developing two or even three sister applications, or we are forced to sacrifice performance for portability. When put up to face such options, we have a clear preference to concentrate on a really free and open platform.
While it is certainly ''desirable'' to make the application as robust as possible, we don't see how '''using multiple separate processes''' could help us with this goal ''without creating major scalability or performance problems'' due to the use of shared memory. And, yet more important: we don't share the basic assumption made in the proposal, namely that video processing is inherently dangerous. We think the basic algorithms involved are sufficiently well-known and understandable to implement them in a sound manner.
While it is certainly _desirable_ to make the application as robust as possible, we don't see how *using multiple separate processes* could help us with this goal _without creating major scalability or performance problems_ due to the use of shared memory. And, yet more important: we don't share the basic assumption made in the proposal, namely that video processing is inherently dangerous. We think the basic algorithms involved are sufficiently well-known and understandable to implement them in a sound manner.
__Conclusion__: drop it
[underline]#Conclusion#: drop it
on the question of separate processes
@ -101,8 +101,8 @@ The only practical solution would be to separate the GUI. Separating backend and
Tag Clouds
~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/TagCloudsOnResources[Tag clouds on resources]
Tags are considered very important. Meanwhile, we have a much more advanced proposal, which superseeds this one: http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DelectusShotEvaluator["Delectus"]
link:{rfc}/TagCloudsOnResources.html[Tag clouds on resources] +
Tags are considered very important. Meanwhile, we have a much more advanced proposal, which superseeds this one: link:/x/Delectus.html[»Delectus«]
__Conclusion__: drop it
@ -111,7 +111,7 @@ __Conclusion__: drop it
Overview of Lumiera Architecture
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview[Architecture Overview]
link:{rfc}/ArchitectureOverview.html[Architecture Overview]:
The purpose of this drawing to give an first impression what subsystem is where and what the names mean. Since discussed last time, Ichthyo re-arranged the plugins as requested and added some details for the backend. Joelholdsworth points out that it's OK for him to show the GUI just as a single block here (and of course the GUI has much more internal structure). Cehteh adds that maintaining this drawing surely is a moving target, so we better remove the rendered image and just retain the textual description and link to the source (SVG), which is in GIT.
__Conclusion__: accept it, change the image to a link
@ -121,7 +121,7 @@ __Conclusion__: accept it, change the image to a link
EDLs as Meta-Clips
~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/EDLsAreMetaClips[EDLs are meta-clips]
link:{rfc}/EDLsAreMetaClips.html[EDLs are meta-clips] +
This is just a high-level proposal, which doesn't go into technical details of implementing nested EDLs. It just poses the question "do we want to treat nested EDLs as being meta-clip" -- which we do.
__Conclusion__: accepted
@ -131,7 +131,7 @@ __Conclusion__: accepted
The Builder
~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcBuilder[Builder in the Proc-Layer]
link:{rfc}/ProcBuilder.html[Builder in the Proc-Layer] +
Similar to the previous one, this is a high-level proposal. It covers the fundamental approach Ichthyo takes within the Proc-Layer. Cehteh adds that he agrees to 98% and the remaining 2% are just matter of favour. Personally, he would have preferred one large graph which gets garbage collected (instead of the segmented graph)
__Conclusion__: accepted
@ -141,7 +141,7 @@ __Conclusion__: accepted
High-level Model
~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcHighLevelModel[Overview of the High-level model within the Proc-Layer]
link:{rfc}/ProcHighLevelModel.html[Overview of the High-level model within the Proc-Layer] +
Cehteh queries if this shouldn't be better moved over to the documentation? He is fine with the contents, but it seems to be a bit voluminous for a design proposal. Ichthyo asks to leave it there just for now, as he feels it still needs review.
__Conclusion__: leave it for now, maybe retract it from the design proposals and file it as documentation?
@ -151,8 +151,16 @@ __Conclusion__: leave it for now, maybe retract it from the design proposals and
Lua scripting language
~~~~~~~~~~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ScriptingLanguage[use Lua as required scripting language]
All core devs agree with this decision. Joelholdsworth points out that he is fine with Lua, just he didn't want to write the GUI in it. Ichthyo adds that Lua is probably the best choice from today's mainstream scripting languages, because it is very lightweight. He further points out, that having Lua as ''required'' scripting language doesn't rule out using other popular languages (Python, Ruby) for scripting. Just they aren't required for running Lumiera. Cehteh will have a look at the details as soon as possible, but has currently other more urgent things in the queue. (Plouj shows interest to help here)
link:{rfc}/ScriptingLanguage.html[use Lua as required scripting language] +
All core devs agree with this decision.
_Joelholdsworth_ points out that he is fine with Lua, just he didn't want to write the GUI in it.
_Ichthyo_ adds that Lua is probably the best choice from today's mainstream scripting languages,
because it is very lightweight. He further points out, that having Lua as _required_ scripting language
does not rule out using other popular languages (Python, Ruby) for scripting.
Just they aren't required for running Lumiera.
_Cehteh_ will have a look at the details as soon as possible,
but has currently other more urgent things in the queue.
(_Plouj_ shows interest to help here)
__Conclusion__: accepted
@ -161,8 +169,8 @@ __Conclusion__: accepted
Time Handling
~~~~~~~~~~~~~
http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/time_handling[time handling]
A long standing proposal; meanwhile we've decided to build on GAVL, which is now reflected in the text of this proposal too. Ichthyo points out he changed the rounding rule in this proposal from "mathematical" to "floor (x+0.5)". Cehteh asks if we should use a thin library layer on top of gavl, to centralize all the time calculations. There seems to be agreement that this should actually be done ''on demand.'' Joelholdsworth sais sometimes he'd prefer to have a simple raw type to represent time, because it makes calculations much easier. Ichthyo adds that internally (within the layers, but not on interfaces) one could use a thin C++ wrapper with overloaded operators, which is default-convertible to gavl_time.
link:{rfc}/TimeHandling.html[time handling] +
A long standing proposal; meanwhile we've decided to build on GAVL, which is now reflected in the text of this proposal too. Ichthyo points out he changed the rounding rule in this proposal from "mathematical" to "floor (x+0.5)". Cehteh asks if we should use a thin library layer on top of gavl, to centralize all the time calculations. There seems to be agreement that this should actually be done _on demand._ Joelholdsworth says sometimes he'd prefer to have a simple raw type to represent time, because it makes calculations much easier. Ichthyo adds that internally (within the layers, but not on interfaces) one could use a thin C++ wrapper with overloaded operators, which is default-convertible to gavl_time.
__Conclusion__: accepted
@ -171,7 +179,7 @@ Note: the proposed rigid testsuite for time handling is necessary only when we i
Interface naming convention
~~~~~~~~~~~~~~~~~~~~~~~~~~~
See the design proposal http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/InterfaceNamespaces[Interface Namespaces]. While working on the plugin loader, '''Cehteh''' and '''nasa''' did some brainstorming about a plugin naming scheme and how to get unique interface identifiers. The idea is to use a distinctive prefix, like a condensed organisation domain or email name, or a GPG fingerprint or even a UID, followed by the interface namespace hierarchy. These would be combined into a single identifier (valid C name). The intention is to get non-ambiguous names, yet avoiding the need of a central registry.
See the design proposal link:{rfc}/InterfaceNamespaces.html[Interface Namespaces]. While working on the plugin loader, _Cehteh_ and _nasa_ did some brainstorming about a plugin naming scheme and how to get unique interface identifiers. The idea is to use a distinctive prefix, like a condensed organisation domain or email name, or a GPG fingerprint or even a UID, followed by the interface namespace hierarchy. These would be combined into a single identifier (valid C name). The intention is to get non-ambiguous names, yet avoiding the need of a central registry.
__Conclusion__: accepted
@ -180,13 +188,23 @@ general Topics
Config System
-------------
'''cehteh''' landed the first version of this subsystem and asked for review and testing. Currently it's "work with no progress", but it is basically usable (you can get values, you can set values by environment variables, but you can't persist). It should be augmented on demand, e.g. by adding the support for more value types (value types are a hint how to parse, and link the parsed value to a given C type).
_Cehteh_ landed the first version of this subsystem and asked for review and testing. Currently it's ``work with no progress'', but it is basically usable (you can get values, you can set values by environment variables, but you can't persist). It should be augmented on demand, e.g. by adding the support for more value types (value types are a hint how to parse, and link the parsed value to a given C type).
Use of Namespaces
-----------------
Currently there is no clear uniform rule regarding namespaces use. *Joelholdsworth* places his code within lumiera::gui and below. He points out that external libs like Cairo, GTK, GLib will bring in their hierarchies and all of Lumiera should comply and put anything below a lumiera:: root. On the contrary, *Ichthyo* deliberately moved his implementation code away from the central lumiera:: interface hierarchy into shallow namespaces and avoids nesting. He argues that having all code below lumiera:: effectively makes this namespace global or forces it to be void of any function; rather he'd prefer to import every interface explicitly into the implementation namespace. *Cehteh* argues that having a global lumiera::, even if empty, would mark a general claim and stand for the uniformity of the project. Generally, there should be some correspondence between folders and namespaces.
Currently there is no clear uniform rule regarding namespaces use.
_JoelHoldsworth_ places his code within lumiera::gui and below.
He points out that external libs like Cairo, GTK, GLib will bring in their hierarchies
and all of Lumiera should comply and put anything below a lumiera:: root.
On the contrary, _Ichthyo_ deliberately moved his implementation code away from the central `lumiera::`
interface hierarchy into shallow namespaces and avoids nesting.
He argues that having all code below `lumiera::` effectively makes this namespace global or forces it to be void of any function;
rather he'd prefer to import every interface explicitly into the implementation namespace.
_Cehteh_ argues that having a global `lumiera::`, even if empty,
would mark a general claimand stand for the uniformity of the project.
Generally, there should be some correspondence between folders and namespaces.
No conclusion yet, to be discussed further.
@ -194,9 +212,13 @@ No conclusion yet, to be discussed further.
Interface Definition Language
-----------------------------
In his work on the plugin loader, '''Cehteh''' created a first draft how to export an interface, and calls for review. An example can be found in http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=tests/backend/test-interfaces.c;h=fb1c4d30a34414767a313d24df60e679c96ad2a7;hb=7323114e77348995ccaf03417136aef7ee332776[tests/backend/test-interfaces.c]
In his work on the plugin loader, _Cehteh_ created a first draft how to export an interface, and calls for review.
An example can be found in
https://git.lumiera.org/?p=LUMIERA;a=blob;f=tests/backend/test-interfaces.c;h=09fa25afa3cb57b79a2717d0bf3a8253afeba000;hb=ebcc5c7fd2d8700f3375e3309b724ac2517a0f40[tests/backend/test-interfaces.c]
An interface is a list of "slots" mapping functions. The interface descriptor is itself realised as interface, an thus can be versioned, extended and specialised. By use of some glue code and macros we create a simple Interface Definition Language
An interface is a list of »slots« mapping functions. The interface descriptor is itself realised as interface,
and thus can be versioned, extended and specialised.
By use of some glue code and macros we create a simple Interface Definition Language
* after exporting a header with the C interface, including the types to be used...
* LUMIERA_INTERFACE_DECLARE creates an interface description (i.e. the official interface)
@ -204,22 +226,33 @@ An interface is a list of "slots" mapping functions. The interface descriptor is
* LUMIERA_INTERFACE_INSTANCE creates an instance on-the-fly (e.g. for descriptors)
* LUMIERA_EXPORT for defining a table of functions/interfaces to export from the core
* LUMIERA_PLUGIN for defining an interface table for functions located within a dynlib module (plugin)
* besides, with LUMIERA_INTERFACE_INLINE you can create a function on-the-fly while LUMIERA_INTERFACE_MAP maps onto an existing function directly
* besides, with LUMIERA_INTERFACE_INLINE you can create a function on-the-fly while LUMIERA_INTERFACE_MAP maps
onto an existing function directly
The plugin loading system cares for mapping the given implementation function to the interface slots. Interfaces from the core need to be registered before they can be used, while for plugins this is done automatically on loading the module. The client code later just calls {{{interface_open()}}} and {{{interface_close()}}} where it doesn't matter anymore if the invoked function is in the core or loaded from an dynlib (plugin); loader, registry and/or plugin-DB shall manage it transparently.
The plugin loading system cares for mapping the given implementation function to the interface slots.
Interfaces from the core need to be registered before they can be used,
while for plugins this is done automatically on loading the module.
The client code later just calls `interface_open()` and `interface_close()`
where it doesn't matter anymore if the invoked function is in the core or loaded from an dynlib (plugin); loader,
registry and/or plugin-DB shall manage it transparently.
Version numbering starts with 1 and uses minor version numbers for compatible changes and major version numbers for everything that breaks existing asumptions. Version number zero is reserved for experimental work and per definition always the most recent version number.
Version numbering starts with 1 and uses minor version numbers for compatible changes
and major version numbers for everything that breaks existing assumptions.
Version number zero is reserved for experimental work and per definition always the most recent version number.
The system is designed to be very flexible and extensible, but this foundation really needs thorough review.
Joelholdworth expresses some concern regarding the UIDs in octal notation used within the interface description. Cehteh explains they never need to be specified by client code. They are just distinctive IDs and provided for some special case within the plugin loader / serializer. He plans to provide a simple tool which automatically replaces a $LUIDGEN with such a bitstring. The octal notation was chosen, because it is the most compact albeit portable notation possible in C source code.
_Joelholdworth_ expresses some concern regarding the UUIDs in octal notation used within the interface description.
_Cehteh_ explains they never need to be specified by client code.
They are just distinctive IDs and provided for some special case within the plugin loader / serializer.
He plans to provide a simple tool which automatically replaces a $LUIDGEN with such a bitstring.
The octal notation was chosen, because it is the most compact albeit portable notation possible in C source code.
Conclusion
~~~~~~~~~~
looks good, agreement by all core devs.
+
Looks good, agreement by all core devs. +
Should be reviewed and investigated in detail to find any hidden problems.
@ -227,6 +260,7 @@ Should be reviewed and investigated in detail to find any hidden problems.
Next meeting
------------
There were some problems with the meeting schedule. Using the first week of month seems to be problematic. We'll try with second wednesday...
There were some problems with the meeting schedule. Using the first week of month seems to be problematic.
We'll try with second Wednesday...
The next meeting is scheduled for '''Wednesday Nov 12 2008 19:30 UTC''' at #lumiera
The next meeting is scheduled for **Wednesday Nov 12 2008 19:30 UTC** at #lumiera

4
doc/devel/meeting_summary/2008-11-12.txt
View file

@ -48,7 +48,7 @@ eg. fader, panner, blur.
_joelholdsworth_ points out that configurability can't replace real GUI and workflow design.
He quotes from a recent Blender GUI discussion
[quote, the Belnder UI reviews]
[quote, the Blender UI reviews]
____________________________________________________________________
Lastly, I’d like to address another misconception, this time about customizability.
There has been a notion that the solution to most of the UI problems can be solved with added customizability.
@ -71,7 +71,7 @@ from the defaults to match another 3D application such as Maya or Softimage XSI
for users of those applications to adapt to Blender.
____________________________________________________________________
Consequently, Joel wants to try just doing the UI _right_, then add a little bit of customization back in here and there.
Consequently, _Joel_ wants to try just doing the UI _right_, then add a little bit of customization back in here and there.
Additionally, agreement is to have a kind-of ``perspective switcher'' (like in Eclipse), so saving different
panel layouts would be covered easily

12
doc/devel/meeting_summary/2008-12-10.txt
View file

@ -23,17 +23,17 @@ __Participants__
The Lumiera Logo
----------------
The logo contest is a great success: http://www.pipapo.org/pipawiki/Lumiera/Logos[105 entries]. Everyone agrees that a preselection has to be made. Every attendee will have a look at the entries and selects 5 for the preselection list. Finally, 21 logos are selected. Together with a nice collage they are http://www.pipapo.org/pipawiki/Lumiera/Logos/Selection[presented] so that anyone online can vote for his/her favorite one. Voting will be possible from 20 december until 31 december at midnight.
The logo contest is a great success: *105 entries*. Everyone agrees that a preselection has to be made. Every attendee will have a look at the entries and selects 5 for the preselection list. Finally, 21 logos are selected. Together with a nice collage they are presented ([purple]#`http://www.pipapo.org/pipawiki/Lumiera/Logos/Selection`#) so that anyone online can vote for his/her favorite one. Voting will be possible from 20 december until 31 december at midnight.
Recurring Topics
----------------
Discussion of open http://www.pipapo.org/pipawiki/Lumiera/DesignProcess[design process] drafts.
Discussion of open link:/x/DesignProcess.html[design process] drafts.
EDL vs Sequence
~~~~~~~~~~~~~~~
There has been a long discussion on the ML about the term EDL. In the end almost agreed or was at least ok with the Sequence instead of EDL. The Sequence will be the building block and is a collection of media objects and a tree of tracks. A discussion about the UML showed in [wiki:self:../DesignProcess/TimelineSequenceOutput Project, Timeline(s), Sequence(s) and Output] and the relation of Timeline and Sequence follows.
There has been a long discussion on the ML about the term EDL. In the end almost agreed or was at least ok with the Sequence instead of EDL. The Sequence will be the building block and is a collection of media objects and a tree of tracks. A discussion about the UML showed in link:{rfc}/TimelineSequenceOutput.html[Project, Timeline(s), Sequence(s) and Output] and the relation of Timeline and Sequence follows.
__Conclusion__: the name Sequence will be used instead of EDL
@ -45,7 +45,7 @@ Ichtyo explains that the idea is that between layers only the C Language interfa
Threads
~~~~~~~
The UI will mostly run on a single thread, i.e. gtk_main will run in this GUI thread and when it terminates, the GUI is "done" and signals back that it is done. Cehteh points out that really hard working threads should be managed by the scheduler in the backend. All agree that we should avoid thread cancellation
The UI will mostly run on a single thread, i.e. »gtk_main« will run in this GUI thread and when it terminates, the GUI __is ``done''__ and signals back that it is done. _Cehteh_ points out that really hard working threads should be managed by the scheduler in the backend. All agree that we should avoid thread cancellation.
@ -55,12 +55,12 @@ General Topics
Video format
~~~~~~~~~~~~
Kirk asks to what video format footage has to be converted so that it can be used in Lumiera. Ichtyo and cehteh point out that Lumiera will not be nailed down to one single format. A small number of formats that permit precise editing will be supported. Other formats may be available through plugins. The working horse is gmerlin, especially libgavl. Essentially Lumiera will try to figure out a conversion path in a lossless way.
_Kirk_ asks to what video format footage has to be converted so that it can be used in Lumiera. _Ichtyo_ and _Cehteh_ point out that Lumiera will not be nailed down to one single format. A small number of formats that permit precise editing will be supported. Other formats may be available through plugins. The working horse is gmerlin, especially libgavl. Essentially Lumiera will try to figure out a conversion path in a lossless way.
Knowledge base
~~~~~~~~~~~~~~
Kirk has already collected lots of information on video formats, conversion from one into the other, formats supported out of the box by Quicktime, Windows Media Player and so on. The developers agree that this is much needed. Kirk proposes to help in this area.
_Kirk_ has already collected lots of information on video formats, conversion from one into the other, formats supported out of the box by Quicktime, Windows Media Player and so on. The developers agree that this is much needed. _Kirk_ proposes to help in this area.

56
doc/devel/meeting_summary/2009-01-14.txt
View file

@ -36,54 +36,72 @@ Conclusion
~~~~~~~~~~
Two groups are created, each of these have someone responsible to bring them forward.
The group nudger is some director/moderator who keeps it going and nudges the people constantly, leading the discussion, not making the decisions alone. This 'supervisor' doesn't need to be someone to do the work of that group, but someone who can spend some efforts and time to coordinate it.
The group nudger is some director/moderator who keeps it going and nudges the people constantly, leading the discussion, not making the decisions alone. This `supervisor' doesn't need to be someone to do the work of that group, but someone who can spend some efforts and time to coordinate it.
Work discussion will proceed on the Mailing List but following the directions stated during the IRC meetings. +
Messages will have [ARTWORK] or [LOGO] or [WORKFLOW] in the subject. [[BR]] Groups can schedule IRC meetings separated from the monthly meetings that are meant for general organization.
Messages will have [ARTWORK] or [LOGO] or [WORKFLOW] in the subject. +
Groups can schedule IRC meetings separated from the monthly meetings that are meant for general organization.
Group 1 [WORKFLOW]
^^^^^^^^^^^^^^^^^^
. director/supervisor: nikola_ (Nikola Duper)
Unlike other software where the GUI dictates the capabilities of the backend, Lumiera is being built from the bottom up to the GUI. So the foundations are built first to make the things accessible independently to the layout. +
The GUI layout is determined by the people who code it. This workflow group will be counsellor for the coding devs.[[BR]] The core dev responsible for the GUI is joelholdsworth (Joel Holdsworth).[[BR]] One of the group goals is to make the dev point of view dialogate with the editor point of view.
. director/supervisor: _nikola_ (Nikola Duper)
Unlike other software where the GUI dictates the capabilities of the backend, Lumiera is being built from the bottom up to the GUI. So the foundations are built first to make the things accessible independently to the layout.
The group studies how a professional editor uses a NLE, defines the key-features and the main qualities (rock solid, simple, support for the main video formats, usable,...), define the static mainstream functionality as opposed to optional experimental ideas and funny widgets, discuss implementability in Lumiera with the devs. +
It discuss about UI design, to ease the pro workflow, to improve usability for amateurs and discoverability for newcomers. [[BR]] It thinks about ergonomics.
- The GUI layout is determined by the people who code it. This workflow group will be counsellor for the coding devs.
- The core dev responsible for the GUI is _joelholdsworth_ (Joel Holdsworth).
- One of the group goals is to create a dialogue between the developer's point of view and the editor's point of view.
The group studies how a professional editor uses a NLE, defines the key-features and the main qualities (rock solid, simple, support for the main video formats, usable,...), define the static mainstream functionality as opposed to optional experimental ideas and funny widgets, discuss implementability in Lumiera with the devs.
It discuss about UI design, to ease the pro workflow, to improve usability for amateurs and discoverability for newcomers. +
It considers aspects of ergonomics.
Group 2 [ARTWORK]
^^^^^^^^^^^^^^^^^
. director/supervisor: raffa (Raffaella Traniello)
. director/supervisor: _raffa_ (Raffaella Traniello)
The group discuss about logo, themes, the look and feel...
Getting the 'non-coders' community to help
------------------------------------------
goibhniu proposes an issue tracker.
_goibhniu_ proposes an issue tracker.
The documentation needs love: it's currently horribly scattered all around. +
All the content needs to be converted to asciidoc and to the git repo at lumiera.org.[[BR]] Waiting for uWiki, the site will be in asciidoc+git [[BR]] The site needs a structure or other means to increase discoverability of all our information[[BR]] goibhniu proposes organizing a "sprint" to help get people involved and set a date for it (documentation migration/organisation)
* The documentation needs love: it's currently horribly scattered all around.
* All the content needs to be converted to asciidoc and to the git repo at lumiera.org.
* Waiting for uWiki, the site will be in asciidoc+git
* The site needs a structure or other means to increase discoverability of all our information
* _goibhniu_ proposes organizing a ``sprint'' to help get people involved and set a date for it (documentation migration/organisation)
Conclusion
~~~~~~~~~~
* goibhniu volunteers to set up Trac.
* raevol volunteers to maintain it.
* The link:AsciiDoc[] Day idea will be discussed at the next meeting.
* _goibhniu_ volunteers to set up *Trac*.
* _raevol_ volunteers to maintain it.
* The »*AsciiDoc Day*« idea will be discussed at the next meeting.
Possible GUI-Integration: Display a frame?
------------------------------------------
There was some discussion about the need for a component which does the timing and communicates with the scheduler and where it should sit in the stack.
For example: a render controler would be `for (frame i=0; i < end; ++i){pull_frame_without_timing_constraints(i);}` and a player would be the same with timing constraints and possibly lower quality. The GUI just has to remember that a play button is pushed, and that a certain instance of the play control is associated with a certain playback task in the backend. It was decided that this doesn't need to be resolved at the moment and requires further discussion and planning. It was felt that device dependnet things shouldn't be in the backend since it may one day run remotely as a frame server. It may need to sit between the gui and the backend. It was noted that the backend will run on constraints rather than ticks. For now the focus is on getting a single frame into the gui and there will be time to flesh out final interfaces later.
For example: a render controler would be `for (frame i=0; i < end; ++i){pull_frame_without_timing_constraints(i);}` and a player would be the same with timing constraints and possibly lower quality.
The GUI just has to remember that a play button is pushed, and that a certain instance of the play control is associated with a certain playback task in the backend.
It was decided that this doesn't need to be resolved at the moment and requires further discussion and planning.
It was felt that device dependnet things shouldn't be in the backend since it may one day run remotely as a frame server.
It may need to sit between the gui and the backend. It was noted that the backend will run on constraints rather than ticks.
For now the focus is on getting a single frame into the gui and there will be time to flesh out final interfaces later.
The devs agreed to meet up on Saturday to get the latest version up and running.
http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=src/common/guifacade.cpp;h=7f781845ad79b4a3e2cd820b96b87f5e702a80d3;hb=8e89506d289f3986af133493a40e3705b7919c87#l64[]
NOTE: Demonstration in https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/common/guifacade.cpp;h=60a16d0f67bd95b43e44662daa9c0525235e14f5;hb=5f10e65852de2c51364c2e2a5a1cf29cae81c6b2#l64[guifacade.cpp]
(The thread shall be forked from within the GUI code not from the facade)
This was discussed and ichthyo has already pushed a new cleaned up state and resolved most of the dependency problems with the liblumiera. It raised the question: do we prefer a UI facade to a GUI facade or do we want an extra script facade someday?
It was discussed whether joelholdsworth should wait for cehteh to make a playback interface or use a dummy one for now. Cehteh wasn't ready to commit to a final interface yet but felt it was important to acknowledge the type of bidirectional interface that would be required. Icythyo has been using the link:GuiNotification[] as a dummy to implement an interface and get things working with loading the GUI plugin. Joelholdsworth already has displayer code which uses XVideo and falls back to GDK. It tells the buffer the address instead of being integrated with gavl, so cehteh will be able to hand it the address when ready. At the moment the buffers contain RGB (not gavl frames or anything). For the simple test joelholdsworth will need a buffer with RGB data and some metadata which cehteh and joelholdsworth planned to flesh out in the near future.
It was discussed whether _joelholdsworth_ should wait for _cehteh_ to make a playback interface or use a dummy one for now.
_Cehteh_ wasn't ready to commit to a final interface yet but felt it was important to acknowledge the type of bidirectional interface that would be required. Ichythyo has been using the `GuiNotification` as a dummy to implement an interface and get things working with loading the GUI plugin. Joelholdsworth already has displayer code which uses XVideo and falls back to GDK. It tells the buffer the address instead of being integrated with gavl, so cehteh will be able to hand it the address when ready. At the moment the buffers contain RGB (not gavl frames or anything). For the simple test joelholdsworth will need a buffer with RGB data and some metadata which _cehteh_ and _joelholdsworth_ planned to flesh out in the near future.
# Errors, Assertions, Checks, Dev- and Release-Builds
@ -97,7 +115,7 @@ in new nobug you can do:
alpha code here
)
it's the same for BETA RELEASE and there's a NOT variant for each but even then that should be avoided and higher level nobug facilities should be used instead.
(http://www.lumiera.org/nobug.html)[]
(https://nobug.pipapo.org/[NoBug])
beta and release builds shall be possible with nobug soon .. waiting for metta to integrate the new test.sh
test.sh with regex is awesome because you can test output which contains no exact things like addresses, version numbers, times
@ -106,7 +124,7 @@ and running the testsuite under valgrind works properly now
Workflow/Interface
~~~~~~~~~~~~~~~~~~
Ichthyo expressed the importance of not having dedicated kinds of tracks, but to be able to use any track for anything (audio, video etc.). This will require more work in the proc layer. Tracks are also not just layered but are trees which can fold. Any clip can contain N streams of various kinds. When a clip contains video and audio streams it still occupies just one track and the system automatically connects the audio to an audio bus etc. but the user is free to split off the audio as an independent clip and treat it separately from the video. The plan is to have various kinds of links between clips. This basic idea will need further refinement and consideration by the workflow team (Nikola et. al.) e.g. the user will need some way to direct the sound to a different bus even though it may be in a compound clip. By default all the video should be layered in the order of the tracks and a user should be able to say "don't mix the audio from track 4 and its child tracks directly to master but route it to the music subgroup". This is where the tree of tracks plays an important role because each track with its children forms a group.
Ichthyo expressed the importance of not having dedicated kinds of tracks, but to be able to use any track for anything (audio, video etc.). This will require more work in the proc layer. Tracks are also not just layered but are trees which can fold. Any clip can contain N streams of various kinds. When a clip contains video and audio streams it still occupies just one track and the system automatically connects the audio to an audio bus etc. but the user is free to split off the audio as an independent clip and treat it separately from the video. The plan is to have various kinds of links between clips. This basic idea will need further refinement and consideration by the workflow team (Nikola et. al.) e.g. the user will need some way to direct the sound to a different bus even though it may be in a compound clip. By default all the video should be layered in the order of the tracks and a user should be able to say ``don't mix the audio from track 4 and its child tracks directly to master but route it to the music subgroup''. This is where the tree of tracks plays an important role because each track with its children forms a group.
There was further discussion on the general aims, objectives and focus of Lumiera and the reasoning behind them. Integration with control surfaces, jog wheels, sliders etc. should also be considered for the workflow. Nikola expressed the importance of stability and a simple and clean UI.

6
doc/devel/meeting_summary/2009-09-09.txt
View file

@ -29,7 +29,7 @@ This success wouldn't be possible without a lot of people helping. +
So lets say: *Thank you all*!
We plan to be there again next year with another Lumiera meeting (possibly
all the 3 core devs present). _Ichthyo_ consideres to do a dedicate talk
all the 3 core devs present). _Ichthyo_ considers to do a dedicate talk
(in German).
Participation as a group to other possible events has been considered for +
@ -60,7 +60,7 @@ If later on there will be funding for development (not just covering expenses)
that would require a different approach and special communication with the
community.
_daniieel_ proposes to put a price to each request in "buglist". +
_daniieel_ proposes to put a price to each request in ``buglist''. +
The proposal is discussed and dismissed.
@ -71,7 +71,7 @@ The news in the homepage makes the project look alive. But this is not
enough to communicate the state of the Lumiera development. Two
solutions are proposed:
* The website needs to be reorganized and made accessible. andrewjames
* The website needs to be reorganized and made accessible. _andrewjames_
volunteers to work on it.
* Quarterly development news will be published in the devel section of the
website. The devs will post drafts to the mailing list and encourage the

16
doc/devel/meeting_summary/2011-03-09.txt
View file

@ -25,6 +25,8 @@ The new website is finally online.
How do we proceed with the graphical layout?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[caption="☉Transcript☉ "]
----------------------------
21:37 <fsiddi> the template code is not ready yet
21:37 <fsiddi> and there are some incorrect uses of tags in the current one
21:37 <fsiddi> so i will go on coding a static html layout
@ -32,6 +34,7 @@ How do we proceed with the graphical layout?
...
21:50 <ichthyo> fsiddi: I liked the way you provided a slightly larger content area
for the tutorial part
----------------------------
image:{img}/meetings/2011-03-09-mockup_dev_1.jpg["Website Proposal Mockup number 3", width=128, link="{img}/meetings/2011-03-09-mockup_dev_1.jpg"]
@ -69,6 +72,9 @@ until the sun burns out.
engines will not respect it. Private logs or other logs not publically available
are fine though.
.-- Discussion about relevance of IRC logs --
[caption="☉Transcript☉ "]
----------------------------
22:40 <cehteh> well ... IRC should *not* be for persistent documentation .. we shall
force/educate ourself to document things (and decisions) properly, irc
should be volatile
@ -96,11 +102,12 @@ are fine though.
22:50 <skangas_> This means I personally always prefer shorter summaries of a
discussion to IRC logs, given that they do not leave anything
important out.
----------------------------
VoIP discussions over Mumble?
-----------------------------
There seems to be link:http://kitenet.net/~joey/blog/entry/12_hours_of_talking/[ongoing discussions]. on using VoIP more in Debian GNU/Linux.
There seems to be https://joeyh.name/blog/entry/12_hours_of_talking/[ongoing discussions]. on using VoIP more in Debian GNU/Linux.
It was decided that while the idea is nice, it will not be used for developer
meetings. We might use it for developer discussions outside meetings if we feel
@ -116,8 +123,11 @@ highly insecure.
Version numbering
-----------------
Hermann has written an rfc for version numbers.
_Ichthyo_ has written an link:{rfc}/VersionNumberScheme.html[RfC for version numbers].
.-- Discussion about a version number scheme for Lumiera --
[caption="☉Transcript☉ "]
----------------------------
23:19 <cehteh> so in my words: we will have a usuall major.minor.patch for releases
23:20 <cehteh> and major+1~develtag for devel snapshots
23:20 <cehteh> where develtag is a timestamp
@ -201,6 +211,8 @@ Hermann has written an rfc for version numbers.
could be automatized)
23:26 <cehteh> remember in test.sh i reserved the 90-99* area for 'bugs'
23:26 <cehteh> we may put some blocking tests there which prevent staging
----------------------------
Next meeting
------------

44
doc/devel/meeting_summary/2011-04-13.txt
View file

@ -16,9 +16,12 @@ _Protocol written by Ichthyo_
.organisational
- IRC meeting summaries will be moved into the main Git tree, below 'doc/devel'
- mostly shortened and tidied IRC logs, plus summary of conclusions \+ decisions
- ``winter quarterly coding news'': this time just paste _Ichthyo's_ contribution into the website
- IRC meeting summaries will be moved into the main Git tree, +
below 'doc/devel'
- mostly shortened and tidied IRC logs, +
plus summary of conclusions + decisions
- ``winter quarterly coding news'': +
this time just paste _Ichthyo's_ contribution into the website
- the next ``coding news'' probably in May?
@ -28,7 +31,7 @@ _Francesco Siddi_ has augmented his Layout proposal and already built up two pag
cover most of the layout needs of the Lumiera website and documentation resources. However,
some points with the code generated by Asciidoc turned out to be problematic.
In a link:http://permalink.gmane.org/gmane.comp.video.lumiera.general/2330[message preceeding the meeting],
In a https://lists.lumiera.org/pipermail/lumiera/2011-April/002418.html[message preceeding the meeting],
today _ichthyo_ highlighted some general concerns which might need further discussion and maybe
a decision.
@ -344,17 +347,19 @@ _Cehteh_ points out that this new policy should at least be anounced on the Mail
Recurring Topic: Design process entries
---------------------------------------
Discussion of open link:/documentation/devel/rfc.html[design process] drafts.
Discussion of open link:/x/DesignProcess.html[design process] drafts.
Since some time, no further discussion happened regarding the currently _pending_
RfC entries. Agreement is that we should again return to the former routine and
revisit the relevant design process entries in each developer meeting.
-> link:{rfc}/ApplicationInstall.html[RfC: Application Install]
[[application_install_proposal]]
.-- the Application Install proposal --
[caption="☉Transcript☉ "]
----------------------------
[2011-04-14 00:48:25] <cehteh> link:{ldoc}/devel/rfc_pending/ApplicationInstall.html
[2011-04-14 00:48:25] <cehteh> the pending ApplicationInstall RfC
[2011-04-14 00:48:40] <ichthyo> maybe only pick out some interestin ones or some which are quick to decide
[2011-04-14 00:49:06] <cehteh> well i want to go over all pending .. then we can put notes there "boring for the next meeting"
[2011-04-14 00:49:42] <cehteh> for example this application install .. is boring .. you did a lot work, imo you can finalize it
@ -372,7 +377,9 @@ revisit the relevant design process entries in each developer meeting.
Delectus Shot Evaluator
~~~~~~~~~~~~~~~~~~~~~~~
Agreement to _park_ it until someone else comes up to advance this topic further.
Agreement to _park_
link:{rfc}/DelectusShotEvaluator.html[the »Delectus« RfC], +
until someone else comes up to advance this topic further.
Clip Cataloging System
~~~~~~~~~~~~~~~~~~~~~~
@ -386,6 +393,7 @@ Keep _pending_ -- _ichthyo_ will expand on that
Lumiera Forward Iterator
~~~~~~~~~~~~~~~~~~~~~~~~
-> link:{rfc}/LumieraForwardIterator.html[RfC]
[caption="☉Transcript☉ "]
----------------------------
@ -405,6 +413,7 @@ Lumiera Forward Iterator
Design the Render Nodes interface
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-> link:{rfc}/DesignRenderNodesInterface.html[RfC]
.-- Discussion of details --
[caption="☉Transcript☉ "]
@ -421,7 +430,8 @@ Design the Render Nodes interface
Developer Documentation Structure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--> see link:https://issues.lumiera.org/ticket/763[Ticket #763]
- -> link:{rfc}/DeveloperDocumentationStructure.html[RfC]
- -> see link:https://issues.lumiera.org/ticket/763[Ticket #763]
.-- Discussion of details --
[caption="☉Transcript☉ "]
@ -440,6 +450,7 @@ Developer Documentation Structure
Engine Interface Overview
~~~~~~~~~~~~~~~~~~~~~~~~~
-> link:{rfc}/EngineInterfaceOverview.html[RfC]
.-- Discussion of details --
[caption="☉Transcript☉ "]
@ -464,12 +475,14 @@ Engine Interface Overview
Feature Bundle
~~~~~~~~~~~~~~
Expected to be very important in the far future, but we don't have the
This link:{rfc}/FeatureBundle_PluggableModules.html[RfC: Reature Bundle]
is expected to be very important in the far future, but we don't have the
resources to work on that right now, so _park_ it.
Marble Mode
~~~~~~~~~~~
-> link:{rfc}/MarbleMode.html[RfC: Marble Mode]
.-- Discussion of details --
[caption="☉Transcript☉ "]
@ -492,7 +505,8 @@ Marble Mode
Normalized Device Coordinates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
still very rough, but basically agreed. +
The proposal for link:{rfc}/NormalizedDeviceCoordinates.html[Normalized Device Coordinates]
is still very rough, but basically agreed upon.
While it needs more work, it's a bit out of focus right now, so _park it.
@ -509,6 +523,8 @@ link:{rfc}/ProcPlacementMetaphor.html[Placement] proposal
Render Optimizer, Resource Management and Profiling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- -> link:{rfc}/ResourceManagementProfiling.html[RfC: Profiling]
- -> link:{rfc}/ResourceManagementBudgeting.html[RfC: Budgeting]
.-- Discussion of details --
[caption="☉Transcript☉ "]
@ -545,12 +561,13 @@ Render Optimizer, Resource Management and Profiling
Roadmap
~~~~~~~
The link:{rfc}/rfc/Roadmap-first.html[Roadmap document]
The link:{rfc}/Roadmap-first.html[Roadmap document]
was erroneously not marked as final; +
Seemingly it was decided upon in 2009 already ...
Stream Type System
~~~~~~~~~~~~~~~~~~
-> link:{rfc}/StreamTypeSystem.html[RfC]
[caption="☉Transcript☉ "]
----------------------------
@ -577,6 +594,8 @@ Stream Type System
Threads Signals and important management tasks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-> link:{rfc}/ThreadsSignalsAndImportantManagementTasks.html[RfC]
.-- Discussion of details --
[caption="☉Transcript☉ "]
----------------------------
@ -620,7 +639,8 @@ in multiple timelines. We pretty much agree on that, thus it counts as _finalise
Use Cases
~~~~~~~~~
This is an heavyweight proposal regarding the high-level design and general handling of the
-> link:{rfc}/UseCases.html[This RfC]
is a heavyweight proposal regarding the high-level design and general handling of the
Application. This would be really a topic to be discussed in conjection with the ``Workflow''
-- the idea was to have a working group focussed these topics entirely, but there is no one
in charge of that right now. Thus _park_ it for the time being.

2
doc/devel/meeting_summary/2011-05-11.txt
View file

@ -20,7 +20,7 @@ Render Engine Interface
_Ichthyo_ had prepared a new
link:/documentation/devel/rfc_pending/EngineInterfaceSpec.html[RfC]
about the actual interface between the
link:/documentation/design/architecture/playRender.html[Player subsystem]
link:/documentation/design/architecture/Playback.html[Player subsystem]
and the Renderengine/Scheduler.
The following discussion turned into considering several detaled and technical
topics regarding the Jobs to be scheduled, how to create and attach new jobs,

9
doc/devel/meeting_summary/2012-09-12.txt
View file

@ -20,7 +20,7 @@ RFCs
----
It was not clear what state
link:{ldoc}/devel/rfc.html[RFCs] have in our
link:/x/DesignProcess.html[RFCs] have in our
documentation structure. The question was if they should, after
becoming finalized integrated into some other document or stay first
class and be referenced from other documents.
@ -86,7 +86,6 @@ Workflow between the Master and the Documentation repository
There was some confusion how the master and the documentation
repository relate to each other.
We agreed on merging back and forth between in a bidirectional way,
but doing this lazy on demand.
@ -101,10 +100,10 @@ A complete rewrite of Builddrone (a continuous integration system) is
now (almost) finished and will be deployed on our build server within
the next days. It has numerous improvements over the old one. More
information and documentation will appear at
https://builddrone.pipapo.org/ soon. Stay tuned.
https://web.archive.org/web/20221205192908/https://builddrone.pipapo.org/[builddrone.pipapo.org]
soon. Stay tuned.
Thanks to Lenny for helping with the documentation and Simon for the
Logo.
Thanks to Lenny for helping with the documentation and Simon for the Logo.

2
doc/devel/meeting_summary/2013-09-12.txt
View file

@ -60,7 +60,7 @@ Scheduler: Interface and requirements
-------------------------------------
_Benny_ showed interest to work on that topic. The first step would be to build or use
a priority queue textbook implementation as starting point. Some time ago, _cehteh_ included
a suitable implementation in his link:http://git.pipapo.org/?p=cehsrc;a=summary[cehlib],a
a suitable implementation in his https://git.pipapo.org/cehteh/cehsrc[cehlib],a
collection of basic C library routines, mostly extracted from Lumiera's library. _ichthyo_
integrates this priority queue into the Lumiera tree.

4
doc/devel/meeting_summary/2023-09-13.txt
View file

@ -92,7 +92,7 @@ integrated into the website infrastructure.
Library solutions for Video Display
-----------------------------------
_Benny_ conducted some research regarding library solutions for *video display*, notably
ffmpeg, GStreamer and libVLC. It was rather easy to code up an "hello world" example based on
ffmpeg, GStreamer and libVLC. It was rather easy to code up an ``hello world'' example based on
GStreamer, while it was difficult to find suitable documentation regarding the ffmpeg based
solution. Moreover, GStreamer seems to have a much more active and helpful community.
@ -116,7 +116,7 @@ support framework.
Next meeting
------------
The next meeting will be Wednesday Oct 11, 20:00 UTC.
The next meeting will be Wednesday **Oct 11, 20:00 UTC**.
You are welcome to join.
''''

2
doc/devel/meeting_summary/2023-10-11.txt
View file

@ -65,7 +65,7 @@ but a replacement solution was identified, which still needs to be integrated.
Next meeting
------------
The next meeting will be Wednesday Nov 8, 20:00 UTC.
The next meeting will be Wednesday **Nov 8, 20:00 UTC**.
You are welcome to join.
''''

4
doc/devel/meeting_summary/2023-11-08.txt
View file

@ -35,7 +35,7 @@ https://web.archive.org/web/20090129083001/https://www.linux.com/feature/126441[
and remove a ^[citation needed]^ tag.
-> see the reworked
{l}/project/index.html[``About''] and {l}/project/faq.html[``FAQ''] pages +
link:/project/index.html[``About''] and link:/project/faq.html[``FAQ''] pages +
-> section in the
https://en.wikipedia.org/wiki/Cinelerra#Lumiera[Wikipedia page for Cinelerra].
@ -93,7 +93,7 @@ able to demonstrate running video display in the GUI.
Next meeting
------------
The next meeting will be Wednesday Dec 13, 20:00 UTC.
The next meeting will be Wednesday **Dec 13, 20:00 UTC**.
You are welcome to join.
''''

4
doc/devel/meeting_summary/2024-01-10.txt
View file

@ -4,7 +4,7 @@
:Date: 2024-01-20
Jan 10, 2024
on {l}/project/contact.html#_irc[`#lumiera`]
on link:/project/contact.html#_irc[`#lumiera`]
20:00 - 23:00 UTC +
__Participants__
@ -78,7 +78,7 @@ process and resource management within the Lumiera render engine itself.
Next meeting
------------
The next Lumiera meeting is scheduled for Wednesday, Feb 14 at 20:00 UTC.
The next Lumiera meeting is scheduled for Wednesday, **Feb 14 at 20:00 UTC**.
Should this be inconvenient for you, please speak up on, for example,
link:http://lists.lumiera.org/cgi-bin/mailman/listinfo/lumiera[lumiera@lists.lumiera.org]
and let us know of when you would prefer to attend.

19
doc/devel/meeting_summary/index.txt
View file

@ -11,6 +11,17 @@ spending time on the task of writing a summary.
Anyone interested in Lumiera development is also encouraged to read mailing list
archives and other documentation.
2024-2025
---------
All meetings were informal in style; usually _Ichthyo_ gave a summary
of recent achievements and explained some of the problems he was facing.
Usually this leads into a rather detailed and technical discussion.
Since Spring 2005, _Wouter Verwijlen_ has regularly participated in
renewed discussions for a
of a renewed link:{ldoc}/design/workflow/Verwijlen/[Workflow Concept].
8 May / 12 June 2024
--------------------
Discussion regarding the approach taken towards the next core topic, which
@ -326,8 +337,8 @@ Topics
~~~~~~
* organisational (protocol, agenda, leftovers?)
* Logo Contest progress, discussion about how to do the pre selection
* rename "EDL" into "Sequence"
* link:DesignProcess/TimelineSequenceOutput[Project, Timeline(s), Sequence(s) and Output]
* rename »EDL« into »Sequence«
* link:/documentation/devel/rfc/TimelineSequenceOutput.html[Project, Timeline(s), Sequence(s) and Output]
* GUI/Proc Interface and collaboration
* Threading questions regarding gtk-main and main()
@ -500,7 +511,7 @@ Topics
~~~~~~
* boilerplate (protocol, whats left from last meeting, next meeting)
* Go through Ideas and Drafts in design process
* "Call for design" for some features relevant for the whole Application:
* ``Call for design'' for some features relevant for the whole Application:
- parameters and automation
- render node interface
- handling of compound sessions
@ -522,7 +533,7 @@ Summary
Topics
~~~~~~
* Who will write the protocol below
* Discuss the open points in link:Lumiera/DesignProcess[] do we need this formalism?
* Discuss the open points in a link:/x/DesignProcess[»Design Process«] -- do we need this formalism?
* Who works on what, what are the short term goals, what tasks are open
* State of the new-name search for the was-intended-as-cinelerra-3 project (no name discussion, just how we will progress!)
* Introduce the development model

12
doc/devel/report.txt
View file

@ -6,29 +6,23 @@ Statistics and Reports
++++++++++++++++++++++++++++++++++++++
<div style="float:left">
<script type='text/javascript' src='https://www.openhub.net/p/lumiera/widgets/project_basic_stats?format=js'></script>
<script type='text/javascript' src='https://openhub.net/p/lumiera/widgets/project_basic_stats?format=js'></script>
</div>
++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++
<div style="float:right; margin-left: 2em;">
<script type='text/javascript' src='https://www.openhub.net/p/lumiera/widgets/project_cocomo?format=js'></script>
<script type='text/javascript' src='https://openhub.net/p/lumiera/widgets/project_cocomo?format=js'></script>
</div>
<p style="clear:both" />
++++++++++++++++++++++++++++++++++++++
''''
^Statistics generated automatically by *OpenHub* based on Git master footnote:[»link:https://blog.openhub.net/about/[OpenHub]«,
^Statistics generated automatically by *OpenHub* based on Git master footnote:[»link:https://openhub.net[OpenHub]«,
formerly known as »Ohloh« is a public directory and networking site for free and open source software (FOSS),
offering analytics and search services for evaluating and comparing open source projects.]^
Mailing List
------------
image:http://gmane.org/plot-rate.php?group=gmane.comp.video.lumiera.general[Lumiera Mailinglist activity] +
^activity stats by link:http://dir.gmane.org/gmane.comp.video.lumiera.general[Gmane.org]^
Tickets
-------

32
doc/devel/rfc/AllPluginInterfacesAreC.txt
View file

@ -1,12 +1,12 @@
Design Process : All Plugin Interfaces Are C
============================================
[grid="all"]
`------------`-----------------------
*State* _Dropped_
*Date* _2007-06-29_
*Proposed by* link:ct[]
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Dropped_
|*Date* | _2007-06-29_
|*Proposed by* | ct
|====================================
@ -39,7 +39,7 @@ Implementation Proposal
* first member is a _size_ which will be initialized by the actual
implementation
* followed by function pointers defining the interface, see:
link:Lumiera/DesignProcess/CCodingStyleGuide[]
link:{rfc}/CCodingStyleGuide.html[C-coding style guide]
* everything added is considered immutable for this interface version
* new functions are added to the end (thus changing size)
@ -162,7 +162,7 @@ outweigh the drawbacks.
ct:: '2007-07-03 05:51:06'
C is the only viable choice here. Perhaps some sort of "test bench" could be
C is the only viable choice here. Perhaps some sort of ``test bench'' could be
designed to rigorously test plugins for any problems which may cause Lumiera to
become unstable (memory leaks etc).
@ -173,9 +173,9 @@ documented in the repository (tiddlywiki/source)
ct:: '2007-07-11 13:10:07'
Development took another direction over course of the years;
Lumiera is not based on a _generic plug-in Architecture_ and the topic
.State -> Dropped
Development took another direction over the course of the years;
Lumiera is _not_ based on a _generic plug-in Architecture_ and the topic
of interfaces for _dedicated plugins_ still needs to be worked out
Ichthyostega:: '2023-10-24 22:55:23'
@ -185,17 +185,17 @@ Ichthyostega:: '2023-10-24 22:55:23'
Conclusion
----------
Initially there was agreement over the general direction set out by this proposal.
However, _Ichthyo_ was always sceptical regarding the benefits of a generic plug-in
However, _Ichthyo_ was always skeptical regarding the benefits of a generic plug-in
Architecture. Experience with high-profile projects based on such a concept seem
to show both tremendous possibilities, especially regarding user involvement, but
at the same time also indicate serious problems with long-term sustainability.
The practical development -- mostly driven ahead by _Ichthyo_ -- thus never really
embraced that idea; rather structuring by internal interfaces and contracts was
The practical development -- after some point mostly driven ahead by _Ichthyo_ -- never
really embraced that idea; rather structuring by internal interfaces and contracts was
preferred. The basic system for loading of Plug-ins, as indicated by this proposal,
is still used though to load some dedicated plug-ins, most notably the GUI.
To draw an conclusion: this proposal is now considered as *rejected*.
To draw a conclusion: this proposal is now considered as *rejected*.
Instead, Ticket https://issues.lumiera.org/ticket/1212[#1212 »Extension Concept«]
was added to the list of relevant
https://issues.lumiera.org/report/17[»Focus Topics«] for further development.
@ -205,4 +205,4 @@ https://issues.lumiera.org/report/17[»Focus Topics«] for further development.
.........
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

54
doc/devel/rfc/ApplicationInstall.txt
View file

@ -3,22 +3,22 @@ ApplicationInstall
// please don't remove the //word: comments
[grid="all"]
`------------`-----------------------
*State* _Draft_
*Date* _Di 11 Jan 2011 17:00:55 CET_
*Proposed by* Ichthyostega <prg@ichthyostega.de>
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Final_
|*Date* | _Di 11 Jan 2011 17:00:55 CET_
|*Proposed by* | Ichthyostega <prg@ichthyostega.de>
|====================================
[abstract]
*********************************************************************************
Lumiera should be a _freely relocatable_ application bundle.
Lumiera should be a _freely relocatable_ application bundle. +
Relying only on the relative folder structure within this bundle, the application
will be fully functional at any location, provided that the external library
dependencies are resolvable using the standard mechanisms of the platform.
The setup mechanism must be obvious, self-explanatory and must not rely
on compiled in magic or buildsystem trickery. Yet packaging into a FSH conforming
installation location should be supported by the same mechanisms.
This setup mechanism should be obvious and self-explanatory and must not rely
on compiled-in hidden magic or buildsystem trickery. Yet packaging into a fully
FSH conforming installation location should be supported by the same mechanisms.
*********************************************************************************
Description
@ -66,7 +66,7 @@ In former days, it was common habit to compile-in a hard wired absolute
policy forbids doing so. This is the result from numerous maintainability
problems in the past. On the other hand, the GNU linker and other modern
linkers support a relative resolution of shared modules directly accompanying
an specific executable. The Debian policy allows this, if and only if these
a specific executable. The Debian policy allows this, if and only if these
shared modules are installed with the same binary package and only used by
this specific executable(s). Together, this is exactly what we need to
solve our requirement.
@ -76,7 +76,7 @@ and sets the +DT_RUNPATH+ with an value relative to +$ORIGIN+, which resolves
to the path of the currently executing binary. Moreover, it is _sufficient_
to set this on the initial executable _only,_ because this creates a common
searchpath for all lib resolution events in the scope of that loaded executable.
Besides that, we need to care that our private libraries have a unique +SONAME+,
Besides that, we need to care that our private libraries have an unique +SONAME+,
in this case all starting with the prefix +liblumiera*+. Note moreover that this
new-style +DT_RUNPATH+ indeed _can_ be overridden by an +LD_LIBRARY_PATH+ in the
environment, should there be the need for very special experiments.
@ -121,7 +121,7 @@ Tasks
* build the executables in a way to allow relative resolution of the
internal shared modules ([green]#✔ done#)
* replace the compiled-in path definitions for plugin loading by a
configurable bootstrap ([green]#✔#)
configurable bootstrap ([green]#✔ done#)
* add an working library implementation for a config loader ([green]#✔ done#)
* add a mechanism for establishing the path of the current execubable. +
This is _non-portable_ ([green]#✔ done#)
@ -130,7 +130,7 @@ Tasks
* try to extract the path search code from the existing config loader,
or build a new solution based on standard libraries ([green]#✔ done#)
* introduce an output root directory into the buildsystem, allowing
for package builds ([green]#✔#)
for package builds ([green]#✔ done#)
* define a _Debian packaging_ as proof-of-concept ([green]#✔ done#)
@ -172,10 +172,10 @@ up some very specific problems and constraints, which can be a serious
threat when discovered late in the development process.
The second alternative isn't really applicable IMHO. The original UNIX philosophy
breeds on an academic setup and really excels with small nifty commandline utils
draws from an academic setup and really excels with small nifty commandline utils
combined by pipes, each specialised to do a single thing very well. These utils
are more like the objects within our implementation. The concept of large
application software bundles and desktop software was always a bit alien
application software bundles and desktop software was always slightly alien
within the classic UNIX environment.
@ -191,17 +191,20 @@ trickery, inline code compiled on-the-fly, relying on very specific and
un-obvious behaviour of some build script, configuration via environment
variables and a lot of similar idioms. These practices might be adequate
in a quickly moving Research & Development setup, but turned out to be
not so helpful when it comes to industrial strength development,
not so helpful when it used within large-scale development efforts,
as they are known to lead to maintenance problems.
//Conclusion
//----------
//conclusion: When approbate (this proposal becomes a Final)
Conclusion
----------
//conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process:
All the indicated clean-up was done and the bootstrap sequence could be implemented. +
The link:{ldoc}/devel/meeting_summary/2011-04-13.html#application_install_proposal[Apr.2011 developer meeting]
shortly touched on this proposal without raising any objections.
``... for example this application install .. is boring .. we need it, you did it well'' (_Cehteh_)
@ -219,7 +222,14 @@ which reminded me of several small issues, which seem to become unhealthy when l
around unfixed for such a long time. Probably I'll start a clean-up initiative and
try to bring these points to discussion separately.
So 13 Feb 2011 20:04:00 CET Ichthyostega <prg@ichthyostega.de>
Ichthyostega:: 'So 13 Feb 2011 20:04:00 CET'
.State -> Final
After being established in 2011, this structure was used ever since. There was once
a problem with a bug in `ld.so` related to the transitive use of the `$origin` token;
this bug had been resolved quickly. Other than that, packaging and application start
always worked as intended -- so I consider this topic as settled.
Ichthyostega:: '2025-09-18'
//endof_comments:

117
doc/devel/rfc/ApplicationStructure.txt
View file

@ -1,12 +1,13 @@
Design Process : Application Structure
======================================
[grid="all"]]
`------------`----------------------
*State* _Dropped_
*Date* _2008-11-05_
*Proposed by* link:ct[]
------------------------------------
[options="autowidth"]
|====================================
|*State* | _Dropped_
|*Date* | _2008-11-05_
|*Proposed by* | ct
|====================================
Application Structure
---------------------
@ -20,8 +21,8 @@ So far we came up with a simplified BACKEND/PROC/GUI structure where each of
this entities defines its own sub subcomponents. We agreed to glue that all
together with some portable versioned interfaces system, but details where not
laid out yet. At the time of this writing the interface system and plugin
loader are reasonable finished to be usable (some small refinements to do). We
recently discussed some details on IRC on how to engage this without a
loader are reasonable finished to be usable (some small refinements to do).
We recently discussed some details on IRC on how to engage this without a
definitive decision. The topic of this proposal is to make a detailed
description towards how the application components being glued together.
@ -31,12 +32,12 @@ this parts are actually be, except that the GUI should be optional for headless
operation. I suggested to make as much as possible pluginable to make it easier
to validate our interfaces and try different things out.
Now I introduce 'lumiera' here, this will become a new component in
./src/lumiera being the driver application for bootstraping all the rest:
Now I introduce `"lumiera"` here, this will become a new component in
`./src/lumiera` being the driver application for bootstraping all the rest:
Then our application structure looks somewhat like (please refine):
* the 'lumiera' loader
* the Lumiera loader
- commandline handling
- interface & plugin system
- session manager core
@ -60,24 +61,24 @@ Then our application structure looks somewhat like (please refine):
- preferences
- ...
Furthermore the interface&plugin system is flexible enough to provide things
independently of their origin (if it is build in or a plugin/dynamic library).
Furthermore the interface and plugin system is flexible enough to provide things
independently of their origin (if it is either built-in or a plugin/dynamic library).
So deployment (where to link these things) is secondary.
'lumiera' will then be the executable the user starts up, what exactly gets
initialized and booted up is then matter
of configuration and commmandline options (and maybe lua scripting?).
`"lumiera"` will then be the executable the user starts up,
what exactly gets initialized and booted up is then matter
of configuration and commandline options (and maybe Lua scripting?).
Tasks
^^^^^
* create the 'lumiera' directory
* create the `lumiera` directory
- setup the build system
- move config, plugin and interfaces therein
- lua support can be done later
* write the main() part of the application
- Lua support can be done later
* write the `main()` part of the application
- start config system
- parse commandline opts
* librificate all other components (backend, proc gui)
@ -92,17 +93,17 @@ Pros
^^^^
* flexible plugin based architecture
- later: loads only things which are necessary for a given task
** later: loads only things which are necessary for a given task
* very fast startup
* things which cant be used on a given environment can be left out (no gui on
a headless system, no $DISPLAY set)
* things which can't be used on a given environment can be left out (no gui on
a headless system, no `$DISPLAY` set)
* inter dependencies between interfaces and plugins are automatically tracked.
Cons
^^^^
Ichthyo raised concerns that this kind of flexibility might attract other
_Ichthyo_ raised concerns that this kind of flexibility might attract other
people to write things which are not in our intention and break future design
and compatibility. We need to carefully document and define interfaces that
people don't abuse those!
@ -112,7 +113,7 @@ people don't abuse those!
Alternatives
^^^^^^^^^^^^
We discussed the startup/main() through the GUI as it is currently done, it
We discussed the startup / `main()` through the GUI as it is currently done, it
would be also possible to produce some more executables (lumigui, luminode,
lumiserver, ....). But I think we agreed that a common loader is the best way
to go.
@ -122,7 +123,7 @@ Rationale
~~~~~~~~~
I just think this is the best way to ensure a enduring design even for future
changes we can not forsee yet.
changes we can not foresee yet.
@ -139,19 +140,24 @@ agreed on it.
From reading the above text, this proposal seems to capture that. But I am
somewhat unsure if the purpose of this proposal isn't rather to load just a
micro kernel and the pull up components according to configuration. Because I
wouldn't accept such an architecture, and I clearly stated so right at the
*micro kernel* and then pull up components according to configuration. Because
I wouldn't accept such an architecture, and I clearly stated so right at the
beginning of our project. I accepted a very flexible and language neutral
plugin system on the condition the core remains in control, stays
''reasonable'' monolithic and componentization doesn't handicap us in creating
plugin system on the condition that the core remains in control, stays
``reasonable'' monolithic and componentization doesn't handicap us in creating
an architecture based on abstractions and exploiting the proven design
patterns.
Ichthyo:: '2008-11'
+
--
It has that flexibility, yes. But that means not that we have to abuse it in
any way. The main() there and thus the bootstrap of the application is under
any way. The `main()` there and thus the bootstrap of the application is under
our tight control, if we want to reject scriptable/highly configurable
bootstrapping there then we can just do so. Thats more a social than a
technical decision. I personally don't like if a design is 'nannying' and puts
technical decision.
I personally don't like if a design is ``nannying'' and puts
too much constraints into unforeseen areas. If the computer can do some task
better than we, it shall do it. This still means that I want to stay very much
in control, it should only do some tedious, error-prone managing tasks for me.
@ -161,40 +167,63 @@ define anything. The interface system gets it right and we wont need to care
for the order initialization. I added that because I consider such as
absolutely important for plugins which might be supplied by third parties where
we have no control over. But I now realized that we can nicely use that for our
own internal things too. Imo thats some very valuable service.
-- link:ct[] [[DateTime(2008-11-08T06:26:18Z)]]
own internal things too. IMO thats some very valuable service.
ct:: '2008-11-08T06:26:18Z'
--
Some further minor details: We didn't finish the discussion about namespaces on
the last meeting. (I know I still have to write up a proposal showing the two
or three alternatives I see regarding namespace organisation). But probably,
"lumiera::" will be our top level interface namespace and then probably the
lumiera directory will be taken by that. I see no problem also putting some
`"lumiera::"` will be our top level interface namespace and then probably the
`./lumiera` directory will be taken by that. I see no problem also putting some
startup facilities in there, but generally, it shouldn't contain implementation
code, only headers and abstract classes. If that's going to become a problem,
we should consider to use a separate package for the startup, e.g. "src/boot".
Another point is, you need not write a main, because there is already one.
Another point is, you need not write a `main()`, because there is already one.
Please have a look at it, especially with regards to the
[wiki:self:../GlobalInitialization global initialisation]. Further, last year
link:{rfc}/GlobalInitialization.html[global initialisation]. Furthermore, last year
I've investigated boost::program_options and think it's fine. I use it for my
test class runner since then. I don't think there is any reason why we should
bother with parsing options (most config is pulled up from the session). I
don't think we get much program options, maybe something to set a GUI skin.
Moreover, I've written last year a thin wrapper around the commandline and
integrated it with the boost options parser such that user code can receive the
remaining options as a vector of std::strings. Please have a look at
link:http://git.lumiera.org/gitweb?p=LUMIERA;a=blob;f=tests/common/mainsuite.cpp;h=455bfd98effd0b7dbe6597f712a1bdfa35232308;hb=80e1e382f42512ebf2e10a802f77e50327b8fb73[the test class runner main]
remaining options as a vector of `std::string`s. Please have a look at
https://git.lumiera.org/?p=LUMIERA;a=blob;f=tests/common/mainsuite.cpp;h=455bfd98effd0b7dbe6597f712a1bdfa35232308;hb=80e1e382f42512ebf2e10a802f77e50327b8fb73[the test class runner main]
for an usage example. I really want our Lumiera main to be clean and expressive
in the way showed there. Probably the most important part of the startup is
pulling up the session core; because of that I think most of the startup
process falls into the realm of the Proc-Layer. Within Proc, I don't want any
significant string manipulations done with C-strings and I don't want raw
arrays when we can use std::vector.
-- link:Ichthyostega[] [[DateTime(2008-11-06T19:28:13Z)]]
I 'dropped' this now because we do it somewhat differently now and I dont want
to document this here :P
-- link:ct[] [[DateTime(2009-02-03T17:28:28Z)]]
Ichthyostega:: '2008-11-06T19:28:13Z'
I _dropped_ this now because we do it somewhat differently now and I don't want
to document this here 😛
ct:: '2009-02-03T17:28:28Z'
💡 +
[underline]#Historical remark#: this RfC is related to a series of discussions
and controversies during the early stages of the project -- which eventually
helped to establish a style of internal organisation within the application.
After exploring various angles, Lumiera eventually became a *modularised Monolith*
-- using plug-ins for strictly optional parts of the system. Notably, the GUI
is loaded as a plug-in, and the integration with specific media-handling libraries
will rely on plug-in components as well. On the other hand, the core comprises
a small selection of built-in »Subsystems«, which are started with a formalised
lifecycle and dependency management. Flexibility is not attained by allowing
to totally reconfigure the application structure -- rather we allow for an
unusual degree of flexibility by combination and reconfiguration of
behaviour patterns within the application.
Ichthyotega:: '2025-09-20'
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

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

@ -1,12 +1,12 @@
Architecure Overview
====================
[grid="all"]
`------------`-----------------------
*State* _Final_
*Date* _2008-03-06_
*Proposed by* link:Ichthyostega[]
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Final_
|*Date* | _2008-03-06_
|*Proposed by* | Ichthyostega
|====================================
Architecure Overview
--------------------
@ -15,7 +15,8 @@ This proposal intends to capture envisioned Architecture of the Application.
image:{ldoc}/devel/draw/rendered/Lumi.Architecture-1.png[Overview of Lumiera Architecture]
^The SVG source of this drawing is
link:http://www.lumiera.org/gitweb?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD[maintained in GIT]^
https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD[maintained in GIT(2008)]·
https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-2.svg;hb=HEAD[(current: 2022)]^
Description
@ -33,18 +34,15 @@ Description
* the user/GUI manipulates a high-level model whereas rendering is based on a
corresponding low-level model
* stored Session (state) is comprised of high-level model, a collection of
Assets and accompaning configuration
Assets and accompanying configuration
* (possibly) several storage backends, abstracted out by a common interface
Comments
--------
* Alcarinque made link:/documentation/design/gui/GuiDiscussion/Proposal.Alcarinque.html[some
design drafts] for the UI. Here is the
link:/documentation/design/gui/GuiDiscussion/Proposal.Alcarinque.svg[SVG source] (converted
from OODraw by Ichthyo 2011). This is not a technical draft at all, it is just
an idea.
* Alcarinque made link:/x/Proposal.Alcarinque.html[some design drafts] for the UI. +
This is not a technical draft at all, it is just an idea.
* Wouldn't the Config Rules (embedded Prolog) also interact with the High
Level Model? Or would that be expanding its scope too much? I imagine
@ -55,27 +53,29 @@ Comments
the next scene to appear relative to the last scene played. In the first,
you want to keep the scenes always synced up against the audio, while in the
latter, you just want the scenes to appear one after another.
--- link:PercivalTiglao[] [[DateTime(2008-07-16T05:32:45Z)]]
PercivalTiglao:: '2008-07-16T05:32:45Z'
* Yes, indeed, that is what I am planning. The drawing above just doesn't show
every connection. The interaction between high-level model and rules system
mostly goes via the "session defaults", which are facts ''and'' rules. Thus,
in your example, the user would just use the "default placement". My
Intention was to use '''tags''' to quite some extent. The user would be able
mostly goes via the ``session defaults'"'', which are facts _and_ rules. Thus,
in your example, the user would just use the ``default placement'"''. My
Intention was to use *tags* to quite some extent. The user would be able
to tag the source footage, and then rules can kick in when a certain tag
applies. Incidentally, integrating prolog is immediately on the agenda,
because first we want to flesh out the very basic system and get to work
basic rendering. Until then, I use a "mock" implementation of the
basic rendering. Until then, I use a _mock implementation_ of the
query/rules system, which just returns some hard wired defaults.
-- link:Ichthyostega[] [[DateTime(2008-09-04T15:38:21Z)]]
Ichthyostega:: '2008-09-04T15:38:21Z'
Conclusion
----------
Accepted. The drawing was moved into the GIT tree, hopefully it will be
maintained in future.
Accepted. The drawing was moved into the GIT tree. +
It was upgraded and reworked
https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-2.svg;hb=0b9f2e2c3139cad542013caac593cb5972a2e3f6[in 2022]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

123
doc/devel/rfc/CCodingStyleGuide.txt
View file

@ -1,12 +1,12 @@
Design Process : C Coding Style Guide
=====================================
[grid="all"]
`------------`-----------------------
*State* _Final_
*Date* _2007-07-03_
*Proposed by* link:ct[]
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Dropped_
|*Date* | _2007-07-03_
|*Proposed by* | ct
|====================================
@ -23,17 +23,18 @@ Description
In the following I'll explain a C coding style I used frequently for other
projects. Take this as suggestion for parts written in C (it definitely makes
no sense for C++). We probably don't need to enforce this style for normal C
code, but for the related link:Lumiera/DesignProcess/AllPluginInterfacesAreC[]
code, but for the related
link:{rfc}/AllPluginInterfacesAreC.html[Rfc: »All Plugin Interfaces Are C«]
it really makes sense to have some well defined style.
Function names follow the rule:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.`namespace[\_object][\_verb[\_subjects]][\_version]`
* namespace is \'lumiera_\' appended with some subsystem tag
* namespace is `lumiera_` appended with some subsystem tag
(`lumiera_plugin_audio_`)
* object is the type of the \'this\' object we are addressing, maybe followed
by the object we are returning
* object is the type of the `this' (or `self') object we are addressing,
maybe followed by the object we are returning
* verb is the action to take, (new, copy, free, set, clear,.. etc.) if omitted
the action is `get`
* subjects is a descriptive list of the arguments which the action takes, this
@ -50,11 +51,11 @@ Prototypes follow the rule:
* function is the functionname as above
* rettype is sensible to what object and verb define, setters return a pointer
to the set'ed element if an allocation could be involved (or NULL on
failure), a int if the setter does some checks over the supplied argument (0
indicates failure, !0 success), void for procedures and actions which can
failure), a int if the setter does some checks over the supplied argument
(`0` indicates failure, `!0` success), void for procedures and actions which can
never fail.
* Object is a pointer to refered object (\'this\' like C++) in rare cases
(_new()) functions may be used without this self pointer, see below
* Object is a pointer to referred object (`this' like C++) in rare cases
(`_new()`) functions may be used without this self pointer, see below
* `...` are the types and names of the arguments described in `subjects` of the
name.
@ -75,9 +76,9 @@ typedef const namespace_foo ** const_NamespaceFoo_ref; // same for const object
Examples:
+++++++++
.`lumiera_plugin_audio_sample_normalize_limit_1 (AudioSample self, int limit)`
* namespace is \'lumiera_plugin_audio\'
* operates on a \'sample\' object (and likely returns a pointer)
* operation is \'normalize\'
* namespace is `lumiera_plugin_audio`
* operates on a `sample' object (and likely returns a pointer)
* operation is `normalize`
* takes one additional parameter describing the limit for normalization
* this is a version 1 interface we later define:
@ -96,9 +97,6 @@ Examples:
Tasks
^^^^^
Pros
^^^^
@ -129,20 +127,20 @@ overhead to encode arguments to functionnames. But the intention here is to
make code easy readable and memorizeable, when one follows this scheme one does
seldom need to lookup the docs about the API. In fact it sometimes even turns
out that one wants to use a functionname which isn't defined in the API, which
is a good indicator to add such to to the API.
is a good indicator to add such a missing function to the API.
This scheme is not fully unambiguous but suffices for all practical task. It
encodes parameters like C++ does for overloading without strange mangling. All
names are global in a well defined namespace which is very natural for C (other
OO like C styles involve structs and hand written vtables, with this scheme we
trampoline from this global names to vtables *only* if needed)
OO like C styles involve structs and hand written CTables, with this scheme we
trampoline from this global names to VTables _only if needed_)
Conclusion
----------
Finalized on link:MonthlyMeetings[]/Protocol-2008-03-06
Finalized at the link:{ldoc}/devel/meeting_summary/2008-03-06.html[2008-03-06 developer meeting]
@ -150,61 +148,96 @@ Finalized on link:MonthlyMeetings[]/Protocol-2008-03-06
Comments
--------
I strongly object promoting such a thing as a general "Style Guide". It can be
I strongly object promoting such a scheme as a general ``Style Guide''. It can be
a help or last resort if you are forced to work with improper tools (a
situation that's rather frequent in practice though). __As such it is well
chosen and practical__.
chosen and practical__, however.
But basically, it shows several things:
* you are using a global namespace
* you deal with way to fat interfaces
* you mix deployment metadata (a version/compatibility check) with functional
code
All of this indicates some design style breakage, so it would be preferable to
fix the design if possible.
The only part I'd like to support as a Style Guide is the rule of using the
"verb+object" pattern for creating function names
-- link:Ichthyostega[] [[DateTime(2007-07-08T11:42:39Z)]]
Ichthyostega:: '2007-07-08T11:42:39Z'
Probably needs little explanation:
* you are using a global namespace
This is only about C for names which get exported, C only has a global
** This is only about C for names which get exported, C only has a global
namespace and we need some way to get unique names. The
link:Lumiera/DesignProcess/AllPluginInterfacesAreC[] already uses
better/smaller namespaces by defining interfaces as C structs. The full blown
long names explained here are technically not needed when we use the plugin
system as proposed, I just shown them here for completeness. Next, when we
decide for alternative linking methods like static builds we would need to
link:{rfc}/AllPluginInterfacesAreC.html[RfC: Plugin Interfaces in C]
already uses better/smaller namespaces by defining interfaces as C structs.
The full blown long names explained here are technically not needed when we use
the plugin system as proposed, I just shown them here for completeness. Next,
when we decide for alternative linking methods like static builds we would need to
declare all "verb+object" functions static, else there is a high probability of
clashes.
* you deal with way to fat interfaces
How can you tell that? This is only a nameing style. No interfaces mentioned
** How can you tell that? This is only a nameing style. No interfaces mentioned
here. I am all after small well defined specialized interfaces.
* you mix deployment metadata (a version/compatibility check) with functional
code
Yes, I cant figure out how to do it better but still lightweight in C. the
_version thing is something I added here after the interfaces proposal. I work
* you mix deployment metadata (a version/compatibility check) with functional code
** Yes, I cant figure out how to do it better but still lightweight in C. the
`_version` thing is something I added here after the interfaces proposal. I work
on a example how this will be used in a more friendly way.
Note again that this is a "nameing system", it is intended to be very verbose
Note again that this is a ``naming system'', it is intended to be very verbose
and give unique declarative names. It is not about design! Design is done as
usual and only when things have to be exported as C symbols (both, exported and
C!!) this applies. This has zero implication for C++ code, zero implication
for C functions which are not exported (while I personally still prefer this
style) and finally when we do the interfaces thing like I proposed, then the
naming can be much simpler, see examples there or in my repository.
-- link:ct[] [[DateTime(2007-07-10T08:03:06Z)]]
ct:: '2007-07-10T08:03:06Z'
Thanks, your explanation together with the example in git made the usage
pattern much more clear. I think the _version postfix is esp. helpful on the
pattern much more clear. I think the `_version` postfix is esp. helpful on the
names of the plugin interfaces (structs in C), and probably it will be a good
practice, to have one such common plugin interface on every "plugin extension
point", i.e. every point in the sytem, that can be extended by plugins.
-- 217.110.94.1 [[DateTime(2007-07-10T17:23:33Z)]]
practice, to have one such common plugin interface on every ``plugin extension
point'', i.e. every point in the system, that can be extended by plugins.
Ichthyostega:: '2007-07-10T17:23:33Z'
.State -> Dropped
During the last years, I have read this RfC several times, and I am still
not sure what this proposal wanted to achieve, and what was the intention of
proposing it this way. +
A ``C coding style'', a ``naming system'' meant to be very verbose,
but not intended to be about design, yet ``technically not needed when
using the plugin system'' -- which all together touches at
questions of design for sure.
In the early stages of the project, there was a debate revolving around the
idea of bootstrapping the application from a tiny core, with pretty much
any functionality assembled from plugins, and internal functions being
callable directly from Lua code. Combined with a low-ceremony, distributed,
collaborative working style, such a setup was linked to the promise of
fluid evolution of ideas in order to try out unconventional solutions
and see what works best.
Personally, this premise made me feel queasy, because I had a clear vision
in my head, which required to build some rather advanced and challenging
structures. Mastering complexity means to segregate and settle parts of a
problem in order to avoid excess interdependencies. I'd rather attempt
to deflect and redirect flexibility and differentiation towards the
periphery and establish stable yet generic structures in the core.
Ichthyostega:: '2025-09-16'
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

75
doc/devel/rfc/ClipCatalogingSystem.txt
View file

@ -1,12 +1,12 @@
Design Process : Clip Cataloging System
=======================================
[grid="all"]
`------------`-----------------------
*State* _Parked_
*Date* _2008-07-26_
*Proposed by* link:JordanN[]
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Parked_
|*Date* | _2008-07-26_
|*Proposed by* | JordanN
|====================================
Clip Cataloging System
-----------------------
@ -22,7 +22,7 @@ Organizations that work with video, and even home users, tend to have massive
collections of stock videos and images that they will need to find and use in
their projects. A Linux-based system is needed to help them to organize, tag,
and retrieve assets from those collections. Being able to find the clips the
user needs and bring them into his timeline, will mean that the user will be
user needs, and to bring them into his timeline, will mean that the user will be
able to more rapidly complete his project.
This could be implemented as a separate application, but integrated for use in
@ -57,8 +57,6 @@ them correctly. Not clip-based, so the entire video must be imported and the
desired portion selected.
Rationale
~~~~~~~~~
Comments
@ -69,40 +67,49 @@ Comments
development power to do that now. If someone wants to work on that, please
contact me. General idea is to put all kinds of resources (Footage, Clips,
Effects, Subprojects, Sounds ....) into a database with then gets
tagged/attributed in different ways (implicit things like 'filename', 'type',
'length'; automatic deduceable things like 'Exposure', 'Timecode', ...; And
manual tags like: who was on set, location, ....). Then present this all in a
tagged/attributed in different ways (implicit things like `filename', `type',
`length'; automatic deducible things like `Exposure', `Timecode', ...; And
manual tags like: who was on set, location, ...). Then present this all in a
*good* GUI (by default just showing filesysten like) but one can define
queries on this database and the generated views will then be storeable.
Back to Lumiera, for now we will likely just use 'normal' file open dialogs
Back to Lumiera, for now we will likely just use ``normal'' file open dialogs
until the above system becomes available.
-- link:ct[] [[DateTime(2008-07-26T08:31:42Z)]]
* Yes, it's indeed an important feature we should care for. But cehteh is
ct:: '2008-07-26T08:31:42Z'
* Yes, it's indeed an important feature we should care for. But _cehteh_ is
right, we have more important things to do first. But feel free to target it.
* Also, we'd need integration with production support systems, for example
http://celtx.com/[CELTX].
* The interface to the Lumiera App would be to populate the asset manager with
the required assets
-- link:Ichthyostega[] [[DateTime(2008-07-27T22:19:38Z)]]
Ichthyostega:: '2008-07-27T22:19:38Z'
Videos, Audio, Clips and Resources Manager by using plugins for FOSS GPL
"Library & Collections Management" programs.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The video and audio raw material, clips, etc could be managed using code that
is already available in project that carry out the same tasks. For example as
Connect to existing FOSS applications by plugin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A Video-, Audio-, Clips and Resources Manager can be built by using plugins
for existing ``Library and Collections Management'' programs available under GPL,
or at least code from such applications could be used to carry out similar tasks.
For example as
library managers, or media (video, audio or CD) collections, Integrated
Library Systems (ILS).
Examples of a library management program ;
Examples of a library management program:
. Kete - http://kete.net.nz/[]
. Koha - http://www.koha.org/[]
. link:GreenStone[] - http://www.greenstone.org/[]
. Evergreen - http://open-ils.org/faq.php[]
- https://web.archive.org/web/20080514220816/http://www.koha.org/[Koha]
· https://koha-community.org/[2025]
· https://en.wikipedia.org/wiki/Koha_(software)[Wikipedia]
· https://liblime.com/[LibLime (commercial)]
- https://web.archive.org/web/20080613192838/http://kete.net.nz/[Kete]
- https://www.greenstone.org/[GreenStone]
- https://evergreen-ils.org/frequently-anticipated-questions/[Evergreen]
An additional benefit to using "library" managers, is that it can handle
interloans, referencing of "other" (people's/organization's) libraries,
An additional benefit to using ``library'' managers, is that it can handle
interloans, referencing of ``other'' (people's / organization's) libraries,
numbering systems, descriptions, and classifications, thousands to millions of
items, search systems, review and comment systems, plus the benefits of open
source that allow the expansion of features easily. The use of task oriented
@ -113,16 +120,18 @@ working with cataloging systems for a long time is likely to do well. Plus it
can be readily improved, by people who do not have to know the first thing
about how to design video editing programs. The program also gets improved
because of it own community, which adds features or performance to Lumiera,
without even having to "drive" the development..
--link:Tree[][[DateTime(2008-08-27T20:38:00NZ)]].
without even having to ``drive'' the development..
Tree:: '2008-08-27T20:38:00NZ'
''''
Parked until someone cares
~~~~~~~~~~~~~~~~~~~~~~~~~~
Decided on Developer meeting
Decided in link:{ldoc}/devel/meeting_summary/2011-04-13.html#_clip_cataloging_system[Developer meeting]
Do 14 Apr 2011 02:52:30 CEST Christian Thaeter
Christian Thaeter:: 'Tur 14 Apr 2011 02:52:30 CEST'
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

40
doc/devel/rfc/CodingStyle.txt
View file

@ -1,12 +1,12 @@
Design Process : Coding Style
=============================
[grid="all"]
`------------`-----------------------
*State* _Final_
*Date* _2007-06-27_
*Proposed by* link:ct[]
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Final_
|*Date* | _2007-06-27_
|*Proposed by* | ct
|====================================
@ -23,17 +23,17 @@ Description
We need to agree on some coding style, IMHO consistency is the most important
part with this, no matter which style we use.
See http://en.wikipedia.org/wiki/Indent_style[]
See https://en.wikipedia.org/wiki/Indentation_style[Wikipedia: Indentation Style]
.Notes:
* no tabs, use spaces!
.Proposed:
* K&R by _ichthyo_
* compact and well known
** compact and well known
* GNU by _cehteh_
* imo the best readability (albeit little strange)
* Lumiera might apply as official GNU project someday
** imo the best readability (albeit little strange)
** Lumiera might apply as official GNU project someday
Another question: __how to write identifiers?__
@ -65,11 +65,11 @@ CT:: '2007-07-03 04:04'
Comments
--------
Since link:ct[] called spaces instead of tabs first, we should stick to that. I
Since ct called spaces instead of tabs first, we should stick to that. I
think all other reasons will lead us to nowhere!
Although I'm used to a BSD/KNF-like coding style I will try the GNU one. After
all, the wikipedia page mentions no disadvantages of that style :)
all, the wikipedia page mentions no disadvantages of that style 😊
MichaelPloujnikov:: '2007-06-27 17:17'
@ -77,12 +77,22 @@ MichaelPloujnikov:: '2007-06-27 17:17'
I just proposed K&R because it is widely accepted. Personally, I was never very
fond of K&R style, I always preferred putting opening braces to the left. I
never used GNU style until now, but it looks somewhat appealing to me. (btw,
ECLIPSE comes with presets for all this styles :-P ). Anyhow, I can adapt to
ECLIPSE comes with presets for all this styles 😛 ). Anyhow, I can adapt to
most any style. The only thing I really dislike is using tabs (with the
exception of database DDLs and CSound files, where tab are actually helpful) :)
exception of database DDLs and CSound files, where tab are actually helpful) 😊
Ichthyo:: '2007-06-27 20:55'
Many years later -- we are still using GNU style and over time have developed
a »Lumiera flavour« which plays well with C++, templates and λ-functions.
A striking consequence is that the code looks light, favours short functions,
is rather vertically oriented and is easy to skim while scrolling.
-> see our link:/x/CodeStyle.html[Style guide].
Ichthyo:: '2025-09-05'
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

79
doc/devel/rfc/ConfigLoader.txt
View file

@ -4,12 +4,12 @@ Config Loader
// please don't remove the //word: comments
[grid="all"]
`------------`-----------------------
*State* _Parked_
*Date* _2008-08-07_
*Proposed by* **ct**
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Dropped_
|*Date* | _2008-08-07_
|*Proposed by* | **ct**
|====================================
********************************************************************************
.Abstract
@ -44,8 +44,8 @@ NOTE: (by _Ichthyostega,_ 2023) +
Parked
~~~~~~
.State -> Parked
While the general idea seams adequate, the topic of Configuration
requires a much more in-depth Requirement Analysis. Moreover, considering
the state of tooling today (2023), I consider it questionable still to rely
@ -64,13 +64,35 @@ to be addressed _after achieving the first integration_ of the Engine.
Ichthyostega:: '2023-10-24' ~<prg@ichthyostega.de>~
.State -> Dropped
Lumiera needs a system for configuration, but it will not work as proposed here.
The reasons for this decision can be traced back to questions of architecture
and the intended use of ``Configuration''. This became first clear in a
discussion between _Cehteh_ and _Ichthyo_, as they were walking together
through the forest north of the Karlsruhe castle in August 2011.
//Conclusion
//----------
//conclusion: When approbate (this proposal becomes a Final)
// write some conclusions about its process:
While _Cehteh_ aims at an unified set of configuration data, composed by
layering system-, user- and further local configuration files, to be combined
with textual expansion- and replacement mechanisms -- and the ability to
target a wide array of ``settings'' within the application, the intentions
of _Ichthyo_ go into an almost antithetical direction: He rather wants
to split off a very limited set of ``parametrisation'' and ``installation
configuration'', while handling most of the other possible choices by evaluation
of _configuration rules,_ which are tightly interwoven with the Session and
are actively resolved in the Builder, as opposed to being provided by a global
static _configuration service._ With this model, configuration can be injected
from various sources as a structured set of _facts._ Furthermore, _Ichthyo_
wants to isolate the behaviour of the application from ad-hoc tweaks through
textual replacements and environment variables, rather looking for ways to
record any application of rules or facts in the global _Event Log._
Ichthyostega:: '2025-09-20'
....
​
​
....
~What follows below is extended documentation for _Cehteh_'s Config System proposal...~
''''''''''''''''
@ -147,7 +169,7 @@ API
- lumiera_config_init (const char* searchpath) searchpath is a buildin-default, can be changed via configure and can be appended and overridden by using a flag, e.g. `--config-path-append=""` or `--config-path=""`
* `lumiera_config_destroy(...)`
- frees all space allocated by the link:ConfigLoader[].
- frees all space allocated by the ConfigLoader.
* `lumiera_config_load(...)`
- reads *one* single configuration file that will include all settings from other files.
@ -205,10 +227,12 @@ API
.foo.bar
=======================================
`integer_set("foo.bar", 123)`
looks up "foo.bar"
this returns as well file and line
it will be decided whether it's a system file or a user's config file.
if systemfile: loop for user's config file, if necessary create it in our RAM but not yet on disk
- this returns as well file and line
- it will be decided whether it's a system file or a user's config file.
- if systemfile: loop for user's config file, if necessary create it in our RAM but not yet on disk
set the value in the line.
=======================================
@ -236,16 +260,15 @@ anchor:anchor_config[]lumiera_configfile
anchor:anchor_types[]provided TYPES
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[grid="all"]
`--------------.--------------------------------------'------------------------------------------------------------
config type C type semantic (example)
-------------------------------------------------------------------------------------------------------------------
number signed long long also hex and octal (foo.bar = 12345 #comment)
real long double differerent formats as well (foo.bar=1.2345 #comment)
string const char* optionaly quoted string (foo.bar="this string" #this not)
word const char* first optionaly quoted word of the config (foo.bar= first this # not)
bool int common representations for bools (0,1,true,false,yes,no,on,off,set,clear)
-------------------------------------------------------------------------------------------------------------------
[options="header", cols="^,2^m,6"]
|====================================
|config type | C type | semantic (example)
|number |signed long long | also hex and octal (foo.bar = 12345 #comment)
|real |long double | differerent formats as well (foo.bar=1.2345 #comment)
|string |const char* | optionaly quoted string (foo.bar="this string" #this not)
|word |const char* | first optionaly quoted word of the config (foo.bar= first this # not)
|bool |int |common representations for bools (0,1,true,false,yes,no,on,off,set,clear)
|====================================
... add more types on demand (ichthyo mentioned a tuple type for color triples etc.)
@ -314,7 +337,7 @@ semantics notes:
anchor:anchor_links[]links
~~~~~~~~~~~~~~~~~~~~~~~~~~
http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html[]
https://specifications.freedesktop.org/basedir-spec/0.6/[]
anchor:anchor_internals[]internals/implementation sketch
@ -591,7 +614,7 @@ Discussion on irc
[02:06] <__nasa__> There should be a callback for a plugin to add a config file for that plugin.
[02:06] <__nasa__> Ooh
[02:06] <__nasa__> cool idea
[02:06] <cehteh> this is not really complicated to do but would give a big usage experience link:JustWorks[][TM]
[02:06] <cehteh> this is not really complicated to do but would give a big usage experience JustWorks[TM]
[02:06] <__nasa__> ~/.lumi/config is the main configuration directory
[02:06] <__nasa__> inside, there is a ~/.lumi/config/config.ini which is main configuration
[02:07] <cehteh> no callbacks .. the idea is that the config system is independent and nothing else need to register there, that makes it much easier

116
doc/devel/rfc/DataBackend.txt
View file

@ -1,12 +1,12 @@
Design Process : Data Backend
=============================
[grid="all"]
`------------`-----------------------
*State* _Parked_
*Date* _2007-06-04_
*Proposed by* link:ct[]
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Dropped_
|*Date* | _2007-06-04_
|*Proposed by* | ct
|====================================
DataBackend
-----------
@ -17,36 +17,34 @@ Description
~~~~~~~~~~~
This just starts as braindump, I will refine it soon:
. handle all files lumiera uses at runtime (media, edl, temp data)
. manage filehandles, lumiera might use more more files than available
filehandles
. manage temporary data
. do caching
. io will be blocked where the backend tells the core where it can expect the
data (not read()/write() like)
. kindof garbage collector
. do prefetching
. no/low latency for the core the prefetcher and other things ensure that data
is available in time
. translate any input into a format which the lumiera core understands (demux,
decode)
. same for encoding to output formats
. offer a plugin API for encoders/decoders
. maybe network backend for serving data to distributed rendernodes
. can do some load control or management (trigger adaptive rendering if system
is idle etc)
. pull based arch
- handle all files lumiera uses at runtime (media, edl, temp data)
- manage filehandles, lumiera might use more more files than available filehandles
- manage temporary data
- do caching
- IO will be blocked where the backend tells the core where it can expect the data (not `read()`/`write()` like)
- kindof garbage collector
- do prefetching
- no/low latency for the core the prefetcher and other things ensure that data is available in time
- translate any input into a format which the lumiera core understands (demux, decode)
- same for encoding to output formats
- offer a plugin API for encoders/decoders
- maybe network backend for serving data to distributed rendernodes
- can do some load control or management (trigger adaptive rendering if system is idle etc)
- pull based architecture
.Notes:
* ichthyo wrote also some ideas on
http://www.pipapo.org/pipawiki/Cinelerra/Developers/ichthyo/Cinelerra3/Architecture[Architecture] and a sketch/draft about http://www.pipapo.org/pipawiki/Cinelerra/Developers/ichthyo/Possibilities_at_hand[things possible in the middle layer]
* ichthyo wrote also some ideas regarding
link:http://localhost:8888/project/background/history/PossibilitiesAtHand.html[things possible in the middle layer]...
Parked
~~~~~~
Conclusion: Dropped
-------------------
The underlying principles remain valid, yet development took another
direction during the last years. Special frameworks for high-performance
asynchronous IO will be used for dedicated use cases.
asynchronous IO will be used for dedicated use cases. A garbage collector
is not necessary, since Lumiera relies on deterministic memory management.
Furthermore, decoding, transcoding and encoding is handled as part of the
pipeline and not through a separate service.
Ichthyostega:: '2023-10-24' ~<prg@ichthyostega.de>~
@ -56,15 +54,63 @@ Comments
--------
Sounds fairly complete to me
-- link:Ichthyostega[] [[DateTime(2007-06-16T23:19:44Z)]]
Ichthyostega:: '2007-06-16T23:19:44Z'
Developement takes place in the repo now
-- link:ct[] [[DateTime(2007-06-27T16:14:56Z)]]
ct:: '2007-06-27T16:14:56Z'
.State -> Parked
Development took another direction over the last years;
the former »Backend« layer is restructured
-- link:Ichthyostega[] [[DateTime(2023-10-24T22:45:55Z)]]
the former »Backend« layer is called »Vault« now and structured differently.
Ichthyostega:: '2023-10-24T22:45:55Z'
.State -> Dropped
The approach to most of the topics listed in this RfC has shifted, and thus
it is time to draw the conclusion that overall Lumiera will not use a »Backend«
as an _adaptation layer,_ in the way envisioned here. Notably the idea of
centralising _any access to resources_ to apply some kind of instrumentation
and regulation is rejected. Rather, the »Vault« (as it is called now),
provides specialised low-level services with deep vertical integration;
this implies rather to establish dedicated control circuits for a small
number of special resources deemed performance critical.
Most topics touched by this RfC however remain relevant,
yet will be approached differently...
- while non-blocking, asynchronous I/O is still considered essential,
it is acknowledged that getting a grip at the resource usage of
external libraries and frameworks, integrated via plug-in, is a
non-trivial task, and must be approached at a case-by-case base.
- the Scheduler provides a much more high-level and specialised
execution service then intended initially; the majority of
resource usage regulation will be achieved by adjusting the
job generation, which is connected to high-level structures,
while relying on generic resource observation facilities
in the Vault.
- the Cache service will require a deep integration with the Builder
and the media / asset management; _cache invalidation_ will be
based on a _naming and identification scheme,_ which requires
explicit support by the high-level metadata management.
- the Vault has no connection to media processing whatsoever,
it does not decode / encode data or mark and map parts of
media streams; this topic is coordinated at the level of
the builder and delegated to external facilities, while
the Vault provides some dedicated resource management
(notably handling GPU access and shader code)
- file handles and generic file access are considered a non-issue,
as is the occasional usage of multithreading -- as long as any
substantial parallelism is organised through the scheduler.
Ichthyostega:: '2025-09-20'
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

122
doc/devel/rfc/DelectusShotEvaluator.txt
View file

@ -1,9 +1,12 @@
[grid="all"]
`------------`-----------------------
*State* _Parked_
*Date* _2008-09-21_
*Proposed by* link:nasa[]
-------------------------------------
Design Process : Delectus
=========================
[options="autowidth"]
|====================================
|*State* | _Parked_
|*Date* | _2008-09-21_
|*Proposed by* | nasa
|====================================
Delectus Shot Evaluator
@ -14,16 +17,14 @@ This is a brain dump about the shot evaluator subproject.
Description
~~~~~~~~~~~
Brainstorm on Delectus
~~~~~~~~~~~~~~~~~~~~~~
.A collection of Ideas
Some (many) of the ideas presented herein come from the various parties
involved in the Lumiera discussion list and IRC channel #lumiera.
http://lists.lumiera.org/pipermail/lumiera/2008-September/000053.html[] -- the
main discussion thread
involved in the Lumiera Mailing List and IRC channel `#lumiera` -- here is the
http://lists.lumiera.org/pipermail/lumiera/2008-September/000053.html[main discussion thread].
Additionally, a lot of great concepts for how to streamline the interface are
derived in part from link:KPhotoAlbum[].
derived in part from https://www.kphotoalbum.org/[KPhotoAlbum].
I use tags, keywords, and metadata almost interchangeably, with the exception
that metadata includes computer generated metadata as well. These are not tags
@ -42,7 +43,7 @@ support (please add more!) is:
As such, the tags themselves can have metadata. You can see where this is
going...
Also, the tags are applied to "clips" -- which I use interchangeably between
Also, the tags are applied to ``clips'' -- which I use interchangeably between
source material imported into the application and slice of that material that
tags are applied to. Any section of a video or audio source can have tags
applied to it.
@ -68,9 +69,9 @@ Some key points:
* Technically flawed footage can be both manual and computer classified.
* In some cases (e.g. documentaries, dialog) audio and video clips/footage can
follow different section processes.
It is possible to use video from footage with useless audio or use audio
from footage with useless video.
* "Interesting" is designed to be broad and is explained below.
- It is possible to use video from footage with useless audio or use audio
from footage with useless video.
* ``Interesting'' as a category is meant be broad and is explained below.
* steps 2-5 can be performed in parallel by numerous people and can span many
different individual clips.
@ -106,7 +107,7 @@ The key to adequate expressive power is as follows:
* Connection to on site documentation and pre-production documentation. When
making decisions about what material to use and how to classify it, it is
essential to use any tools and resources available. The two most useful are
onsite documentation (what worked/didn't work, how the weather was, pictures
on-site documentation (what worked/didn't work, how the weather was, pictures
of the setup, etc all at the shoot) and pre-production (what the ideal scene
would be, what is intended, etc). Anything else that would be useful should
be supported as well.
@ -143,7 +144,7 @@ vice-versa.
Interesting
^^^^^^^^^^^
An "interesting" clip is one that has potential -- either as a metadata piece
An _interesting clip_ is one that has potential -- either as a metadata piece
(multimedia note, talent briefing, etc) or footage (for the final product OR
intermediary step). The main goal of the application is to find and classify
interesting clips of various types as quickly as possible.
@ -181,10 +182,10 @@ that by having parts of individual clips, metadata, or other files be specific
to one aspect of the overall design. This allows for much more successful use
of the related information and a cleaner, streamlined layout. As an example,
metadata involving file size has no effect whatsoever on the vast majority of
most major decisions -- the answer is almost always "whatever it takes." Thus,
most major decisions -- the answer is almost always ``whatever it takes''. Thus,
it would not appear most of the time. Content narrowing means that it is easy
to add back footage -- "widen the view" one step, add it back, and "narrow the
view" again.
to add back footage -- ``widen the view'' one step, add it back, and ``narrow
the view'' again.
Multiple cuts
@ -206,7 +207,7 @@ THE SCENE), take (what is actually going on IN THIS SPECIFIC RUN), and instance
(what is actually going on IN THIS CLIP). If editing a situation, the other
referenced clips AUTOMATICALLY add metadata and relevant sections. This can be
as precise and nested as desired, though rough cuts for level one editing
(first watchthrough after technically well executed clips have been selected)
(first watch-through after technically well executed clips have been selected)
and more accurate ones for higher levels is the recommended method.
@ -223,12 +224,12 @@ nasa's Laws of Tagging
(reasonable) number of tags. This is OK. All that is needed is the minimum
set of unique tags to progress to the next cycle without losing editing
intent or the ability to rapidly evaluate many situations.
. Many tags are used many times. "Outdoors" will be a very, very common tag; so
will "redub." If conventional names are decided upon and stuck to, it is
. Many tags are used many times. `Outdoors` will be a very, very common tag; so
will `redub`. If conventional names are decided upon and stuck to, it is
significantly easier to map the complex interactions between different
content situations.
. Avoid compound tags. Do not have "conversation_jill_joe" as a tag; use
"conversation," "jill," and "joe" instead. It is very easy to search for
. Avoid compound tags. Do not have ``conversation_jill_joe'' as a tag; use
``conversation'', ``jill'', and ``joe'' instead. It is very easy to search for
multiple tags and very hard to link data that doesn't use overlapping tags.
@ -257,15 +258,16 @@ sections are allowed.
Prompting Prompting for metadata is a laborious, time-consuming process. There
is no truly efficient way to do it. This application uses a method similar to
link:KPhotoAlbum[]. When the space key is held and a letter is pressed, the tag
_KPhotoAlbum_. When the space key is held and a letter is pressed, the tag
that corresponds to that letter is assigned to the track for the duration of
the press. (If the space is pressed and no other key is pressed at the same
time, it stops the track.) For example, suppose that the following mapping is
present:
o = outside
x = extra
p = protagonist
c = closeup
o ⟼ outside
x ⟼ extra
p ⟼ protagonist
c ⟼ closeup
Then holding SPACE over a section and pressing one of these keys would assign
the tag to the audio AND video of the section over which the space was held. If
@ -277,15 +279,18 @@ If LALT is held down instead of SPACE, the audio is effected instead. If RALT
is held, just the video is effected.
In order to support scenario/take/clip tagging:
The default is situation. If the keybinding to x is:
x = t:extra ; effect only take
x = ts:extra ; effect take and scenario
x = c:extra ; extra only visible in this clip!
x = tc:extra ; this take and clip show the extra
etc
- The default is situation. If the keybinding to x is:
** x = t:extra ; effect only take
** x = ts:extra ; effect take and scenario
** x = c:extra ; extra only visible in this clip!
** x = tc:extra ; this take and clip show the extra
** ...
Other keyargs (the part in front of the colon) can be added to account for
other uses (e.g. l = all taken on the same location).
other uses +
(e.g. l = all taken on the same location).
Tab is pressed to add metadata mappings. Tab is pressed to enter metadata edit
mode; this pauses video. Then press any key to map; and type the tag to
@ -306,12 +311,9 @@ defined:
If ESC is pressed, all currently ranged tags are ended.
Finally, if single_quote is pressed without SPACE or {L,R}ALT down, it marks an
"interesting location." Pressing SHIFT+single_quote goes to the next
"interesting location" and pressing CNTRL+' goes to the previous "interesting
location." This allows for very quick review of footage.
``interesting location''. Pressing SHIFT+single_quote goes to the next
``interesting location'' and pressing CNTRL+' goes to the previous
``interesting location''. This allows for very quick review of footage.
@ -335,28 +337,29 @@ The importance/value of the video for various factors uses, can vary through
the video. It would be helpful to have the ability to create continuous ratings
over the entire track. Ratings would be numerical. Automatic clip
selection/suggestion could be generated by using algorithms to compute the
usefulness of video based on these ratings (aswell as "boolean
operations"/"binary decisions" done with tags). The ratings could be viewed
usefulness of video based on these ratings (as well as ``boolean operations''
rsp. ``binary decisions'' done with tags). The ratings could be viewed
just like levels are - color coded and ovelayed on track thumbnails.
- Tree 2008-10-25
Tree:: '2008-10-25'
link:MultiView[] - useful for concurrent ratings input
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
MultiView - useful for concurrent ratings input
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It would be convenient to have an ability to view the different tracks (of the
same scene/time sequence) at once, so the viewer can input their ratings of the
video "on the fly", including a priority parameter that helps decide which
video ``on the fly'', including a priority parameter that helps decide which
video is better than what other video.See the GUI brainstorming for a viewer
widget, and key combinations that allow both right and left hand input, that
could be used for raising/lowing ratings for up to six tracks at once.
- Tree 2008-10-25
Tree:: 2008-10-25
I like the idea of rating clips (or rather, takes) a lot. It would be cool to
include both "hard," "relative," and "fuzzy" rating. Hard is an exactly defined
include both `hard', `relative', and `fuzzy' rating. Hard is an exactly defined
value (scaled 0-1) that puts the clip in an exact location in the queue.
Relative means that one is higher or lower rated than another. Fuzzy is a
slider which is approximate value, and there is some randomness. The best part
@ -367,7 +370,7 @@ sort of heap (think binary heap, at least for the data structure) which
determines the priorities and decides which clips are played. Then the highest
rated clips are played first, down to the worst.
- link:NicholasSA[] 2009-01-04
NicholasSA:: '2009-01-04'
Possible Collaboration with the people from Ardour?
@ -376,14 +379,15 @@ Possible Collaboration with the people from Ardour?
I guess if the thing can do all the things we talked about here, it would be
perfectly suitable for sound classification too, and maybe could fill another
gap in FOSS: Audio Archival Software, like this:
http://www.soundminer.com/SM_Site/Home.html[] (which is very expensive)...
https://web.archive.org/web/20100618104752/http://www.soundminer.com/SM_Site/Why_Buy.html[soundminer.com]
(which is very expensive)...
maybe the Ardour people would be interested in a collaboration on this?
I like the suggestion of sound classification with a similar (or, even better,
identical) evaluator. link:SoundMiner[] looks interesting, but like you say
very expensive. I'm a sound guy, so I feel your pain...
- link:NicholasSA[] 2009-01-04
NicholasSA:: '2009-01-04'
Parked
@ -391,7 +395,7 @@ Parked
Decided on Developer meeting, until someone wants to investigate this further.
Do 14 Apr 2011 02:52:30 CEST Christian Thaeter
ct:: 'Thu 14 Apr 2011 02:52:30 CEST'
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

59
doc/devel/rfc/DesignParamAutomation.txt
View file

@ -1,23 +1,22 @@
[grid="all"]
`------------`-----------------------
*State* _Idea_
*Date* _2008-03-06_
*Proposed by* link:Ichthyostega[]
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Idea_
|*Date* | _2008-03-06_
|*Proposed by* | Ichthyostega
|====================================
Design the handling of Parameters and Automation
------------------------------------------------
Parameters of Plugin Components and/or Render Nodes play a role at various
levels of the application.
+
Thus it seems reasonable to do a formal requirements analysis and design prior
to coding.
Description
~~~~~~~~~~~
Regarding components directly participating in the render (which may be
Regarding components directly participating in the render (which might be
implemented by plugins), we distinguish between *configuration* (static) and
*parameters* (dynamic). The point of reference for this distinction is the
render process: a plugin configuration may well be variable in some manner,
@ -34,8 +33,7 @@ Tasks
* we need to work out an introspection mechanism for parameters
- asses what different types of parameters we need
- find out how much structured parameters will be (do simple values
suffice?)
- find out how much structured parameters will be (do simple values suffice?)
- define how parameters can be discovered/enumerated
- define a naming scheme for parameters, so they can be addressed
unambiguously
@ -46,16 +44,16 @@ Tasks
So...
. find out to which extend we need these properties
. find out to which extent we need these properties
. find out what parts of the App will have what requirements?
. chose a best fitting implementation based on this information
A closely related issue is the handling of *Automation*. The current draft
calls for an abstract interface "ParamProvider", which just allows the
link:Plugin/RenderComponent[] to pull a current value, without knowing if the
ParamProvider is a GUI widget or an automation data set with interpolation. The
component using the param value should not need to do any interpolation. We
should re-asses and refine this draft as needed. Note: Render Nodes are
calls for an abstract interface `ParamProvider`, which just allows the
Plugin or RenderComponent to pull a current value, without knowing if the
`ParamProvider` is a GUI widget or an automation data set with interpolation.
The component using the param value should not need to do any interpolation.
We should re-asses and refine this draft as needed. Note: Render Nodes are
stateless; this creates some tricky situations.
@ -68,17 +66,38 @@ Alternatives
^^^^^^^^^^^^
?? (any ideas?)
One alternative would be _not to recognise_ that this is a problematic requirement,
and just to hack away and ``solve'' each obstacle in an ad-hoc manner.
Unfortunately I'm unable to take this ``alternative'' seriously.
Another approach could be to reject the idea of ``parameters'' being _something special_
and rather to treat them as some kind of _different medium_ -- which would subject
a _parameter stream_ to pull-processing. This seems to be an interesting angle, since
going that route would remove the topic of parameters and automation from the core
render engine altogether. However, I am not _bold enough_ to embrace this approach
as a solution -- since I can not see to what extent such a shift would _actually_
change anything of the actual functionality to be implemented or remove any overhead.
Ichthyostega:: '2025-09-10'
Rationale
~~~~~~~~~
The rationale of this RfC is to conduct some requirement analysis before the
point where the aforementioned features will actually be required to continue
with the coding work. In an ideal world, such analysis would be carried out
in parallel by someone knowledgeable enough to recognise the difficulties.
Comments
--------
This seems to be one of those nasty features which do not garner any engagement
nor spur any creativity. At some point you'll just happen to need it, and then,
I'm afraid the analysis and planning work will incur significant delay...
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
Ichthyostega:: '2025-09-10'
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

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

@ -1,17 +1,18 @@
[grid="all"]
`------------`-----------------------
*State* _Parked_
*Date* _2008-03-06_
*Proposed by* link:Ichthyostega[]
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Parked_
|*Date* | _2008-03-06_
|*Proposed by* | Ichthyostega
|====================================
Design the Render Nodes interface
---------------------------------
In the current design, the low-level model is comprised of "Render Nodes";
Stean-Layer and Vault carry out some colaboration based on this node network.
+
In the current design, the low-level model is comprised of ``Render Nodes'';
Steam-Layer and Vault carry out some collaboration based on this node network.
Three different interfaces can be identified
* the node wiring interface
* the node invocation interface
* the processing function interface
@ -22,22 +23,22 @@ Description
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
a result, output nodes are _pulled_ via the invocation interface, resulting
in the affected nodes to recursively pull their predecessor(s). In the course
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 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.
NOTE: Render Node is an internal interface used by Steam-Layer and
activated by the Vault. Plugins are planned to be added via Adaptor nodes.
Thus the Render Node interface needs _not_ to be exported.
the wiring interface
^^^^^^^^^^^^^^^^^^^^
This part of the design defines how nodes can be combined and wired up by the
builder to form a network usable for rendering. For this purpose, the
link:ProcNode[] is used as a shell / container, which is then configured by a
`ProcNode' is used as a shell / container, which is then configured by a
Connectivity descriptor. Thus, the node gets to know its predecessor(s) and is
preselected to use a combination of specific working modes:
@ -59,18 +60,18 @@ corner case.
the invocation interface
^^^^^^^^^^^^^^^^^^^^^^^^
this is intended to be a rather simple "call-style" interface, without much
possibilites to influence the way things are happening. You pull a node and
this is intended to be a rather simple ``call-style'' interface, without much
possibilities to influence the way things are happening. You pull a node and
will find the results in a provided buffer or the cache, but you can't even
change the frame data type type of the result. Besides the node invocation,
functions for collecting statistics will be accessible here too (Probably these
functions will be ''implemented'' in a classic-OO fashion by virtual functions,
functions will be _implemented_ in a classic-OO fashion by virtual functions,
but that's another story)
the processing interface
^^^^^^^^^^^^^^^^^^^^^^^^
the individual nodes are configured to call a plain-C {{{process()}}} function
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 vault layer or provided by a plugin.
@ -81,7 +82,7 @@ processing function is supposed to do The Right Thing ^TM^
Tasks
^^^^^
* What services do we expect from Render Nodes. What do we plan to do with a
* 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 Steam / Vault. Find out specific
@ -98,13 +99,14 @@ Tasks
Rationale
~~~~~~~~~
The purpose of this Design Entry is to give a summary; the questions and the
The purpose of this Design Entry is to give a summary and to spur the discussion
regarding the responsibilities of Steam vs Vault; 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[Development internal doc (TiddlyWiki)]
link/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]
https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/proc/engine/procnode.hpp;h=9cf3a2ea8c33091d0ee992ec0fc8f37bb5874d34;hb=f9452f654cf39a4abbbeecfd81bef51aa347b321[Draft: ProcNode (src)]
for details
(and/or contact Ichthyo for in-depth discussion of those technical details)
@ -113,15 +115,12 @@ for details
Comments
--------
Parked
~~~~~~
We park this until we have time to revisit the details. It is accepted that we
need to design this interfaces.
Do 14 Apr 2011 03:06:42 CEST Christian Thaeter
Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

68
doc/devel/rfc/DeveloperDocumentationStructure.txt
View file

@ -3,12 +3,12 @@ Developer Documentation Structure
// please don't remove the //word: comments
[grid="all"]
`------------`-----------------------
*State* _Draft_
*Date* _Mon Aug 2 18:03:25 2010_
*Proposed by* Cehteh + Ichthyo
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Final_
|*Date* | _Mon Aug 2 18:03:25 2010_
|*Proposed by* | Cehteh + Ichthyo
|====================================
********************************************************************************
We describe here how to bring the Lumiera Developer Documentation into an simple
@ -32,7 +32,7 @@ The Lumiera (developer) documentation shall be organised in the following way:
link:{ldoc}/user/intro/intro.html[Lumiera from Outer Space],
which outlines our vision and the fundamental concepts.
. there is a section holding our link:{ldoc}/design/[design documents].
Deliberately, these are written so to omit any technicalities,
Deliberately, these are written in a way omitting any technicalities,
which keeps them valid as the technology evolves.
. the entrance to the technical documentation is formed by
link:{ldoc}/technical/overview.html[The inner Core] document.
@ -69,14 +69,16 @@ Tasks
~~~~~
// List what would need to be done to implement this Proposal in a few words:
* Go over the existing content and the remainder of the asciidoced tiddlywikis,
integrate this content either in directly into the "Lumiera: The inner Core"
* Go over the existing content and the remainder of the Asciidoced TiddlyWikis,
integrate this content either in directly into the
link:{ldoc}/technical/overview.html[»Lumiera: The inner Core«]
document or write separate documentation pages or RFC's. ([green]#✔ done#)
* The 'proc' tiddlywiki is a bit special, we need a plan how to integrate this.
[red yellow-background]#TBD#
* The »Renderengine« TiddlyWiki is a bit special, we need a plan how to integrate this.
* Create a facility to support the cross-linking between the various kinds of documents
[yellow-background]#WIP#
[red yellow-background]#TODO#
CAUTION: this issue with stable cross-links
-> link:{rfc}/WebsiteSupportMarkup.html[remains a concern]
Pros
@ -121,9 +123,23 @@ developers.
//Conclusion
//----------
//conclusion: When approbated (this proposal becomes a Final)
//conclusion: When approvedd (this proposal becomes a Final)
// write some conclusions about its process:
This RfC had been started initially by _Cehteh_ to propose a _simple structure_ --
the ensuing discussion however showed that our documentation is already structured
in a mostly consistent way, which just happens to be not that simple. Some confusing
redundancies could be removed, as result from that discussion. _Ichthyo_ then edited
and extended the original RfC to reflect the existing structure.
A serious problem is posed by the rather tedious procedure to define cross-links in the
Asciidoc based web content. link:{rfc}/WebsiteSupportMarkup.html[Another RfC] was created
to discuss these problems in detail, leading to a solution proposal, which unfortunately
was never implemented (due to lack of developer capacity). This _somehow transitory_
situation had the (adverse) effect that most detailed technical content was authored
within the Development TiddlyWiki.
These remaining problems do not seem to be related to the _structure_ of the documentation
however, which seems to fulfil its purpose. So this RfC now counts as de-facto standard.
@ -137,12 +153,12 @@ Comments
which includes the documentation. Why should we overthrow these results now and
re-start the discussion? Lets just stick to this agreed on structure!
* especially I don't like the way this proposal tries to squeeze everything into
an completely uniform structure. It is simply not true that the RFCs are just the
a completely uniform structure. It is simply not true that the RFCs are just the
second level, and doxygen would cover the 3^rd^ level. Look at the existing
documentation to see why.
- RFCs are a 'kind' of document, not a 'hierarchy level.' Indeed, our existing
- RFCs are a `kind' of document, not a `hierarchy level'. Indeed, our existing
RFCs span all three hierarchy levels, and this is OK so and should remain this
way. (And yes, I like the RFCs much and want to retain them)
way. (And, in fact I consider the RFCs relevant and want to retain this formalism)
- RFCs are well suited to topics requiring discussion and agreement by the whole
core developer team. I see no point in 'pseudo-RFC-ing' the individual design
decisions only relevant for an isolated part of the application and without
@ -154,11 +170,11 @@ Comments
when asciidocing the content).
* so my conclusion is rather having one overview text, and then the split into
*conceptual* and *technical* documentation, each of which has a separate sub
structure not necessarily congruent to the structure on the other half. RFCs,
structure not necessarily congruent to the structure at the other half. RFCs,
UML model and doxygen are just separate and consistent bodies of documentation
and can be referred to from the main documentation. (I agree with the observation
regarding permanent links into doxygen. But I can't imagine there isn't some
existing solution to this problem)
existing solution to this problem, waiting to be discovered)
Ichthyostega:: '2010-10-15' ~<prg@ichthyostega.de>~
@ -173,4 +189,20 @@ documentation in textual form, which is inherentely structured.
Ichthyostega:: 'Mo 09 Sep 2013 01:01:25 CEST' ~<prg@ichthyostega.de>~
.State -> Final
I am using this structure since several years now, without encountering any
serious mismatch or incompatibility. The situation with the cross-linking
generator, which still remains to be implemented, is obviously some kind
of impediment, since it prevents me from migrating more mature content
from the TiddlyWiki into the documentation section of the website.
Furthermore, I should notice, as a limitation, that I am the _only one_ to
use this structure actively -- so the fact that I feel comfortable with
the arrangement should be taken with a grain of salt. Yet, on the other
hand, we have meanwhile a massive body of information structured
this way, so that it can be considered more than
just a ``proposal for discussion''
Ichthyostega:: '2025-09-20'
//endof_comments:

131
doc/devel/rfc/DevelopmentFramework.txt
View file

@ -1,12 +1,12 @@
Design Process : Development Framework
======================================
[grid="all"]
`------------`-----------------------
*State* _Final_
*Date* _2007-06-08_
*Proposed by* link:ct[]
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Final_
|*Date* | _2007-06-08_
|*Proposed by* | Cehteh
|====================================
@ -22,11 +22,11 @@ needed/required for working on lumiera.
Description
~~~~~~~~~~~
.Tools required:
* unix like shell environment with standard tools
* Unix like shell environment with standard tools
* we don't require a specific linux distribution
* git 1.5.3 (not out yet, but really soon, we want submodules support)
* GNU toolchain, autoconf/automake (maybe scons or something else?)
* bouml (version case unresolved)
* Git 1.5.3 (not out yet, but really soon, we want submodules support)
* GNU toolchain, autoconf/automake (maybe SCons or something else?)
* Bouml (version case unresolved)
.Tools suggested:
* doxygen
@ -36,45 +36,44 @@ Description
Tasks
^^^^^
* cehteh will setup a initial repository (see link:RepositorySetup[proposed
structure])
* ichthyo has setup a debian-APT-depot at http://deb/ichthyostega.de[] and will
* _Cehteh_ will setup a initial repository
(see -> link:{rfc}/RepositorySetup.html[RfC: proposed repository structure])
* ichthyo has setup a debian-APT-depot at 'deb/ichthyostega.de' and will
add backport packages there if necessary so the debian-people can stay near
Etch/stable in the next time
* ichthyo volunteers to get the new source into a debian package structure from
* _Ichthyo_ volunteers to get the new source into a debian package structure from
start (same as the current cinelerra is)
.And for later:
* decide on a Unit Test framework (see link:UnitTests_Python[this Proposal])
* decide on a Unit Test framework
(see -> link:rfc/UnitTestsPython.html[RfC Unit-Tests])
* can we get some continuous integration running somewhere (nightly builds,
testsuite)?
* find a viable toolchain for writing more formal documentation.
link:ReStructured[] Text, Docbook etc?
ReStructured Text, Docbook etc?
Pros
^^^^
Cons
^^^^
* the GIT submodules are just not there atm. we need to come along with one
* Git submodules are just not usable yet; we need to come along with one
monolitic large project until they are available.
Alternatives
^^^^^^^^^^^^
* use visual studio and .NET :P
* use visual studio and .NET [big]#😇#
Rationale
~~~~~~~~~
The project will be tied to a distributed infrastructure/git. With recent git
submodules support it should be easy to let contributors only checkpout/work on
The project will be tied to a distributed infrastructure based on Git. With recent
Git submodules support it should be easy to let contributors only checkpout/work on
parts of the tree (plugins, documentation, i18n, ...). We want to build up a
set of maintenance scripts in a ./admin dir.
set of maintenance scripts in an `./admin` directory.
At the moment we go for rather bleeding edge tools, because we want to stay at
a given version to avoid incompatibility problems. Later on a version switch
@ -91,12 +90,13 @@ scripting up and running very early in a project. I would like if the project
would take a rather conservative approach on the required Libs and Tools, so
that finally, when we get into a beta state, we can run/compile on the major
distros without too much pain. I wouldn't completely abandon the idea to target
\*bsd and osx as well later on.
*bsd and osX as well later on.
I would propose to move Doxygen to "required". The Idea to use scons sounds
quite appealing to me at the moment. Besides that, I think it could be moved to
"Draft".
-- link:Ichthyostega[] [[DateTime(2007-06-17T00:18:40Z)]]
I would propose to move Doxygen to ``required''. The Idea to use SCons sounds
quite appealing to me at the moment. Besides that, I think this RfC could be
moved to ``Draft''.
Ichthyostega:: '2007-06-17T00:18:40Z'
Moved to Draft. For Developer documentation I would prefer doxygen. For user
documentation we can make a similar/same think like nicolasm did for
@ -106,26 +106,83 @@ current cin2 docs, i say its rather well done.
We need to factor out some of the proposals from this page to subpages (scons,
documentation, testing,...)
-- link:ct[] [[DateTime(2007-06-17T17:27:59Z)]]
It would really suck if we have to go through the experiences described
http://freshmeat.net/articles/view/889/[here]. I have experienced parts of that
ct:: '2007-06-17T17:27:59Z'
It would really suck if we have to go through the experiences described in the article
https://web.archive.org/web/20060427005516/http://freshmeat.net/articles/view/889/[»Stop the autoconf insanity!«].
I have experienced parts of that
in the past. I have only some beginner experience with writing autotoolized
projects (mostly based on trial-and-error) and no experience in any other build
system (such as scons). As such, I still believe that autotools can be
manageable (for me personally) once the initial hurdle of learning is overcome.
I all for Doxygen documentation. Related to documentation are
http://www.splint.org/[splint]
http://www.splint.org/manual/html/appC.html[annotations] (comments). I suggest
that we consider using such a tool for QA. Like link:ct[] said, this should be
http://splint.org/[Splint: Annotation-Assisted Lightweight Static Checking].
See also http://splint.org/manual/html/appC.html[descriptions of annotations (in comments)].
I suggest
that we consider using such a tool for QA. Like ct said, this should be
discussed in a subpage.
I agree with using currently bleeding-edge tools.
* _historic remark(Ichthyo):_ who wrote that comment? (neither me nor ct)
We have now a \'compatibility wiki\', finalized this proposal
-- link:ct[] [[DateTime(2008-03-26T13:43:26Z)]]
We have now a ``compatibility wiki'', finalized this proposal
ct:: '2008-03-26T13:43:26Z'
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
....
​
​
​
....
Assessment 2025
~~~~~~~~~~~~~~~
[underline]#In hindsight,# this RfC captures the baseline of our project setup. +
We soon settled upon the following toolchain, which is used up to today:
- One published Git repository per developer, with direct pull / merging; +
history is consolidated eventually into the
link:{rfc}/MasterRepositorySetup.html#historical_remark[»official Lumiera repository«],
which is made accessible at
https://git.lumiera.org/?p=LUMIERA;a=summary[`git://git.lumiera.org/LUMIERA`]
- We never used link:{rfc}/GitSubmoduleTransistion.html#_comments[Git submodules]...
- https://www.scons.org/[SCons] became the primary buildsystem soon,
with Autotools discontinued in 2011
- https://trac.edgewall.org/[Trac] is used as planning- and ticket system.
- API documentation is extracted with https://www.doxygen.nl/[Doxygen]
- Website and documentation pages are generated by
https://asciidoc-py.github.io/[Asciidoc], with source files for
documentation maintained
https://git.lumiera.org/?p=LUMIERA;a=blob;f=doc/index.txt;h=9bc0f11e6fb67588388e7616320b695841571278;hb=20f3252892d5b53a05ecd8aeb571122806baba17[in-tree],
published
https://git.lumiera.org/?p=website;a=blob;f=build_website.sh;h=60b90e18d5732d66566baf2c20a217212a5dcece;hb=aefc91e13a95a3c742dc8143c374ec982e0aa56b[automatically on push].
- A https://classic.tiddlywiki.com/[TiddlyWiki] is used for development notes
- for Unit-Tests, we use our own minimalist
https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/lib/test/run.hpp;h=035633af9bde7a8053bcd304baffc21693dcf031;hb=20f3252892d5b53a05ecd8aeb571122806baba17[Test-runner].
and a
https://git.lumiera.org/?p=LUMIERA;a=blob;f=tests/test.sh;h=8c13810eb475bbacd97c528607e6750f47bb145e;hb=20f3252892d5b53a05ecd8aeb571122806baba17[shell script]
to support definition of test collections.
- A Debian package is maintained with
https://wiki.debian.org/PackagingWithGit[git-buildpackage] and published
in our own DEB depot generated by the
https://wiki.debian.org/DebianRepository/SetupWithReprepro[reprepro tooling].
- UML plays only a marginal role today -- yet in fact we generated our initial class
hierarchy with https://web.archive.org/web/20070625100128/http://bouml.free.fr/[Bouml],
as proposed by _Cehteh_. Sometimes, UML design sketches are made with
https://uml.sourceforge.io/[Umbrello], while schematic drawings,
Icons and graphic elements for the GUI are maintained
with https://inkscape.org/[Inkscape]
- Test-visualisation relies heavily on
https://graphviz.org/[Graphviz] and
http://www.gnuplot.info/[Gnuplot]
Ichthyostega:: '2025-09-20'
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

87
doc/devel/rfc/DistributedDevelopmentFramework.txt
View file

@ -1,12 +1,12 @@
Design Process : Distributed Development Framework
==================================================
[grid="all"]
`------------`-----------------------
*State* _Final_
*Date* _2007-06-07_
*Proposed by* link:ct[]
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Dropped_
|*Date* | _2007-06-07_
|*Proposed by* | ct
|====================================
Distributed Development Framework
@ -29,20 +29,6 @@ Tasks
* Serveral (shell?) scripts which ease the use
Pros
~~~~
Cons
~~~~
Alternatives
~~~~~~~~~~~~
Rationale
~~~~~~~~~
@ -57,9 +43,64 @@ Rationale
Comments
--------
Made this 'final', this proposal got accepted and is already in use without
Made this `final', this proposal got accepted and is already in use without
much discussion
-- link:ct[] [[DateTime(2007-06-27T16:07:13Z)]]
ct:: '2007-06-27T16:07:13Z'
....
​
​
​
....
[large]#🌑 ​ 🌒 ​ 🌓 ​ 🌔 ​ 🌕 ​ 🌖 ​ 🌗 ​ 🌘 ​ 🌑#
[underline]#Historical remark#: This was ultimately the first
_conceptual_ (not process-related) RfC published in this Design-Process
(note the date!). Thus, _in hindsight,_
the question arises what this RfC was meant to propose; +
During the following months, an ambitious side-project named »**uWiki**« was started,
with the goal to provide a wiki-like web frontend based on completely self-contained
storage in a Git repository, without requiring any kind of data base. This project,
however -- in spite of some compelling prototype implementations -- was abandoned;
it became clear that such a system can not be bootstrapped from a lightweight,
minimalist setup and would require a significant amount of web development
rather -- a task no one was willing to take on.
Yet the Lumiera project succeeded in building a web presence based on
https://asciidoc-py.github.io/[Asciidoc] sources
https://git.lumiera.org/?p=website;a=summary[checked into Git],
with a lightweight
https://git.lumiera.org/?p=website;a=blob;f=build_website.sh;h=60b90e18d5732d66566baf2c20a217212a5dcece;hb=aefc91e13a95a3c742dc8143c374ec982e0aa56b[commit-hook script]
to automatically publish any changes on git-push -- a scheme
which comes close to the gist of this RfC.
Ichthyostega:: '2025-09-08'
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
.State -> Dropped
After reconsidering this RfC, _many years later,_ it seems prudent to mark it as __`Dropped'.__
The reasons for this decision are manifold. For one, the project never fully embraced this
working style, it was a vision from the early days rather. _Parts_ of that vision became a
practical reality, like the use of a link:{rfc}/MasterRepositorySetup.html[shared master repository],
or the use of Git and Asciidoc to generate and publish our website directly from a hook-script.
But we did not ``create our own toolset to track issues, tasks, bugs in a distributed manner''.
This idea might seem enticing for a new experimental project, and, when taken further, it leads to
a development style where most questions of coordination, and notably the preparation of releases
and the delivery and roll-out of published code are handled by an automated production line.
Developers can do what they like most: ``code cool things'' -- while all that
``nasty other stuff'' is dealt with by an »Invisible Hand«.
I do not consider such a setup healthy on the long run, nor can I see how it would be
adequate for a project with liabilities to care for: we should not consider the coordination
of a release cycle as something extraneous, to be ``automated away'' -- it requires the
full attention of the developers rather, to provide a longtime stable version and not to
interfere with the work of creative people, using the software in novel ways,
not foreseeable by the developers.
For this reason, I moved into the opposite direction and have now switched to the
link:/project/background/GitFlow.html[Git-flow branching model].
Ichthyostega:: '2025-09-20'
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

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

@ -1,18 +1,18 @@
EDL's Are Meta-Clips
====================
[grid="all"]
`------------`-----------------------
*State* _Final_
*Date* _2008-07-15_
*Proposed by* link:PercivalTiglao[]
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Final_
|*Date* | _2008-07-15_
|*Proposed by* | PercivalTiglao
|====================================
EDLs Are Meta-Clips
-------------------
One very useful property of EDLs is the ability to contain other EDLs and treat
these "inner" EDLs as a unit. The most logical implementation of this is to
have EDLs themselves be able to be treated as an Clip-MObject. Recursion is
One very useful property of EDLs is the ability to contain other EDLs and to
__treat these ``inner'' EDLs as an unit__. The most logical implementation of this
is to have EDLs themselves be able to be treated as an Clip-MObject. Recursion is
known to be a powerful feature that is relatively simple to understand. By
making EDLs recursive, some higher level features can be more easily
implemented by taking advantage of this fact.
@ -39,14 +39,13 @@ being forced to render the file to disk first.
The usability benefits are obvious.
In all examples, rendering the main EDL implies that all of the "inner EDLs"
In all examples, rendering the main EDL implies that all of the ``inner EDLs''
have to be re-rendered if the inner EDL was modified. That is one of the only
requirements.
Tasks
~~~~~
^^^^^
* Consider usability issues from the current Cinelerra userbase.
* Have the EDL Object (or create a proxy class) that extends MObject, Clip,
AbstractMO, or some other class that would create this kind of behaviour.
@ -54,21 +53,19 @@ Tasks
File2 contains File1. This might produce infinite recursion while attempting
to render the EDL.
* Implement higher level features in the GUI.
* Create "Compound Tracks" which contain multiple tracks within them.
* Create ``Compound Tracks'' which contain multiple tracks within them.
* Create a GUI that can handle multiple open EDLs at the same time.
Pros
~~~~
* A low level feature that would greatly ease the creation of high level
features.
^^^^
* A low level feature that would greatly ease the creation of high level features.
* Multiple applications.
* Eases the use and maintenance of Stock Footage.
Cons
~~~~
^^^^
* Possibly would have to rewrite a lot of code at the Engine level??
* Caching / Efficiency issues arise.
- Handling multiple instances of Lumiera running might be difficult. E.g.
@ -77,53 +74,57 @@ Cons
- Or maybe even multiple instances of Lumiera across computers that are
connected to the same Drive. File1 is opened in Computer1 and File2 is
opened in Computer2.
* A corrupted "inner EDL" or Stock Footage would "poison" the whole project.
* A corrupted ``inner EDL'' or Stock Footage would ``poison'' the whole project.
Alternatives
~~~~~~~~~~~~
* Pre-Rendering Clips
- Unlike the current proposal, you would be unable to reedit sock footage on
the mass scale and reapply it to the whole project.
- Unlike the current proposal, you would be unable to re-edit sock footage on
the mass scale and re-apply it to the whole project.
- Moreover, rendering either introduces a generation loss or requires huge
storage for raw (uncompressed) video.
* Loading the resources of the EDL -- This is an alternative way to load EDLs.
This should also be supported. It would be an expected feature from the old
Cinelerra2 userbase.
Cinelerra-2 user base.
Comments
--------
* I got the inspiration of this idea from an email discussion between Rick777
discussing the Saya Video Editor. -- link:PercivalTiglao[]
[[DateTime(2008-07-17T13:34:08Z)]]
* Hi Percival, thanks for writing this proposal. This is indeed a feature which
was much discussed in the last months and I consider it to be included almost
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
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)
different behaviour if a clip pulls from a media file, from an life input or
from another EDL. Thus, the implementation would be for a meta-clip to use a
special media asset, which represents the output of the other EDL.
* Basically, the implementation is quite simple and doesn't necessiate much
additional code (the power of recursion at work!). Further, I don't see any
caching or efficiency problems. As you already pointed out, there are two
fundamental problems
- We need a cycle detector when building the low-level model. ''But'' we
I got the inspiration of this idea from an email discussion with _Rick777_
discussing the Saya Video Editor.
PercivalTiglao:: '2008-07-17T13:34:08Z'
Hi Percival, thanks for writing this proposal. This is indeed a feature which
was much discussed in the last months and I consider it to be included almost
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
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)
different behaviour if a clip pulls from a media file, from an life input or
from another EDL. Thus, the implementation would be for a meta-clip to use a
special media asset, which represents the output of the other EDL.
Basically, the implementation is quite simple and doesn't necessitate much
additional code (the power of recursion at work!). Further, I don't see any
caching or efficiency problems. As you already pointed out, there are two
fundamental problems
- We need a cycle detector when building the low-level model. _But_ we
don't need it solely because of meta-clips, we also need such a facility
the moment we allow relatively free wiring of input-output connections
(which we do plan anyway). My proposal is to flag the respective MObjects
as erroneous, which should be visualized accordingly in the GUI
- We need a thouroughly complete handling for multichannel video and audio
- We need a thoroughly complete handling for multichannel video and audio
throughout the whole application. We need to get rid of the distinction
into "video" and "audio" tracks. ''But'' again, this is not due to
into »video« and »audio« tracks. _But_ again, this is not due to
meta-clips solely, we should do so anyway because of multichannel spatial
audio, 3D video and other advanced media to come. Thus, when every media is
multichannel by default, and the builder can sort and handle connections
@ -131,11 +132,13 @@ Comments
to do right from start), putting a meta-clip which pulls output from N
channels with various mixed stream types from another EDL is not really a
problem.
* The other "cons" listed above actually aren't directly connected or due to
the existence of meta-clips, thus I wouldn't list them here.
- yes, it ''is'' true, concurrent changes to the session files may screw up
things. But is this really an issue the Lumiera App should handle at all??
- yes, ''any corrupted part'' of the serialized session can mess up things.
The other »cons« listed above actually aren't directly connected or due to
the existence of meta-clips, thus I wouldn't list them here.
- yes, it _is_ true, concurrent changes to the session files may screw up things.
But is this really an issue the Lumiera App should handle at all?
- yes, _any corrupted part_ of the serialized session can mess up things.
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
@ -143,24 +146,53 @@ Comments
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.
-- link:Ichthyostega[] [[DateTime(2008-07-27T22:15:01Z)]]
* I'll think about closures around seralized artefacts, the serialized stream
can then be validated, unsupported or corrupted parts can be tagged as
erroneous (means they become virtually readonly but they must be preserved)
and circumvented. A lot of details have to be worked out here, iirc ichthyo
already planned support for 'erroneous' nodes in the datamodell. I also think
about some debugable plaintext dump format (maybe XML) then real corrupt
things can be fixed manually with some efforts. Otherwise we handle gigabytes
of video data and our most valuable resource is the few MB sized session
file. I really aim to make that as robust as possible. Adding backups and
redundancy there wont hurt.
-- link:ct[] [[DateTime(2008-07-30T16:03:04Z)]]
Ichthyostega:: '2008-07-27T22:15:01Z'
I'll think about closures around seralized artifacts, the serialized stream
can then be validated, unsupported or corrupted parts can be tagged as
erroneous (means they become virtually readonly but they must be preserved)
and circumvented. A lot of details have to be worked out here, iirc ichthyo
already planned support for `erroneous' nodes in the data model. I also think
about some debuggable plaintext dump format (maybe XML) then real corrupt
things can be fixed manually with some efforts. Otherwise we handle gigabytes
of video data and our most valuable resource is the few MB sized session
file. I really aim to make that as robust as possible. Adding backups and
redundancy there wont hurt.
ct:: '2008-07-30T16:03:04Z'
Conclusion
----------
This Design Entry concerns whether to include such a feature and discusses the
general questions when doing so. As we for sure include meta-clip, and so so
exactly in the way described here, this proposal is 'final' now.
This Design Entry deals with the question whether to include such a feature and
it discusses the general questions when doing so. Since we are determined to
include this kind of _meta-clip_ anyway, and will most likely do in a way
similar as described here, this can be considered __`final'__.
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
This conclusion was drawn at the
link:{ldoc}/devel/meeting_summary/2008-10-10.html#_edls_as_meta_clips[October.2008 developer meeting].
''''
[TIP]
===========
Terminology is somewhat in flux regarding this topic:
- »EDL« is a technical term from the Cinelerra-2 code base. The acronym actually
stands for **E**dit **D**ecision **L**ist, which is a term from traditional
film making and production organisation -- and does not really map properly
into the usage possible with digital technology. For that reason, the Lumiera
project _dropped_ this notion subsequently.
- close to the ideas presented in this text is the concept of a ``Sequence'',
which in Lumiera designates a ``Fork'' (tree of tracks) with an arrangement
of clips attached.
- as of 2025, we typically use the following terminology:
** a _Virtual Clip_ is how such a nested structure is integrated
** such a clip in turn uses a _Virtual Medium_
** which is based on the _Binding_ of a _Nested Sequence_
===========
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

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

@ -4,12 +4,12 @@ Engine Interface Overview
// please don't remove the //word: comments
[grid="all"]
`------------`-----------------------
*State* _Draft_
*Date* _2010-04-16_
*Proposed by* link:Ichthyostega[]
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Draft_
|*Date* | _2010-04-16_
|*Proposed by* | Ichthyostega
|====================================
Overview Engine Interface(s)
@ -42,7 +42,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 Stage and Steam-Layer in need to
connect to such a "rendering", and it holds the specific definitions for this
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
controller of some timeline in the model is
@ -51,7 +51,7 @@ processes exist.
* there is an displayer- or output slot, which got allocated on creation
of the process
* the process disposes calculated data frames "into" this slot
* the process disposes calculated data frames _into this slot_
* the process can be paused/started and stopped (aborted, halted).
* some processes allow for changing parameters dynamically (e.g. speed,
direction)
@ -60,7 +60,7 @@ processes exist.
.Process parameters
A process is linked to a single stream data format (a ->
link:StreamTypeSystem.html[stream implementation type]). +
link:{rfc}/StreamTypeSystem.html[stream implementation type]). +
It is configured with _frame quantisation_ and _timings_, and a _model port_
identifier and _channel selector_.
@ -246,7 +246,7 @@ Rationale
//Conclusion
//----------
//conclusion: When approbate (this proposal becomes a Final)
//conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process:
@ -261,11 +261,33 @@ Requirements and details of the design are sufficiently clear meanwhile.
Ther seems to be not much room for alternative approaches, given our
general planning for the application
Mi 11 Mai 2011 19:27:12 CEST Ichthyostega <prg@ichthyostega.de>
Ichthyostega:: 'Wed 11 Mai 2011 19:27:12 CEST' ~<prg@ichthyostega.de>~
//endof_comments:
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
[underline]#Historical remark#: In hindsight, it seems I did post that RfC
(and the corresponding link:{rfc}/EngineInterfaceSpec.html[Specification RfC]) not so much
to ask for input and further ideas, rather as a _call for help_. Last year (2024), I had
to revisit the code written in 2010/11, and it looks like I was struggling desperately at
that time to thread a pathway into a void. During the early stages of the project, _Cehteh_
and myself had agreed to place the boundary between ``Proc'' and ``Backend'' (today designated
as Steam and Vault) at the entrance to the link:/x/Scheduler.html[Scheduler] -- but there was
no scheduler yet, not even a design draft at that time, and the scope of what it was assumed to do
seemed to be ``vanishing'': basically ``the Backend'' wanted a pool of lightweight, stateless,
unconnected requests, which could be treated as a problem of the ``embarrassingly parallel''
kind (to use computer science parlance). So nothing to serve as an anchor or point of reference
for finding a pathway.
This RfC is a summary of design work already completed, asking for validation. I could
not see if this path would lead to anywhere at that time -- and subsequently abandoned that
topic in half-finished state. Currently (since 2024) I am picking up that work and it seems
to be durable. However -- it might be worth mentioning that this RfC indeed spurred an
link:{ldoc}/devel/meeting_summary/2011-05-11.html#scheduler[extended technical discussion]
at the May-2011 developer meeting, maybe the last of this kind of inspiring exchanges
on equal terms.
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

33
doc/devel/rfc/EngineInterfaceSpec.txt
View file

@ -3,12 +3,12 @@ Engine Interface Spec
// please don't remove the //word: comments
[grid="all"]
`------------`-----------------------
*State* _Idea_
*Date* _Mi 11 Mai 2011 17:53:16 CEST_
*Proposed by* Ichthyostega <prg@ichthyostega.de>
-------------------------------------
[options="autowidth"]
|====================================
|*State* | _Idea_
|*Date* | _Mi 11 Mai 2011 17:53:16 CEST_
|*Proposed by* | Ichthyostega <prg@ichthyostega.de>
|====================================
[abstract]
********************************************************************************
@ -54,7 +54,7 @@ Requirements Specification
Functionality description in detail
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-> see the link:EngineInterfaceOverview.html[Engine/Interface overview] for
-> see the link:{rfc}/EngineInterfaceOverview.html[Engine/Interface overview] for
a description of the involved entities and for definitions for common terms.
Definitions
@ -173,8 +173,8 @@ Tasks
Discussion
~~~~~~~~~~
Pros
^^^^
//Pros
//^^^^
// add a fact list/enumeration which make this suitable:
// * foo
// * bar ...
@ -188,8 +188,8 @@ The requirements placed on life changes are quite high
Alternatives
^^^^^^^^^^^^
//Alternatives
//^^^^^^^^^^^^
//alternatives: explain alternatives and tell why they are not viable:
@ -206,7 +206,7 @@ and break it down into tangible functionality on the implementation level.
//Conclusion
//----------
//conclusion: When approbate (this proposal becomes a Final)
//conclusion: When approved (this proposal becomes a Final)
// write some conclusions about its process:
@ -216,7 +216,9 @@ Comments
--------
//comments: append below
Discussed in the May developers meeting. Seems to be basically acceptable.
Discussed in the
link:{ldoc}/devel/meeting_summary/2011-05-11.html#irctranscript[May.2011 developers meeting].
Seems to be basically acceptable.
_Cehteh_ proposed some small adjustments:
- making the _QualityOfService_ rather a strategy to be queried
@ -225,10 +227,11 @@ _Cehteh_ proposed some small adjustments:
- introducing a separate scheduler/queue for time scheduled tasks, like
with rater soft realtime requirements
So 15 Mai 2011 00:55:24 CEST Ichthyostega <prg@ichthyostega.de>
Ichthyostega:: 'Sun 15 Mai 2011 00:55:24 CEST' ~<prg@ichthyostega.de>~
TIP: see also the related link:{rfc}/EngineInterfaceOverview.html#_comments[overview RfC]
//endof_comments:
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]

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