benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

clean-up: trifles

Browse source
This commit is contained in:
Fischlurch 2025-06-07 23:59:57 +02:00
parent 20392eee1c
commit d888891d84
481 changed files with 1987 additions and 1992 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
admin/rfc.sh
View file

@ -6,7 +6,7 @@ shopt -s extglob
# RFC's are created from ./doc/devel/template/new_rfc.sh and stored in # RFC's are created from ./doc/devel/template/new_rfc.sh and stored in
# ./doc/devel/rfc/ . There are directories for the various states # ./doc/devel/rfc/ . There are directories for the various states
# ./doc/devel/rfc_final, ./doc/devel/rfc_pending, ./doc/devel/rfc_parked, # ./doc/devel/rfc_final, ./doc/devel/rfc_pending, ./doc/devel/rfc_parked,
# ./doc/devel/rfc_dropped . Which contain symlinks back to ../rfc/ # ./doc/devel/rfc_dropped . Which contain symlinks back to ../rfc/
# #

4
admin/scons/BuilderGCH.py
View file

@ -14,9 +14,9 @@
##################################################################### #####################################################################
# history: 8/2008 adapted for Lumiera build system # history: 8/2008 adapted for Lumiera build system
# changed to accept a list of precompiled header defs # changed to accept a list of precompiled header defs
# TODO: WIP-remove these comments when port to Python 3.x is DONE # TODO: WIP-remove these comments when port to Python 3.x is DONE
# types.py does not contain ListType in Python 3.x # types.py does not contain ListType in Python 3.x
# # Why do we require ListType? # # Why do we require ListType?
# To do something like # To do something like

12
admin/scons/Buildhelper.py
View file

@ -30,8 +30,8 @@ def isCleanupOperation(env):
def isHelpRequest(): def isHelpRequest():
""" this is a hack: SCons does all configure tests even if only """ this is a hack: SCons does all configure tests even if only
the help message is requested. SCons doesn't export the the help message is requested. SCons doesn't export the
help option for retrieval by env.GetOption(), help option for retrieval by env.GetOption(),
so we scan the commandline directly. so we scan the commandline directly.
""" """
return '-h' in sys.argv or '--help' in sys.argv return '-h' in sys.argv or '--help' in sys.argv
@ -48,8 +48,8 @@ def srcSubtree(tree, **args):
SRCPATTERNS = ['*.c','*.cpp','*.cc'] SRCPATTERNS = ['*.c','*.cpp','*.cc']
def scanSubtree(roots, patterns=SRCPATTERNS): def scanSubtree(roots, patterns=SRCPATTERNS):
""" first expand (possible) wildcards and filter out non-dirs. """ first expand (possible) wildcards and filter out non-dirs.
Then scan the given subtree for source filenames Then scan the given subtree for source filenames
(python generator function) (python generator function)
""" """
for root in globRootdirs(roots): for root in globRootdirs(roots):
@ -92,7 +92,7 @@ def findSrcTrees(location, patterns=SRCPATTERNS):
def isSrcDir(path, patterns=SRCPATTERNS): def isSrcDir(path, patterns=SRCPATTERNS):
""" helper: investigate the given (relative) path """ helper: investigate the given (relative) path
@param patterns: list of wildcards to define what counts as "source file" @param patterns: list of wildcards to define what counts as "source file"
@return: True if it's a directory containing any source file @return: True if it's a directory containing any source file
""" """
if not os.path.isdir(path): if not os.path.isdir(path):
@ -144,7 +144,7 @@ def createPlugins(env, directory, **kw):
""" investigate the given source directory to identify all contained source trees. """ investigate the given source directory to identify all contained source trees.
@return: a list of build nodes defining a plugin for each of these source trees. @return: a list of build nodes defining a plugin for each of these source trees.
""" """
return [env.LumieraPlugin( getDirname(tree) return [env.LumieraPlugin( getDirname(tree)
, srcSubtree(tree) , srcSubtree(tree)
, **kw , **kw
) )

24
admin/scons/IconSvgRenderer.py
View file

@ -27,10 +27,10 @@ artworkLayerPrefix = "artwork:"
# The purpose of this python script is # The purpose of this python script is
# - to parse a SVG # - to parse a SVG
# - to invoke Inkscape to render this SVG into a raster image (icon) # - to invoke Inkscape to render this SVG into a raster image (icon)
# #
# For the actual Cairo based SVG rendering we rely on an executable 'rsvg-convert', # For the actual Cairo based SVG rendering we rely on an executable 'rsvg-convert',
# which is built during the Lumiera build process. # which is built during the Lumiera build process.
# #
# Judging from the code and the actual SVGs, this seems to work as follows: # Judging from the code and the actual SVGs, this seems to work as follows:
# The SVG contains a design to be rendered into raster images of various sizes. # The SVG contains a design to be rendered into raster images of various sizes.
# These sizes are determined by special rectangles, which act as bounding box and # These sizes are determined by special rectangles, which act as bounding box and
@ -39,7 +39,7 @@ artworkLayerPrefix = "artwork:"
# suitable for icon generation. The actual size of the generated icons are then # suitable for icon generation. The actual size of the generated icons are then
# parsed from the height and width attributes of the mentioned bounding box # parsed from the height and width attributes of the mentioned bounding box
# rectangles. # rectangles.
# #
# The parser seems to be rather simplistic; the sizes and positions need to be # The parser seems to be rather simplistic; the sizes and positions need to be
# integral numbers. In one instance we had a float number in the y coordinate, # integral numbers. In one instance we had a float number in the y coordinate,
# which resulted in an invalid, zero sized output icon # which resulted in an invalid, zero sized output icon
@ -61,7 +61,7 @@ def copyMergeDirectory (src, dst):
listing = os.listdir (src) listing = os.listdir (src)
for file_name in listing: for file_name in listing:
src_file_path = os.path.join (src, file_name) src_file_path = os.path.join (src, file_name)
dst_file_path = os.path.join (dst, file_name) dst_file_path = os.path.join (dst, file_name)
shutil.copyfile (src_file_path, dst_file_path) shutil.copyfile (src_file_path, dst_file_path)
def getDocumentSize (svg_element): def getDocumentSize (svg_element):
@ -112,10 +112,10 @@ def renderSvgRsvg (file_path, out_dir, artwork_name, rectangle, _doc_size):
# Prepare a Cairo context # Prepare a Cairo context
width = int(rectangle[2]) width = int(rectangle[2])
height = int(rectangle[3]) height = int(rectangle[3])
if not os.path.exists(rsvgPath): if not os.path.exists(rsvgPath):
print("Error: executable %s not found." % rsvgPath) print("Error: executable %s not found." % rsvgPath)
os.spawnlp(os.P_WAIT, rsvgPath, rsvgPath, os.spawnlp(os.P_WAIT, rsvgPath, rsvgPath,
"--source-rect=%g:%g:%g:%g" % (rectangle[0], rectangle[1], width, height), "--source-rect=%g:%g:%g:%g" % (rectangle[0], rectangle[1], width, height),
"--output=" + os.path.join(out_dir, "%gx%g/%s.png" % (width, height, artwork_name)), "--output=" + os.path.join(out_dir, "%gx%g/%s.png" % (width, height, artwork_name)),
@ -140,35 +140,35 @@ def printHelp():
def parseArguments(argv): def parseArguments(argv):
_optlist, args = getopt.getopt(argv, "") _optlist, args = getopt.getopt(argv, "")
if len(args) == 2: if len(args) == 2:
return args[0], args[1] return args[0], args[1]
printHelp() printHelp()
return None, None return None, None
def main (argv): def main (argv):
in_path, out_dir = parseArguments(argv) in_path, out_dir = parseArguments(argv)
if not (in_path and out_dir): if not (in_path and out_dir):
print("Missing arguments in_path and out_dir.") print("Missing arguments in_path and out_dir.")
sys.exit(1) sys.exit(1)
if os.path.isfile(out_dir): if os.path.isfile(out_dir):
print("Unable to use '%s' as output directory, because it\'s a file." % out_dir) print("Unable to use '%s' as output directory, because it\'s a file." % out_dir)
sys.exit(1) sys.exit(1)
if not os.path.isdir(out_dir): if not os.path.isdir(out_dir):
print("Output directory '%s' not found." % out_dir) print("Output directory '%s' not found." % out_dir)
sys.exit(1) sys.exit(1)
# Create the icons folders # Create the icons folders
createDirectory(os.path.join(out_dir, "48x48")) createDirectory(os.path.join(out_dir, "48x48"))
createDirectory(os.path.join(out_dir, "32x32")) createDirectory(os.path.join(out_dir, "32x32"))
createDirectory(os.path.join(out_dir, "24x24")) createDirectory(os.path.join(out_dir, "24x24"))
createDirectory(os.path.join(out_dir, "22x22")) createDirectory(os.path.join(out_dir, "22x22"))
createDirectory(os.path.join(out_dir, "16x16")) createDirectory(os.path.join(out_dir, "16x16"))
renderSvgIcon (in_path, out_dir) renderSvgIcon (in_path, out_dir)

22
admin/scons/LumieraEnvironment.py
View file

@ -26,7 +26,7 @@ from Buildhelper import *
class LumieraEnvironment(Environment): class LumieraEnvironment(Environment):
""" Custom SCons build environment for Lumiera """ Custom SCons build environment for Lumiera
This allows us to carry structured config data without This allows us to carry structured config data without
using global vars. Idea inspired by Ardour. using global vars. Idea inspired by Ardour.
""" """
def __init__(self, buildSetup, buildVars, **kw): def __init__(self, buildSetup, buildVars, **kw):
kw.update(VERSION = buildSetup.VERSION kw.update(VERSION = buildSetup.VERSION
@ -62,7 +62,7 @@ class LumieraEnvironment(Environment):
self.mergeConf(self.libInfo[other]) self.mergeConf(self.libInfo[other])
else: else:
self.Append (LIBS = other.get ('LIBS',[])) self.Append (LIBS = other.get ('LIBS',[]))
self.Append (LIBPATH = other.get ('LIBPATH', [])) self.Append (LIBPATH = other.get ('LIBPATH', []))
self.Append (CPPPATH = other.get('CPPPATH', [])) self.Append (CPPPATH = other.get('CPPPATH', []))
self.Append (LINKFLAGS = other.get('LINKFLAGS', [])) self.Append (LINKFLAGS = other.get('LINKFLAGS', []))
@ -72,7 +72,7 @@ class LumieraEnvironment(Environment):
def addLibInfo (self, libID, minVersion=0, alias=None): def addLibInfo (self, libID, minVersion=0, alias=None):
""" use pkg-config to create an Environment describing the lib. """ use pkg-config to create an Environment describing the lib.
Don't add this defs to the current Environment, rather store Don't add this defs to the current Environment, rather store
them in the libInfo Dictionary. them in the libInfo Dictionary.
""" """
minVersion = str(minVersion) minVersion = str(minVersion)
if 0 != os.system('pkg-config --print-errors --exists "%s >= %s"' % (libID,minVersion)): if 0 != os.system('pkg-config --print-errors --exists "%s >= %s"' % (libID,minVersion)):
@ -116,7 +116,7 @@ class LumieraConfigContext(ConfigBase):
def register_LumieraResourceBuilder(env): def register_LumieraResourceBuilder(env):
""" Registers Custom Builders for generating and installing Icons. """ Registers Custom Builders for generating and installing Icons.
Additionally you need to build the tool (rsvg-convert.c) Additionally you need to build the tool (rsvg-convert.c)
used to generate png from the svg source using librsvg. 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) import IconSvgRenderer as renderer # load Joel's python script for invoking the rsvg-convert (SVG render)
@ -142,7 +142,7 @@ def register_LumieraResourceBuilder(env):
icon = targetdir+icon icon = targetdir+icon
subdir = getDirname(str(icon)) subdir = getDirname(str(icon))
env.Install (installLocation+subdir, icon) env.Install (installLocation+subdir, icon)
generateTargets.append(icon) generateTargets.append(icon)
return (generateTargets, source) return (generateTargets, source)
@ -168,7 +168,7 @@ def register_LumieraResourceBuilder(env):
target dir is either the install location configured (in SConstruct), target dir is either the install location configured (in SConstruct),
or an explicitly given absolute or relative path segment, which might refer or an explicitly given absolute or relative path segment, which might refer
to the location of the executable through the $ORIGIN token to the location of the executable through the $ORIGIN token
""" """
source = path.join(prefix,str(source)) source = path.join(prefix,str(source))
subdir = getDirname(source, prefix) # removes source location path prefix subdir = getDirname(source, prefix) # removes source location path prefix
if targetDir: if targetDir:
@ -218,13 +218,13 @@ class WrappedStandardExeBuilder(SCons.Util.Proxy):
create a clone environment for specific configuration create a clone environment for specific configuration
and then pass on the call to the wrapped original builder. and then pass on the call to the wrapped original builder.
Automatically define installation targets for build results. Automatically define installation targets for build results.
@note only returning the build targets, not the install targets @note only returning the build targets, not the install targets
""" """
customisedEnv = self.getCustomEnvironment(env, target=target, **kw) # defined in subclasses customisedEnv = self.getCustomEnvironment(env, target=target, **kw) # defined in subclasses
buildTarget = self.buildLocation(customisedEnv, target) buildTarget = self.buildLocation(customisedEnv, target)
buildTarget = self.invokeOriginalBuilder(customisedEnv, buildTarget, source, **kw) buildTarget = self.invokeOriginalBuilder(customisedEnv, buildTarget, source, **kw)
self.installTarget(customisedEnv, buildTarget, **kw) self.installTarget(customisedEnv, buildTarget, **kw)
return buildTarget return buildTarget
def invokeOriginalBuilder(self, env, target, source, **kw): def invokeOriginalBuilder(self, env, target, source, **kw):
@ -269,7 +269,7 @@ class LumieraExeBuilder(WrappedStandardExeBuilder):
def getBuildDestination(self, lumiEnv): return lumiEnv.path.buildExe def getBuildDestination(self, lumiEnv): return lumiEnv.path.buildExe
def getInstallDestination(self, lumiEnv): return lumiEnv.path.installExe def getInstallDestination(self, lumiEnv): return lumiEnv.path.installExe
@ -279,7 +279,7 @@ class LumieraModuleBuilder(WrappedStandardExeBuilder):
""" augments the built-in SharedLibrary() builder to add some tweaks missing in SCons 1.0, """ augments the built-in SharedLibrary() builder to add some tweaks missing in SCons 1.0,
like setting a SONAME proper instead of just passing the relative pathname to the linker. like setting a SONAME proper instead of just passing the relative pathname to the linker.
Besides, we override the library search path to allow for transitive dependencies between Besides, we override the library search path to allow for transitive dependencies between
Lumiera modules; modules are assumed to reside in a subdirectory below the executable. Lumiera modules; modules are assumed to reside in a subdirectory below the executable.
""" """
custEnv = lumiEnv.Clone() custEnv = lumiEnv.Clone()
custEnv.Append(LINKFLAGS = "-Wl,-soname="+self.defineSoname(target,**kw)) custEnv.Append(LINKFLAGS = "-Wl,-soname="+self.defineSoname(target,**kw))

4
admin/scons/Options.py
View file

@ -22,7 +22,7 @@ from SCons.Script import PathVariable, EnumVariable, BoolVariable, Help
def defineCmdlineVariables(buildVars): def defineCmdlineVariables(buildVars):
""" several toggles and configuration variables can be set on the commandline, """ several toggles and configuration variables can be set on the commandline,
current settings will be persisted in a options cache file. current settings will be persisted in a options cache file.
you may define custom variable settings in a separate file. you may define custom variable settings in a separate file.
Commandline will override both. Commandline will override both.
""" """
buildVars.AddVariables( buildVars.AddVariables(
@ -39,7 +39,7 @@ def defineCmdlineVariables(buildVars):
,('TESTSUITES', 'Run only test suites matching the given pattern', '') ,('TESTSUITES', 'Run only test suites matching the given pattern', '')
,('TESTMODE', 'test suite error mode for test.sh', '') ,('TESTMODE', 'test suite error mode for test.sh', '')
# ,BoolVariable('OPENGL', 'Include support for OpenGL preview rendering', False) # ,BoolVariable('OPENGL', 'Include support for OpenGL preview rendering', False)
# ,EnumVariable('DIST_TARGET', 'Build target architecture', 'auto', # ,EnumVariable('DIST_TARGET', 'Build target architecture', 'auto',
# allowed_values=('auto', 'i386', 'i686', 'x86_64' ), ignorecase=2) # allowed_values=('auto', 'i386', 'i686', 'x86_64' ), ignorecase=2)
,PathVariable('PREFIX', 'Installation dir prefix', 'usr/local', PathVariable.PathAccept) ,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('INSTALLDIR', 'Root output directory for install. Final installation will happen in INSTALLDIR/PREFIX/... ', '/', PathVariable.PathIsDir)

8
admin/scons/Platform.py
View file

@ -94,7 +94,7 @@ def configure(env):
if not conf.CheckPkgConfig('gtkmm-3.0', '3.10'): if not conf.CheckPkgConfig('gtkmm-3.0', '3.10'):
problems.append('Unable to configure the mm-bindings for GTK-3') 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.39'):
problems.append('Unable to configure the mm-bindings for Glib') problems.append('Unable to configure the mm-bindings for Glib')
@ -119,17 +119,17 @@ def configure(env):
'and suitable C++ ("mm")-bindings (GDLmm >=%s)' % (verGDL, verGDLmm)) 'and suitable C++ ("mm")-bindings (GDLmm >=%s)' % (verGDL, verGDLmm))
if not conf.CheckPkgConfig('gdlmm-3.0', verGDLmm, alias='gdl'): if not conf.CheckPkgConfig('gdlmm-3.0', verGDLmm, alias='gdl'):
problems.append('We need the C++ bindings for GDL by Fabien Parent: GDLmm >=%s ' 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 GNOME %s or use the debian package from %s)' %
(verGDLmm, urlGDLmm, urlGDLmmDEB)) (verGDLmm, urlGDLmm, urlGDLmmDEB))
if not conf.CheckPkgConfig('librsvg-2.0', '2.30'): if not conf.CheckPkgConfig('librsvg-2.0', '2.30'):
problems.append('Need rsvg Library for rendering icons.') problems.append('Need rsvg Library for rendering icons.')
if not conf.CheckCHeader(['X11/Xutil.h', 'X11/Xlib.h'],'<>'): if not conf.CheckCHeader(['X11/Xutil.h', 'X11/Xlib.h'],'<>'):
problems.append('Xlib.h and Xutil.h required. Please install libx11-dev.') problems.append('Xlib.h and Xutil.h required. Please install libx11-dev.')
# NOTE the following dependencies where for the video displayer widget. # NOTE the following dependencies where for the video displayer widget.
# As of 11/2015 this is broken and disabled. Might be obsolete.... # As of 11/2015 this is broken and disabled. Might be obsolete....
if not conf.CheckPkgConfig('xv') : problems.append('Need libXv...') if not conf.CheckPkgConfig('xv') : problems.append('Need libXv...')
if not conf.CheckPkgConfig('x11') : problems.append('Need X-lib...') # for the xvdisplayer widget if not conf.CheckPkgConfig('x11') : problems.append('Need X-lib...') # for the xvdisplayer widget
if not conf.CheckPkgConfig('xext'): problems.append('Need libXext.') if not conf.CheckPkgConfig('xext'): problems.append('Need libXext.')

12
admin/scons/Setup.py
View file

@ -24,7 +24,7 @@ import Options
TARGDIR = 'target' TARGDIR = 'target'
VERSION = '0.pre.03' VERSION = '0.pre.03'
TOOLDIR = './admin/scons' # SCons plugins TOOLDIR = './admin/scons' # SCons plugins
OPTCACHE = 'optcache' OPTCACHE = 'optcache'
CUSTOPTFILE = 'custom-options' CUSTOPTFILE = 'custom-options'
# these are accessible via env.path.xxxx # these are accessible via env.path.xxxx
@ -66,10 +66,10 @@ def defineBuildEnvironment():
, CPPDEFINES=['LUMIERA_VERSION='+VERSION ] # note: it's a list to append further defines , CPPDEFINES=['LUMIERA_VERSION='+VERSION ] # note: it's a list to append further defines
, CCFLAGS='-Wall -Wextra -Wformat-security' , CCFLAGS='-Wall -Wextra -Wformat-security'
, CXXFLAGS='-std=gnu++17 -Wno-enum-compare' , CXXFLAGS='-std=gnu++17 -Wno-enum-compare'
, CFLAGS='-std=gnu99' , CFLAGS='-std=gnu99'
) )
env.Append(LINKFLAGS='-Wl,--no-undefined') # require every dependency is given on link, in the right order env.Append(LINKFLAGS='-Wl,--no-undefined') # require every dependency is given on link, in the right order
env.Append(LINKFLAGS='-Wl,--as-needed') # by default only link against dependencies actually needed to resolve symbols env.Append(LINKFLAGS='-Wl,--as-needed') # by default only link against dependencies actually needed to resolve symbols
handleVerboseMessages(env) handleVerboseMessages(env)
handleNoBugSwitches(env) handleNoBugSwitches(env)
@ -82,9 +82,9 @@ def defineBuildEnvironment():
# setup search path for Lumiera plugins # setup search path for Lumiera plugins
appendCppDefine(env,'PKGLIBDIR','LUMIERA_PLUGIN_PATH=\\"$PKGLIBDIR/:ORIGIN/modules\\"' appendCppDefine(env,'PKGLIBDIR','LUMIERA_PLUGIN_PATH=\\"$PKGLIBDIR/:ORIGIN/modules\\"'
,'LUMIERA_PLUGIN_PATH=\\"ORIGIN/modules\\"') ,'LUMIERA_PLUGIN_PATH=\\"ORIGIN/modules\\"')
appendCppDefine(env,'PKGDATADIR','LUMIERA_CONFIG_PATH=\\"$PKGLIBDIR/:.\\"' appendCppDefine(env,'PKGDATADIR','LUMIERA_CONFIG_PATH=\\"$PKGLIBDIR/:.\\"'
,'LUMIERA_CONFIG_PATH=\\"$DESTDIR/share/lumiera/:.\\"') ,'LUMIERA_CONFIG_PATH=\\"$DESTDIR/share/lumiera/:.\\"')
Options.prepareOptionsHelp(buildVars,env) Options.prepareOptionsHelp(buildVars,env)
buildVars.Save(OPTCACHE, env) buildVars.Save(OPTCACHE, env)
@ -104,7 +104,7 @@ def appendVal(env,var,targetVar,val=None):
def handleNoBugSwitches(env): def handleNoBugSwitches(env):
""" set the build level for NoBug. """ set the build level for NoBug.
Release builds imply no DEBUG Release builds imply no DEBUG
whereas ALPHA and BETA require DEBUG whereas ALPHA and BETA require DEBUG
""" """

2
data/config/dummy_lumiera.ini
View file

@ -1,4 +1,4 @@
# This is an dummy Lumiera config file # This is an dummy Lumiera config file
# #
# Actually Lumiera can't yet load any extended config, as of 1/2011 # Actually Lumiera can't yet load any extended config, as of 1/2011
# #

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

@ -71,7 +71,7 @@ Basically, we can expect to encounter the following kinds of fundamental data el
- `diff::Record<GenNode>` - `diff::Record<GenNode>`
The last option is what makes our representation recursive.footnote:[Regarding the implementation, The last option is what makes our representation recursive.footnote:[Regarding the implementation,
all these data elements are embedded _inline,_ as values. all these data elements are embedded _inline,_ as values.
With the exception of the record, which, like any `std::vector` implicitly uses heap allocations With the exception of the record, which, like any `std::vector` implicitly uses heap allocations
for the members of the collection.] for the members of the collection.]

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

@ -70,7 +70,7 @@ wall clock and system time::
of a _running synchronisation process,_ with the authority to adjust the time of a _running synchronisation process,_ with the authority to adjust the time
base; base;
+ +
contrast this to the internal time, which is static and unconnected -- contrast this to the internal time, which is static and unconnected --
quantised time:: quantised time::
The *act of quantisation* transforms a continuous property into a *discrete* The *act of quantisation* transforms a continuous property into a *discrete*

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

@ -23,7 +23,7 @@ discussions and brainstorming sessions.
contains some fundamental terms and definitions. contains some fundamental terms and definitions.
* discussions regarding time values and timecode handling shed some light on the requirements * discussions regarding time values and timecode handling shed some light on the requirements
to be fulfilled by a player subsystem 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/2116[Timecode Widget and Framerates]
- link:http://article.gmane.org/gmane.comp.video.lumiera.general/2109[Time, Time-spans, Quatisation and Timecode] - 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] - link:{l}/wiki/renderengine.html#TimeQuant[Definition of Time entities]
@ -33,7 +33,7 @@ discussions and brainstorming sessions.
Reasoning Behind the Player Subsystem's Structure Reasoning Behind the Player Subsystem's Structure
------------------------------------------------ ------------------------------------------------
The name ``Player'' might seem surprising at first. The name ``Player'' might seem surprising at first.
The full, complete and precise name would be something along The full, complete and precise name would be something along
the lines of ``_render- and playback-process coordination subsystem_''. the lines of ``_render- and playback-process coordination subsystem_''.
However we need to shorten that into a single word. The more obvious However we need to shorten that into a single word. The more obvious
@ -49,7 +49,7 @@ Influences and Requirements
In accordance with the spirit of modern software development, the analysis In accordance with the spirit of modern software development, the analysis
starts by determining the _Service_ that is provided by such a starts by determining the _Service_ that is provided by such a
player. Examination of the Use Cases determines the fundamental forces player. Examination of the Use Cases determines the fundamental forces
to be _multiplicity_, combined with _differentiation in detail_, all under to be _multiplicity_, combined with _differentiation in detail_, all under
the government of _time-bound delivery_, combined with _live reconfiguration_. the government of _time-bound delivery_, combined with _live reconfiguration_.
@ -90,8 +90,7 @@ reconfiguration driven by user interactions:
Conclusions for the Design Conclusions for the Design
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~
Based on these observations, the following design would appear to be pretty much Based on these observations, the following design would appear to be pretty much obvious:
obvious:
The overall player subsystem can be described as ``play/render-this''-service. The overall player subsystem can be described as ``play/render-this''-service.
Given a suitable (high-level) object, the player has the ability to ``perform'' Given a suitable (high-level) object, the player has the ability to ``perform''
@ -171,7 +170,7 @@ where to place quantisation: the Vault, the GUI, the player and the session.
we can ``do away'' with nasty things soon, especially if they are technicalities, we can ``do away'' with nasty things soon, especially if they are technicalities,
``get a clean state soon'' -- and hasn't frame quantisation something to do ``get a clean state soon'' -- and hasn't frame quantisation something to do
with media data, which is handled in the vault? with media data, which is handled in the vault?
+ +
Well, actually, all of those are pitfalls to trap the unwary. About Well, actually, all of those are pitfalls to trap the unwary. About
cleanliness, well, sigh! Doing rounding soon will leave us with a huge cleanliness, well, sigh! Doing rounding soon will leave us with a huge
amount of degraded information flows throughout the whole system; as a amount of degraded information flows throughout the whole system; as a
@ -183,7 +182,7 @@ application the subsystem most remote and unaware of output requirements.
- rounding/quantising in the GUI is extremely common within media applications; - rounding/quantising in the GUI is extremely common within media applications;
unfortunately there does not appear to be a single rational argument in unfortunately there does not appear to be a single rational argument in
support of this habit. Most of all, it is a violation of the subsidiarity support of this habit. Most of all, it is a violation of the subsidiarity
principle. principle.
Which leaves us with the player and the session. Both positions could Which leaves us with the player and the session. Both positions could
arguably be supported. Here, a more careful consideration shows, that arguably be supported. Here, a more careful consideration shows, that

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

@ -46,7 +46,7 @@ Modules
------- -------
* Main Menu * Main Menu
- It doesn't have to be a menu. - It doesn't have to be a menu.
- Contains a a way to manage proyects, render as movie, setup the preferences, - Contains a a way to manage proyects, render as movie, setup the preferences,
customize the UI, manage the others modules, and capture a footage. customize the UI, manage the others modules, and capture a footage.
@ -59,7 +59,7 @@ Modules
. Just think of this... I have a footage of a kid playing with some red stick. . Just think of this... I have a footage of a kid playing with some red stick.
. I add this as an _In_ node. Then connect its output to a _Glow_ node. . I add this as an _In_ node. Then connect its output to a _Glow_ node.
Also connect the output of the _In_ node to a _RGB Curves_ node which I use Also connect the output of the _In_ node to a _RGB Curves_ node which I use
to filter a certain tone of red. The output to the curves is sent to the to filter a certain tone of red. The output to the curves is sent to the
alpha input of the glow node. The output of glow is sent to an _Out_ node. alpha input of the glow node. The output of glow is sent to an _Out_ node.
. I save this node layout as a preset, a file called `lightsaber.np`. I go . I save this node layout as a preset, a file called `lightsaber.np`. I go
@ -92,7 +92,7 @@ Modules
node (to convert audio to video), oscilators, noise, etc. For example, we node (to convert audio to video), oscilators, noise, etc. For example, we
could drive a brightness/contrast node with a one dimension noise generator, could drive a brightness/contrast node with a one dimension noise generator,
to obtain an scene with lightnings or broken lamps like “doom” to obtain an scene with lightnings or broken lamps like “doom”
* Sound * Sound
* Media Library: * Media Library:
@ -161,7 +161,7 @@ Modules
different timelines, maybe when selecting in one module the others could different timelines, maybe when selecting in one module the others could
switch inmmediatly, but maybe it is useful in some case. switch inmmediatly, but maybe it is useful in some case.
- It would be divided into three parts. - It would be divided into three parts.
. A list of nodes into the node layout . A list of nodes into the node layout
. The options of the selected node in the list. . The options of the selected node in the list.
. A curve timeline. A list for of the node parameters and curves for it. . A curve timeline. A list for of the node parameters and curves for it.

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

@ -67,7 +67,7 @@ I propose that the future Lumiera GUI is designed without too much (or anything)
* Jog feature + * Jog feature +
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. 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. - Comment: This idea seems feasible, it could be worked together with cehteh shuttle slider proposal.
-- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]] -- link:joelholdsworth[] [[DateTime(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) * 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)
@ -91,11 +91,11 @@ Let the user have more flexibility over the track view height. Some tracks can b
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. 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)]] -- 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. - 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)]] -- link:JoelHoldsworth[] [[DateTime(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. * 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)]] -- link:Ichthyostega[] [[DateTime(2008-08-08T15:18:31Z)]]
-- --
@ -118,7 +118,7 @@ Xinerama and twinView test comparison http://www.phoronix.com/scan.php?page=arti
* Automatic Clip Creation based on video content. + * 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. 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. - 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)]] -- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]]
* Import and Export SMIL files + * Import and Export SMIL files +
@ -143,7 +143,7 @@ Make the timeline view _sparse_, that means the time on top is not continuous an
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, ...) 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)]] -- 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? - 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)]] -- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
+ +
-- --
@ -288,7 +288,7 @@ When attaching such and such effect to a track, disable "play" before attaching
-- link:JoelHoldsworth[] [[DateTime(2008-07-24T16:24:50Z)]] -- 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. ;-) * 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)]] -- link:Ichthyostega[] [[DateTime(2008-07-27T23:04:42Z)]]
-- --

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

@ -5,7 +5,7 @@ GuiBrainstorming Reviewed - Won't Implement
* Help feedback for quality management + * Help feedback for quality management +
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 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. - 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)]] -- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:47:35Z)]]
@ -28,7 +28,7 @@ If it was context sensitive, then it would provide relevant information, similar
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. 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)]] -- link:Tree[][[DateTime(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 - 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)]] -- link:JoelHoldsworth[] [[DateTime(2008-07-23T20:45:00Z)]]
* Help and visual prompts use GIFs for visual cue as to time behaviour of feature. + * Help and visual prompts use GIFs for visual cue as to time behaviour of feature. +
@ -54,10 +54,10 @@ The user could be asked to choose their experience level, and more complex optio
- 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. - 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)]] -- link:JoelHoldsworth[] [[DateTime(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. * 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 [[DateTime(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. - 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)]] -- link:joelholdsworth[] [[DateTime(2008-07-21T21:58:48Z)]]
* Client / Server Model + * Client / Server Model +
@ -82,7 +82,7 @@ There may be several methods to make menu selections, and other choices. The Gui
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.. 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)]]. --link:Tree[][[DateTime(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. - 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)]] -- link:joelholdsworth[] [[DateTime(2008-07-19T19:42:04Z)]]
* GUI development - flexible approach - using "Skin Methods" + * GUI development - flexible approach - using "Skin Methods" +
@ -105,7 +105,7 @@ The Status bar can show more information but isn't directly in the users view, h
+ +
This might be a bit different to some common other user interfaces (M$...) but I think this is much more valuable. 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)]] -- 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. - 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)]] -- link:JoelHoldsworth[] [[DateTime(2008-07-22T21:42:32Z)]]
+ +

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

@ -40,7 +40,7 @@ Akhil
the linkage to change in the middle of the timeline. the linkage to change in the middle of the timeline.
Richard Spindler Richard Spindler
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~
-> link:ConceptProposals/RichardSpindler.html[Richard's Proposal] -> link:ConceptProposals/RichardSpindler.html[Richard's Proposal]
@ -64,12 +64,12 @@ Richard Spindler
of elegantly expressing this concept through the views that we already have. of elegantly expressing this concept through the views that we already have.
Alcarinque Alcarinque
~~~~~~~~~~ ~~~~~~~~~~
-> link:ConceptProposals/Alcarinque.html[Proposal by »Alcarinque« (Francisco G. Rodriguez)] (http://telniratha.atspace.com/spec.html[original page]) -> link:ConceptProposals/Alcarinque.html[Proposal by »Alcarinque« (Francisco G. Rodriguez)] (http://telniratha.atspace.com/spec.html[original page])
.Things I like .Things I like
* Node Layouts in the media library. This isn't a page about the ML, but I like your ideas of having stored node layouts in the library. My own name for these is compound effects - but it's the same idea. Your idea of having collecting a library of these on the website is pretty cool as well. * Node Layouts in the media library. This isn't a page about the ML, but I like your ideas of having stored node layouts in the library. My own name for these is compound effects - but it's the same idea. Your idea of having collecting a library of these on the website is pretty cool as well.
* Being able to connect the view port to different plugs in the compositing system - rather like the PFL buttons on a mixing desk. * Being able to connect the view port to different plugs in the compositing system - rather like the PFL buttons on a mixing desk.
* Keyable parameters, automatable on the timeline * Keyable parameters, automatable on the timeline
* Having a transform trajectory applied to every track * Having a transform trajectory applied to every track
@ -83,7 +83,7 @@ Alcarinque
clips. clips.
Hermann Vosseler (Ichthyo) Hermann Vosseler (Ichthyo)
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~
-> http://ichthyostega.de/cin3/drafts/GUI-draft1.html[] -> http://ichthyostega.de/cin3/drafts/GUI-draft1.html[]

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

@ -91,14 +91,14 @@ extra user experience, instead the user has to learn a new kind of window class.
To chime in with the commenting... this comparison rather strengthened my preference for paradigm #2 _for our situation here._ 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: 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 pannels, 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 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..." 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. 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) 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. + 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)]] -- link:Ichthyostega[] [[DateTime(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. + 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)]] -- link:ct[] [[DateTime(2009-02-01T09:40:08Z)]]

4
doc/design/gui/GuiDiscussion/scrolling.txt
View file

@ -14,7 +14,7 @@ Scrolling without modifiers should jump directly from the current frame to the n
Shift Modifiers Shift Modifiers
--------------- ---------------
The Shift modifier should be used to toggle how scrolling with the mouse affects the gui. The Shift modifier should be used to toggle how scrolling with the mouse affects the gui.
So scrolling while holding down Shift should not scroll horizontally but instead let you scroll through the tracks vertically. This is just a very small detail, but it does matter if you want to cut 2 hours of a Musical filmed with several cameras and two or more effects-tracks. Then you will mind whether you have to use your mouse at a border of the timeline or if you can let it stay where it is. So scrolling while holding down Shift should not scroll horizontally but instead let you scroll through the tracks vertically. This is just a very small detail, but it does matter if you want to cut 2 hours of a Musical filmed with several cameras and two or more effects-tracks. Then you will mind whether you have to use your mouse at a border of the timeline or if you can let it stay where it is.
@ -44,4 +44,4 @@ The Ctrl modifier should switch from normal scrolling to zooming like in most ot
Here again the Shift modifier held down together with the Control modifier should switch from time-zoom to switching the height of a track. Here again the Shift modifier held down together with the Control modifier should switch from time-zoom to switching the height of a track.
But in the second case there is a need for another definition: As every track can have it's own height, there should also be the possibility of changing the height of all tracks at one time. Here it would be a good idea to let the modifier change its catchment area to all tracks when the mouse pointer is over a trackhead as this should be a big enough area so that you don't have to care on which pixel the mouse pointer exactly is. But in the second case there is a need for another definition: As every track can have it's own height, there should also be the possibility of changing the height of all tracks at one time. Here it would be a good idea to let the modifier change its catchment area to all tracks when the mouse pointer is over a trackhead as this should be a big enough area so that you don't have to care on which pixel the mouse pointer exactly is.

4
doc/devel/DoxygenLayout.xml
View file

@ -7,7 +7,7 @@
<tab type="modules" visible="yes" title="" intro="Subsystems"/> <tab type="modules" visible="yes" title="" intro="Subsystems"/>
<tab type="classes" visible="yes" title=""> <tab type="classes" visible="yes" title="">
<tab type="classlist" visible="yes" title="" intro=""/> <tab type="classlist" visible="yes" title="" intro=""/>
<tab type="classindex" visible="$ALPHABETICAL_INDEX" title=""/> <tab type="classindex" visible="$ALPHABETICAL_INDEX" title=""/>
<tab type="hierarchy" visible="no" title="" intro=""/> <tab type="hierarchy" visible="no" title="" intro=""/>
<tab type="classmembers" visible="yes" title="" intro=""/> <tab type="classmembers" visible="yes" title="" intro=""/>
</tab> </tab>
@ -20,7 +20,7 @@
<tab type="globals" visible="yes" title="" intro=""/> <tab type="globals" visible="yes" title="" intro=""/>
</tab> </tab>
<tab type="pages" visible="yes" title="" intro=""/> <tab type="pages" visible="yes" title="" intro=""/>
<tab type="examples" visible="yes" title="" intro=""/> <tab type="examples" visible="yes" title="" intro=""/>
</navindex> </navindex>
<!-- Layout definition for a class page --> <!-- Layout definition for a class page -->

8
doc/devel/meeting_summary/2007-08-10.txt
View file

@ -27,7 +27,7 @@ _Aug 10, 2007 in #lumiera_
- we have to provide coverter nodes to convert frame formats for accessing different libraries anyway (ffmpeg, v4l, gstreamer, ...) - we have to provide coverter nodes to convert frame formats for accessing different libraries anyway (ffmpeg, v4l, gstreamer, ...)
- we need a pool of worker threads and associated APIs - we need a pool of worker threads and associated APIs
- accessing frames has a _time_ (get until..), _unique frame identifier_ (see below), _policies_ (what to do when out of time, quality required,..) and _hints_ (recursive dependency, must cache, playback speed and direction, ...) - accessing frames has a _time_ (get until..), _unique frame identifier_ (see below), _policies_ (what to do when out of time, quality required,..) and _hints_ (recursive dependency, must cache, playback speed and direction, ...)
- for each sequence (configuration) each node has a number (monotonic incrementing), a generation counter (increment on each parameter change), a propagation sum (from parent nodes) - for each sequence (configuration) each node has a number (monotonic incrementing), a generation counter (increment on each parameter change), a propagation sum (from parent nodes)
- frames are identified by their time (frame number) and node number plus generation number and propagation sum. This allows easily to find out when a frame has to be rerendered - frames are identified by their time (frame number) and node number plus generation number and propagation sum. This allows easily to find out when a frame has to be rerendered
- no difference between compositor and viewer - no difference between compositor and viewer
@ -42,14 +42,14 @@ _Aug 10, 2007 in #lumiera_
- they do the mixing of contained things - they do the mixing of contained things
- can be recursive, the GUI represents basically a tree - can be recursive, the GUI represents basically a tree
- we need some ``wiring'' abstraction for the GUI to make it a real graph - we need some ``wiring'' abstraction for the GUI to make it a real graph
- rendering frames, context between frames - rendering frames, context between frames
- the proc layer _only queries frames_ (by identifier and timeout) the backend tries to serve the best it can do (from cache or let them render) - the proc layer _only queries frames_ (by identifier and timeout) the backend tries to serve the best it can do (from cache or let them render)
- each render job carries some _quality limit_ (as S/N ratio) when previewing or scratching through the project this is used to generate reasonable quality previews - each render job carries some _quality limit_ (as S/N ratio) when previewing or scratching through the project this is used to generate reasonable quality previews
- individual processing nodes can use additional state for their calculations... - individual processing nodes can use additional state for their calculations...
* the node objects themselves should stay stateless, i.e. they shouldn't store state internally. * the node objects themselves should stay stateless, i.e. they shouldn't store state internally.
* they can use special _context frames_, which are provided and managed by the backend (as opaque data blocks). * they can use special _context frames_, which are provided and managed by the backend (as opaque data blocks).
* they can depend on previous state, i.e request from the backend a previous context frame, the same way as they can request previous media frames from the bakend, but there is no guarantee that the backend will satisfy this request. * they can depend on previous state, i.e request from the backend a previous context frame, the same way as they can request previous media frames from the bakend, but there is no guarantee that the backend will satisfy this request.
* on the question who decides what to do after a cache miss, we tend to put the decision into the render node (because this seems to be the simpler approach), but still have to work out the details. * on the question who decides what to do after a cache miss, we tend to put the decision into the render node (because this seems to be the simpler approach), but still have to work out the details.

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

@ -2,7 +2,7 @@ Initial Lumiera Developers Meeting
================================== ==================================
:Date: 2008-02-01 :Date: 2008-02-01
//Menu: label 2008-02-01 the first Lumiera Developers Meeting //Menu: label 2008-02-01 the first Lumiera Developers Meeting
__Participants__ __Participants__
@ -71,7 +71,7 @@ Since the render nodes are stateless they can be driven in multiple threads (but
The naming discussion 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 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" ;-)
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: 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 not be an existing project

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

@ -71,7 +71,7 @@ Firstly, as SimAV was not able to be present during the meeting a proposal by hi
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. 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 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.
@ -83,7 +83,7 @@ Workflow is another important aspect to take into account in the design. A lot o
Customisation is deemed important. Some points brought up in the discussion: 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. * 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 * 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. * 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. * There should be a working skeleton or some fixed anchor but gui operations should be bound to a scripting language to achieve customization.
@ -111,7 +111,7 @@ some discussion:
Some brainstorming points about usability: Some brainstorming points about usability:
* We need a realy good bezier widget for all sorts of curves. * We need a realy good bezier widget for all sorts of curves.
* Faders that can be grabbed everywhere are nice like like ardours and Blender faders. Or others which have no big knob * Faders that can be grabbed everywhere are nice like like ardours and Blender faders. Or others which have no big knob
* The controls in blender's node view would be a good modal to copy (not advocating GL UI, just using widgets and concepts). * The controls in blender's node view would be a good modal to copy (not advocating GL UI, just using widgets and concepts).
One extra point: One extra point:
@ -163,14 +163,14 @@ The next meeting will be at thuesday 8th may 21:00GMT
12:52 gmerlin 1. arithmetic <-> struct 12:52 gmerlin 1. arithmetic <-> struct
12:53 gmerlin 2. Generic <-> format specific 12:53 gmerlin 2. Generic <-> format specific
12:53 cehteh arithmetic for sure 12:53 cehteh arithmetic for sure
12:53 gmerlin On the decoder API side, I want to export ideally only one type 12:53 gmerlin On the decoder API side, I want to export ideally only one type
12:54 gmerlin No no SMPTEXXX and ISO999908098 12:54 gmerlin No no SMPTEXXX and ISO999908098
12:54 cehteh will that be attached to the frames in a intrusive way? 12:54 cehteh will that be attached to the frames in a intrusive way?
12:54 cehteh i rather leave the attaching up to the application 12:54 cehteh i rather leave the attaching up to the application
12:54 gmerlin intrusive? 12:54 gmerlin intrusive?
12:55 cehteh struct frame { uint64_t timecode; } vs... 12:55 cehteh struct frame { uint64_t timecode; } vs...
12:55 cehteh struct frame { struct metadata* something; } 12:55 cehteh struct frame { struct metadata* something; }
12:55 cehteh or even vs something done at a api level 12:55 cehteh or even vs something done at a api level
12:56 gmerlin struct lumiera_video_frame { gavl_video_frame_t * f; uint64_t timecode}; 12:56 gmerlin struct lumiera_video_frame { gavl_video_frame_t * f; uint64_t timecode};
12:56 gmerlin Or add timecodes to gavl_video_frame_t 12:56 gmerlin Or add timecodes to gavl_video_frame_t
12:57 cehteh struct lumiera_video_frame { gavl_video_frame_t * f; struct metadata* timecode_n_stuff; } 12:57 cehteh struct lumiera_video_frame { gavl_video_frame_t * f; struct metadata* timecode_n_stuff; }
@ -179,11 +179,11 @@ The next meeting will be at thuesday 8th may 21:00GMT
12:58 cehteh i mean thats the purpose of timecodes .. to tag every frame and dont make assumptions that your footage is perfect 12:58 cehteh i mean thats the purpose of timecodes .. to tag every frame and dont make assumptions that your footage is perfect
12:58 ichthyo but a struct metadata* would rather mean to keep it out of basic GAVL and have a libmetadata -- which may be integrated with GAVL -- right? 12:58 ichthyo but a struct metadata* would rather mean to keep it out of basic GAVL and have a libmetadata -- which may be integrated with GAVL -- right?
12:59 cehteh someome may have stolen a frame :P 12:59 cehteh someome may have stolen a frame :P
12:59 cehteh thats gmerlins decision ... 12:59 cehteh thats gmerlins decision ...
12:59 gmerlin I'm against gavl integration of metadata 12:59 gmerlin I'm against gavl integration of metadata
12:59 gmerlin gavl has a clear scope: Number crunching 12:59 gmerlin gavl has a clear scope: Number crunching
01:00 cehteh gmerlin: you somehow have to pass it from the decoder to the application 01:00 cehteh gmerlin: you somehow have to pass it from the decoder to the application
01:01 cehteh i would prefer to introduce some sidechannel 01:01 cehteh i would prefer to introduce some sidechannel
01:01 gmerlin Yes, gmerlin_avdecoder will provide a separate function for getting the next timecode 01:01 gmerlin Yes, gmerlin_avdecoder will provide a separate function for getting the next timecode
01:01 gmerlin bgav_get_next_timecode() 01:01 gmerlin bgav_get_next_timecode()
01:01 cehteh gavl_get_frame (gavl_frame* place the frame here, metadata* place metadata there) 01:01 cehteh gavl_get_frame (gavl_frame* place the frame here, metadata* place metadata there)
@ -193,7 +193,7 @@ The next meeting will be at thuesday 8th may 21:00GMT
01:06 gmerlin better have them together in one lib 01:06 gmerlin better have them together in one lib
01:06 cehteh actually i would like to cache gavls internal states into the backend 01:06 cehteh actually i would like to cache gavls internal states into the backend
01:08 gmerlin Ok, so timecodes are YYYYMMDDHHMMSSFF as int64_t 01:08 gmerlin Ok, so timecodes are YYYYMMDDHHMMSSFF as int64_t
01:08 cehteh the indexing is something i prolly have some words about 01:08 cehteh the indexing is something i prolly have some words about
01:09 cehteh timecodes are uint64_t as microseconds 01:09 cehteh timecodes are uint64_t as microseconds
01:09 cehteh well for lumiera :-P 01:09 cehteh well for lumiera :-P
01:10 cehteh YYYYMMDDHHMMSSFF as int64_t isnt that much better than a struct :P 01:10 cehteh YYYYMMDDHHMMSSFF as int64_t isnt that much better than a struct :P
@ -215,9 +215,9 @@ The next meeting will be at thuesday 8th may 21:00GMT
01:13 ichthyo also, what sort of timecode this was based on (drop frame or not) 01:13 ichthyo also, what sort of timecode this was based on (drop frame or not)
01:13 cehteh gmerlin: thats a important point .. just uint64_t does not suffice 01:13 cehteh gmerlin: thats a important point .. just uint64_t does not suffice
01:13 cehteh it needs a tag describing what kind of timecode was used 01:13 cehteh it needs a tag describing what kind of timecode was used
01:14 cehteh no matter how you encode it 01:14 cehteh no matter how you encode it
01:14 cehteh and iirc there are quite some timecodes 01:14 cehteh and iirc there are quite some timecodes
01:14 ichthyo because in this respect richard was right: we need to be able to reprocuce any value 1:1 01:14 ichthyo because in this respect richard was right: we need to be able to reprocuce any value 1:1
01:14 cehteh yep 01:14 cehteh yep
01:15 cehteh further i want to be able to convert between any kind of timecode in a fingersnip 01:15 cehteh further i want to be able to convert between any kind of timecode in a fingersnip
01:15 gmerlin ichthyo: and that's impossible with usecs 01:15 gmerlin ichthyo: and that's impossible with usecs
@ -243,7 +243,7 @@ The next meeting will be at thuesday 8th may 21:00GMT
.about Metadata .about Metadata
---- ----
01:19 cehteh gmerlin: well .. how bout other metadata 01:19 cehteh gmerlin: well .. how bout other metadata
01:19 cehteh your decoder needs to pass that too 01:19 cehteh your decoder needs to pass that too
01:20 gmerlin like? 01:20 gmerlin like?
01:20 gmerlin Author, Artist title... 01:20 gmerlin Author, Artist title...
01:20 cehteh some cameras encode shutter speed, focus, gain control, colour balance 01:20 cehteh some cameras encode shutter speed, focus, gain control, colour balance
@ -254,7 +254,7 @@ The next meeting will be at thuesday 8th may 21:00GMT
01:21 gmerlin flac has vorbis metadata 01:21 gmerlin flac has vorbis metadata
01:21 ichthyo important for the more modern sound formats 01:21 ichthyo important for the more modern sound formats
01:21 cehteh dunno .. just thinkin about pro codecs and raw film metadata 01:21 cehteh dunno .. just thinkin about pro codecs and raw film metadata
01:21 ichthyo just wanting to point out: things to come here, 01:21 ichthyo just wanting to point out: things to come here,
01:22 ichthyo e.g for sound: what stream is what channel 01:22 ichthyo e.g for sound: what stream is what channel
01:22 gmerlin Channel locations are handles by gavl 01:22 gmerlin Channel locations are handles by gavl
01:22 gmerlin If you have a multichannel stream 01:22 gmerlin If you have a multichannel stream
@ -285,6 +285,6 @@ The next meeting will be at thuesday 8th may 21:00GMT
01:28 cehteh plugin parameters are volatile 01:28 cehteh plugin parameters are volatile
01:33 gmerlin One other point (but too late for it now) are audio timecodes. I'll adress that on libopenvideo 01:33 gmerlin One other point (but too late for it now) are audio timecodes. I'll adress that on libopenvideo
01:33 cehteh we will write a little more sophisticated timecode library 01:33 cehteh we will write a little more sophisticated timecode library
01:34 cehteh gmerlin: that should be unified :) 01:34 cehteh gmerlin: that should be unified :)
---- ----

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

@ -58,7 +58,7 @@ On the whole, there is no conclusion yet. Certainly, this proposal needs more di
While in this discussion, several aspects of the cooperation of GUI and Proc layer are considered. 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 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.
* the adjustment of objects linked together by a placement can be handled as follows: * 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) . 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 . 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
. GUI pulls the necessary properties by calling Proc on a per object base. . GUI pulls the necessary properties by calling Proc on a per object base.

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

@ -11,7 +11,7 @@ __Participants__
* ichthyo * ichthyo
* joelholdsworth * joelholdsworth
* raffa * raffa
_Summary and transcript supplemented by Ichthyo 11/2011_ _Summary and transcript supplemented by Ichthyo 11/2011_
@ -19,7 +19,7 @@ _Summary and transcript supplemented by Ichthyo 11/2011_
Platform and lib dependency status Platform and lib dependency status
---------------------------------- ----------------------------------
Right away, there is agreement between all 3 core devs that the Lumiera project Right away, there is agreement between all 3 core devs that the Lumiera project
should try to stay close to a *stable reference linux distribution*. Usually, should try to stay close to a *stable reference linux distribution*. Usually,
developers tend to stick to ``latest greatest'', causing lots of difficult to resolve developers tend to stick to ``latest greatest'', causing lots of difficult to resolve
problems to packagers and ursers of their software. The Lumiera team wants to go into problems to packagers and ursers of their software. The Lumiera team wants to go into
the opposite direction: staying close to a mature and stable distro and rather try to the opposite direction: staying close to a mature and stable distro and rather try to
@ -87,7 +87,7 @@ panel layouts would be covered easily
[2008-11-12 22:05:46] <joelholdsworth> so bundling GUI together with plugins is easier now, right? [2008-11-12 22:05:46] <joelholdsworth> so bundling GUI together with plugins is easier now, right?
[2008-11-12 22:05:59] <joelholdsworth> we implement some kind of parameters system [2008-11-12 22:05:59] <joelholdsworth> we implement some kind of parameters system
[2008-11-12 22:06:03] <ichthyo> yes [2008-11-12 22:06:03] <ichthyo> yes
[2008-11-12 22:06:14] <cehteh> joelholdsworth: thats up to you .. but the plugin system is ready [2008-11-12 22:06:14] <cehteh> joelholdsworth: thats up to you .. but the plugin system is ready
[2008-11-12 22:06:27] <joelholdsworth> yeah that's fine [2008-11-12 22:06:27] <joelholdsworth> yeah that's fine
[2008-11-12 22:06:38] <joelholdsworth> if you want to extend the GUI you just expose and interface for it [2008-11-12 22:06:38] <joelholdsworth> if you want to extend the GUI you just expose and interface for it
@ -126,14 +126,14 @@ panel layouts would be covered easily
plugin systems we want to wrap up. plugin systems we want to wrap up.
[2008-11-12 22:13:01] <cehteh> you have a list (or maybe tree) of parameters .. presentation aside [2008-11-12 22:13:01] <cehteh> you have a list (or maybe tree) of parameters .. presentation aside
... tree just because some parameters depend on the presence of some else ... tree just because some parameters depend on the presence of some else
and you have a presentation .. and you have a presentation ..
[2008-11-12 22:11:53] <ichthyo> next problem is: [2008-11-12 22:11:53] <ichthyo> next problem is:
[2008-11-12 22:12:16] <ichthyo> the plugins need to allocate some space in the GUI and should not clutter [2008-11-12 22:12:16] <ichthyo> the plugins need to allocate some space in the GUI and should not clutter
the workspace this is a tough really tough interface design problem the workspace this is a tough really tough interface design problem
because some plugins aren't just some "optional stuff", but wired because some plugins aren't just some "optional stuff", but wired
right into the core operation right into the core operation
[2008-11-12 22:12:54] <joelholdsworth> well ichthyo: I'm not planning to allow plugins to "take over" [2008-11-12 22:12:54] <joelholdsworth> well ichthyo: I'm not planning to allow plugins to "take over"
handling workflow. they get to extend very specific parts of the UI handling workflow. they get to extend very specific parts of the UI
[2008-11-12 22:13:09] <joelholdsworth> e.g. params [2008-11-12 22:13:09] <joelholdsworth> e.g. params
@ -171,12 +171,12 @@ panel layouts would be covered easily
or to bind them to some knobs on an external control surface or to bind them to some knobs on an external control surface
and now you have multiple instances of the same panner plugin and now you have multiple instances of the same panner plugin
so we need a naming scheme so we need a naming scheme
[2008-11-12 22:19:03] <cehteh> how i thought about this: [2008-11-12 22:19:03] <cehteh> how i thought about this:
1) plugin provides the list of its parameters (maybe as tree) 1) plugin provides the list of its parameters (maybe as tree)
2) there is a config file (config system) which gets installed 2) there is a config file (config system) which gets installed
with the plugins which defines the default layout with the plugins which defines the default layout
3) user might override that in his own configs ... 3) user might override that in his own configs ...
but still only defaults for new instances of the things but still only defaults for new instances of the things
4) the actual configured state is saved with the session 4) the actual configured state is saved with the session
while all this config just is a definition which gets applied to a kindof stylesheet while all this config just is a definition which gets applied to a kindof stylesheet
@ -200,7 +200,7 @@ panel layouts would be covered easily
[2008-11-12 22:26:48] <ichthyo> which means, some GUI code in the plugin takes over. That is something I utterly dislike [2008-11-12 22:26:48] <ichthyo> which means, some GUI code in the plugin takes over. That is something I utterly dislike
[2008-11-12 22:33:29] <cehteh> no thats not needed [2008-11-12 22:33:29] <cehteh> no thats not needed
[2008-11-12 22:33:29] <cehteh> in the session each object has a uuid thats its address [2008-11-12 22:33:29] <cehteh> in the session each object has a uuid thats its address
[2008-11-12 22:33:29] <cehteh> each parameter has a uuid too(interface system) [2008-11-12 22:33:29] <cehteh> each parameter has a uuid too(interface system)
[2008-11-12 22:33:31] <cehteh> so you can say parameter 0x2344545645654534 of object 0x4543765732525t643 .... [2008-11-12 22:33:31] <cehteh> so you can say parameter 0x2344545645654534 of object 0x4543765732525t643 ....
[2008-11-12 22:33:34] <cehteh> "yet unknown" doesnt exist .. it is either unknown or known :) [2008-11-12 22:33:34] <cehteh> "yet unknown" doesnt exist .. it is either unknown or known :)
@ -214,7 +214,7 @@ panel layouts would be covered easily
I have the object representing the connectionn to the plugin, I can provide the GUI with I have the object representing the connectionn to the plugin, I can provide the GUI with
some means for re-addressing a certain parameter, e.g. for a key binding, and, of course some means for re-addressing a certain parameter, e.g. for a key binding, and, of course
for re-establishing the same binding when re-creating the session from storage for re-establishing the same binding when re-creating the session from storage
[2008-11-12 23:00:50] <ichthyo> Further, with plugin guis instances there is yet another problem in that you probably [2008-11-12 23:00:50] <ichthyo> Further, with plugin guis instances there is yet another problem in that you probably
have more option windows of some plugins as you can show in any reasonable GUI have more option windows of some plugins as you can show in any reasonable GUI
These issues were one of the reasons I made this "FeatureBundle" proposal some time ago, These issues were one of the reasons I made this "FeatureBundle" proposal some time ago,
@ -233,13 +233,13 @@ panel layouts would be covered easily
say some color correction on 2 tracks, and then you open and close variouos plugins say some color correction on 2 tracks, and then you open and close variouos plugins
for several different clips ...plus, maybe the possibility to "pin" some of the plugin for several different clips ...plus, maybe the possibility to "pin" some of the plugin
windows, while others just allocate the next free slot windows, while others just allocate the next free slot
[2008-11-12 23:13:14] <joelholdsworth> I guess we need some modeless way of putting plugin controls in a panel [2008-11-12 23:13:14] <joelholdsworth> I guess we need some modeless way of putting plugin controls in a panel
[2008-11-12 23:15:32] <joelholdsworth> so maybe having panels open up - or do it like inkscape with a scrollable panel [2008-11-12 23:15:32] <joelholdsworth> so maybe having panels open up - or do it like inkscape with a scrollable panel
container that gets longer as more panels are opened container that gets longer as more panels are opened
[2008-11-12 23:20:10] <cehteh> Cinelerra's plugin guis who constantly get lost behind the main window are really a mess [2008-11-12 23:20:10] <cehteh> Cinelerra's plugin guis who constantly get lost behind the main window are really a mess
[2008-11-12 23:19:28] <ichthyo> joelholdsworth: have you already any ideas about focus handling? [2008-11-12 23:19:28] <ichthyo> joelholdsworth: have you already any ideas about focus handling?
[2008-11-12 23:20:15] <ichthyo> joelholdsworth: do we get a "current object", a "current track" or the like [2008-11-12 23:20:15] <ichthyo> joelholdsworth: do we get a "current object", a "current track" or the like
which receives keybord input which receives keybord input
[2008-11-12 23:20:37] <joelholdsworth> keybaord focus, yes - that was the plan [2008-11-12 23:20:37] <joelholdsworth> keybaord focus, yes - that was the plan
@ -285,7 +285,7 @@ panel layouts would be covered easily
[2008-11-12 23:31:54] <ichthyo> but it's fine we are all aware of the problem and seemingly share the same approach [2008-11-12 23:31:54] <ichthyo> but it's fine we are all aware of the problem and seemingly share the same approach
config system + some sort of automatic persistent references within proc + some config system + some sort of automatic persistent references within proc + some
indirection + maybe a focus system indirection + maybe a focus system
[2008-11-12 23:33:10] <ichthyo> and another point I want to note is: all of us are rather reluctant to allow plugins [2008-11-12 23:33:10] <ichthyo> and another point I want to note is: all of us are rather reluctant to allow plugins
to create GUIs on their own to create GUIs on their own
[2008-11-12 23:33:27] <joelholdsworth> depends what you mean by that [2008-11-12 23:33:27] <joelholdsworth> depends what you mean by that
@ -300,15 +300,15 @@ panel layouts would be covered easily
copy/paste and a lot of diverging GUI, so you need to "help" the plugins copy/paste and a lot of diverging GUI, so you need to "help" the plugins
by putting them in a strict framework. Then, on top of that we allow by putting them in a strict framework. Then, on top of that we allow
extensions which allow a little more flexibility extensions which allow a little more flexibility
[2008-11-12 23:35:20] <ichthyo> Steinberg failed to address this problem properly and VST bears on this heritage until today [2008-11-12 23:35:20] <ichthyo> Steinberg failed to address this problem properly and VST bears on this heritage until today
[2008-11-12 23:35:35] <cehteh> make it in a way where the 'correct' way is also the most convenient for any programmer is [2008-11-12 23:35:35] <cehteh> make it in a way where the 'correct' way is also the most convenient for any programmer is
all and the best we can do all and the best we can do
[2008-11-12 23:35:49] * ichthyo nods [2008-11-12 23:35:49] * ichthyo nods
[2008-11-12 23:36:04] <joelholdsworth> yes [2008-11-12 23:36:04] <joelholdsworth> yes
[2008-11-12 23:36:07] <cehteh> note the 'any' ... [2008-11-12 23:36:07] <cehteh> note the 'any' ...
[2008-11-12 23:36:20] <ichthyo> :-P [2008-11-12 23:36:20] <ichthyo> :-P
[2008-11-12 23:36:26] <cehteh> means mad programmers, beginner programmers, experienced programmers, html programmers ... [2008-11-12 23:36:26] <cehteh> means mad programmers, beginner programmers, experienced programmers, html programmers ...
[2008-11-12 23:36:52] <joelholdsworth> but I'm thinking we do need to remember that the majority of our plugin developers [2008-11-12 23:36:52] <joelholdsworth> but I'm thinking we do need to remember that the majority of our plugin developers
will be part of this project team will be part of this project team
@ -351,7 +351,7 @@ from the *support library* (+liblumiera.so+).
[2008-11-12 23:53:14] <cehteh> the interface/plugin system has now its own rules which are somewhat special [2008-11-12 23:53:14] <cehteh> the interface/plugin system has now its own rules which are somewhat special
and good by that way. I am thinking about a interface_doc.h which can be used and good by that way. I am thinking about a interface_doc.h which can be used
to generate documentation from the interface language with some special gcc/cpp flags to generate documentation from the interface language with some special gcc/cpp flags
[2008-11-12 23:53:18] <ichthyo> those interface parts will be contained in a "Lumiera sdk" [2008-11-12 23:53:18] <ichthyo> those interface parts will be contained in a "Lumiera sdk"
and probably all those interfaces (for C++) will go into namespace lumiera:: and probably all those interfaces (for C++) will go into namespace lumiera::
because it's just the best and most natural pick because it's just the best and most natural pick
@ -359,11 +359,11 @@ from the *support library* (+liblumiera.so+).
a real interface part and cleanly separated from the implementation a real interface part and cleanly separated from the implementation
meaning: I don't want *.c and *.cpp files in this package/directory/namespace, meaning: I don't want *.c and *.cpp files in this package/directory/namespace,
unless they are really needed there unless they are really needed there
[2008-11-12 23:55:55] <cehteh> well interfaces themself need to be .c they need to be implemented [2008-11-12 23:55:55] <cehteh> well interfaces themself need to be .c they need to be implemented
and the implementation might adapt the code for example the config system and the implementation might adapt the code for example the config system
sometimes returns internal state as success/failure indicator sometimes returns internal state as success/failure indicator
but its interface just returns integers but its interface just returns integers
[2008-11-12 23:56:13] <ichthyo> so the question regarding namespaces is connected to the question: [2008-11-12 23:56:13] <ichthyo> so the question regarding namespaces is connected to the question:
how is the implementation organized in relation to the interface part? how is the implementation organized in relation to the interface part?
@ -396,11 +396,11 @@ from the *support library* (+liblumiera.so+).
[2008-11-13 00:04:28] <ichthyo> and only the class SessManagerImpl knows of the implementation class SessionImpl [2008-11-13 00:04:28] <ichthyo> and only the class SessManagerImpl knows of the implementation class SessionImpl
[2008-11-13 00:04:32] <ichthyo> and so on [2008-11-13 00:04:32] <ichthyo> and so on
[2008-11-13 00:04:50] <cehteh> well thats not important yet... [2008-11-13 00:04:50] <cehteh> well thats not important yet...
I currently have some 'mess' of includes because its just easier for now to mix them I currently have some 'mess' of includes because its just easier for now to mix them
all together and relative easy to clean up when done, and I don't have a differentiation all together and relative easy to clean up when done, and I don't have a differentiation
between interface and implementation headers .. because between interface and implementation headers .. because
a) its all implementation code yet a) its all implementation code yet
[2008-11-13 00:06:06] <cehteh> b) i was under the impression that i only wanted to export interfaces [2008-11-13 00:06:06] <cehteh> b) i was under the impression that i only wanted to export interfaces
over 'Interfaces' over 'Interfaces'
[2008-11-13 00:06:25] <ichthyo> ...which is fine [2008-11-13 00:06:25] <ichthyo> ...which is fine
@ -413,7 +413,7 @@ from the *support library* (+liblumiera.so+).
[2008-11-13 00:08:29] <ichthyo> but... on the long run I am sure we don't just get one "includes" package, [2008-11-13 00:08:29] <ichthyo> but... on the long run I am sure we don't just get one "includes" package,
rather I guess we get a (very small) tree of interfaces. rather I guess we get a (very small) tree of interfaces.
That's the rationale behind my keeping the implementation namespaces completely apart That's the rationale behind my keeping the implementation namespaces completely apart
[2008-11-13 00:08:53] <cehteh> ok [2008-11-13 00:08:53] <cehteh> ok
[2008-11-13 00:09:43] <cehteh> the _interface.c is the glue code which can stay in the implementation dir imo [2008-11-13 00:09:43] <cehteh> the _interface.c is the glue code which can stay in the implementation dir imo
[2008-11-13 00:10:16] <cehteh> actually i wanted a include dir too .. i just didnt start because i wanted to ask you too [2008-11-13 00:10:16] <cehteh> actually i wanted a include dir too .. i just didnt start because i wanted to ask you too
@ -433,7 +433,7 @@ from the *support library* (+liblumiera.so+).
[2008-11-13 00:16:29] <ichthyo> ok, back to the include dir question: [2008-11-13 00:16:29] <ichthyo> ok, back to the include dir question:
My proposal would be to use src/lumiera/... and namespace lumiera::... My proposal would be to use src/lumiera/... and namespace lumiera::...
(and its children) for the public interfaces (and its children) for the public interfaces
[2008-11-13 00:17:04] <cehteh> mhm thats the usual reversal operation [2008-11-13 00:17:04] <cehteh> mhm thats the usual reversal operation
[2008-11-13 00:17:31] <cehteh> src/lumiera/include/ ... gets installed in /usr/include/lumiera :P [2008-11-13 00:17:31] <cehteh> src/lumiera/include/ ... gets installed in /usr/include/lumiera :P
[2008-11-13 00:17:40] <cehteh> ok you dont have the include [2008-11-13 00:17:40] <cehteh> ok you dont have the include
@ -483,7 +483,7 @@ from the *support library* (+liblumiera.so+).
which need to be in the .h and need full public structure definitions which need to be in the .h and need full public structure definitions
which expose private details. I think these will stay private which expose private details. I think these will stay private
but if not i wont really care. but if not i wont really care.
[2008-11-13 00:27:06] <ichthyo> ah, I see [2008-11-13 00:27:06] <ichthyo> ah, I see
[2008-11-13 00:27:59] <ichthyo> probably those just count as "reasonable exceptions from the rule" [2008-11-13 00:27:59] <ichthyo> probably those just count as "reasonable exceptions from the rule"
[2008-11-13 00:28:33] <cehteh> well C has no access protection at all .. you have to do whats allowed/documented [2008-11-13 00:28:33] <cehteh> well C has no access protection at all .. you have to do whats allowed/documented
@ -499,7 +499,7 @@ from the *support library* (+liblumiera.so+).
[2008-11-13 00:33:02] <ichthyo> I always assume we have separate interface namespace(s) [2008-11-13 00:33:02] <ichthyo> I always assume we have separate interface namespace(s)
and implementation is in a different namespace then the exported interface and implementation is in a different namespace then the exported interface
basically I see two scenarios: basically I see two scenarios:
so, the first scenario I'd call "libarry type" so, the first scenario I'd call "libarry type"
it means that the implementation namespace is nested it means that the implementation namespace is nested
eg namespace mylib <-- the stuff the library users include and use in their code eg namespace mylib <-- the stuff the library users include and use in their code
@ -519,7 +519,7 @@ from the *support library* (+liblumiera.so+).
the way we discussed the way we discussed
for a real library, the situation is reversed: Often you have much code close for a real library, the situation is reversed: Often you have much code close
to the interface, maybe even inline to the interface, maybe even inline
e.g. think at boost: e.g. think at boost:
half of the code is immediately inline within the interface classes you use half of the code is immediately inline within the interface classes you use
and the more technical parts are in shallow sub-namespaces below and the more technical parts are in shallow sub-namespaces below
the good side of course is, that the implementation code doesn't need the good side of course is, that the implementation code doesn't need
@ -529,7 +529,7 @@ from the *support library* (+liblumiera.so+).
because it clearly documents what non-local parts you use because it clearly documents what non-local parts you use
that was my rationale for keeping the implementation part that was my rationale for keeping the implementation part
in a completely separate hierarchy. in a completely separate hierarchy.
[2008-11-13 00:43:17] <ichthyo> joelholdsworth: so you moved your gui code within namespace gui, is that correct? [2008-11-13 00:43:17] <ichthyo> joelholdsworth: so you moved your gui code within namespace gui, is that correct?
[2008-11-13 00:43:50] <joelholdsworth> yes that's right! [2008-11-13 00:43:50] <joelholdsworth> yes that's right!
[2008-11-13 00:43:59] <ichthyo> because, then the issue seems to be settled. [2008-11-13 00:43:59] <ichthyo> because, then the issue seems to be settled.
@ -570,7 +570,7 @@ from the *support library* (+liblumiera.so+).
[2008-11-13 00:51:56] <cehteh> we really dont need a 1:1 relation between dirs and namespaces [2008-11-13 00:51:56] <cehteh> we really dont need a 1:1 relation between dirs and namespaces
[2008-11-13 00:52:08] <ichthyo> so, then, how can the build system tell at what level of the tree below plugins [2008-11-13 00:52:08] <ichthyo> so, then, how can the build system tell at what level of the tree below plugins
we'd need to start with building one shared libarary? we'd need to start with building one shared libarary?
[2008-11-13 00:52:46] <ichthyo> would the following rule be ok for you? [2008-11-13 00:52:46] <ichthyo> would the following rule be ok for you?
[2008-11-13 00:52:58] <ichthyo> start with dir src/plugins and descend [2008-11-13 00:52:58] <ichthyo> start with dir src/plugins and descend
[2008-11-13 00:53:12] <ichthyo> depth-first tree search [2008-11-13 00:53:12] <ichthyo> depth-first tree search
@ -586,11 +586,11 @@ from the *support library* (+liblumiera.so+).
file *.c *cpp in some of the root directories... file *.c *cpp in some of the root directories...
the moment you add a *c or *cpp file in some new sub tree, the moment you add a *c or *cpp file in some new sub tree,
you'll find a <subtree-rootdirname>.lum in the corresponding bin dir you'll find a <subtree-rootdirname>.lum in the corresponding bin dir
[2008-11-13 00:55:17] <cehteh> thats prolly a good choice anyways [2008-11-13 00:55:17] <cehteh> thats prolly a good choice anyways
[2008-11-13 00:55:28] <cehteh> plugins shall be only at the leaves of the tree [2008-11-13 00:55:28] <cehteh> plugins shall be only at the leaves of the tree
[2008-11-13 00:55:42] <cehteh> be careful when linking [2008-11-13 00:55:42] <cehteh> be careful when linking
[2008-11-13 00:56:16] <cehteh> the autoconf build included a lot libs from configure which where not needed for plugins [2008-11-13 00:56:16] <cehteh> the autoconf build included a lot libs from configure which where not needed for plugins
[2008-11-13 00:56:57] <ichthyo> besides, I will set up a different "build environment" for plugins [2008-11-13 00:56:57] <ichthyo> besides, I will set up a different "build environment" for plugins
@ -601,7 +601,7 @@ from the *support library* (+liblumiera.so+).
[2008-11-13 00:58:12] <ichthyo> and I match them from the directory name [2008-11-13 00:58:12] <ichthyo> and I match them from the directory name
[2008-11-13 00:58:20] <ichthyo> the rest is fully automatic [2008-11-13 00:58:20] <ichthyo> the rest is fully automatic
[2008-11-13 00:58:14] * cehteh thinks [2008-11-13 00:58:14] * cehteh thinks
[2008-11-13 00:58:38] <cehteh> a bare plugin doesnt need any lib [2008-11-13 00:58:38] <cehteh> a bare plugin doesnt need any lib
[2008-11-13 00:59:04] <ichthyo> not even the lumiera support lib? [2008-11-13 00:59:04] <ichthyo> not even the lumiera support lib?
[2008-11-13 00:59:11] <ichthyo> liblumiera.a [2008-11-13 00:59:11] <ichthyo> liblumiera.a
@ -618,7 +618,7 @@ from the *support library* (+liblumiera.so+).
[2008-11-13 01:00:54] <ichthyo> but what is when a plugin wants to open another interface [2008-11-13 01:00:54] <ichthyo> but what is when a plugin wants to open another interface
[2008-11-13 01:01:11] <cehteh> it asks the host to do it [2008-11-13 01:01:11] <cehteh> it asks the host to do it
[2008-11-13 01:01:17] <ichthyo> doesn't it need to link against your plugin system impl? [2008-11-13 01:01:17] <ichthyo> doesn't it need to link against your plugin system impl?
[2008-11-13 01:01:32] <cehteh> nope .. just the interface.h [2008-11-13 01:01:32] <cehteh> nope .. just the interface.h
[2008-11-13 01:02:49] <cehteh> interface.h defines some functions .. but these are not available for the plugin either [2008-11-13 01:02:49] <cehteh> interface.h defines some functions .. but these are not available for the plugin either
but the nature of plugins is to extend the system .. but the nature of plugins is to extend the system ..
thus follows that they will need some more specific libs in many cases thus follows that they will need some more specific libs in many cases
@ -638,7 +638,7 @@ from the *support library* (+liblumiera.so+).
[2008-11-13 01:07:41] <ichthyo> as said, in future I'll tell scons [2008-11-13 01:07:41] <ichthyo> as said, in future I'll tell scons
"build everything below this root dir into a dynamic module" "build everything below this root dir into a dynamic module"
and scons will derive the necessary compile and link commands and scons will derive the necessary compile and link commands
[2008-11-13 01:10:32] <ichthyo> ah, another little issue [2008-11-13 01:10:32] <ichthyo> ah, another little issue
[2008-11-13 01:10:42] <ichthyo> we have two tools directories currently [2008-11-13 01:10:42] <ichthyo> we have two tools directories currently
[2008-11-13 01:10:53] <ichthyo> one as "src/tool" [2008-11-13 01:10:53] <ichthyo> one as "src/tool"
@ -701,10 +701,10 @@ from the *support library* (+liblumiera.so+).
Could you explain it? Lets say: we have interface A Could you explain it? Lets say: we have interface A
now a plugin wants to provide an implementation of interface A now a plugin wants to provide an implementation of interface A
i.e. the client of this plugin would use interface A to access it i.e. the client of this plugin would use interface A to access it
[2008-11-13 01:34:03] <cehteh> in a mail to you i explained that i would like mockup plugins which [2008-11-13 01:34:03] <cehteh> in a mail to you i explained that i would like mockup plugins which
override core functionality override core functionality
[2008-11-13 01:35:07] <ichthyo> so, wouldn't the mockup just be another implementation of interface A ? [2008-11-13 01:35:07] <ichthyo> so, wouldn't the mockup just be another implementation of interface A ?
[2008-11-13 01:35:09] <cehteh> well you query an interface+implementation tuple [2008-11-13 01:35:09] <cehteh> well you query an interface+implementation tuple
[2008-11-13 01:35:35] <cehteh> you cant just open a interface .. you open a implementation of an interface [2008-11-13 01:35:35] <cehteh> you cant just open a interface .. you open a implementation of an interface
@ -714,7 +714,7 @@ from the *support library* (+liblumiera.so+).
[2008-11-13 01:40:32] <cehteh> imagine 2 *.lum modules implement and export exactly the same thing [2008-11-13 01:40:32] <cehteh> imagine 2 *.lum modules implement and export exactly the same thing
(or at least announce it as exactly the same thing) (or at least announce it as exactly the same thing)
[2008-11-13 01:40:57] <ichthyo> I'd just try to relate it to the similar situation with classes [2008-11-13 01:40:57] <ichthyo> I'd just try to relate it to the similar situation with classes
[2008-11-13 01:41:16] <ichthyo> you have an interface and now you have two subclasses [2008-11-13 01:41:16] <ichthyo> you have an interface and now you have two subclasses
[2008-11-13 01:41:12] <cehteh> nah classes are different [2008-11-13 01:41:12] <cehteh> nah classes are different
@ -753,7 +753,7 @@ from the *support library* (+liblumiera.so+).
[2008-11-13 01:48:12] <ichthyo> well... at some point you will be able to tell the loader: [2008-11-13 01:48:12] <ichthyo> well... at some point you will be able to tell the loader:
load this module for use as interface A load this module for use as interface A
[2008-11-13 01:48:20] <cehteh> nah [2008-11-13 01:48:20] <cehteh> nah
[2008-11-13 01:48:37] <cehteh> but you forget that modules != interfaces [2008-11-13 01:48:37] <cehteh> but you forget that modules != interfaces
[2008-11-13 01:49:07] <ichthyo> I understand the modules as being like a "subclass" of the interface [2008-11-13 01:49:07] <ichthyo> I understand the modules as being like a "subclass" of the interface
[2008-11-13 01:49:23] <ichthyo> meaning, each of them can "stand-in" for the interface [2008-11-13 01:49:23] <ichthyo> meaning, each of them can "stand-in" for the interface
[2008-11-13 01:49:18] <cehteh> nope wrong [2008-11-13 01:49:18] <cehteh> nope wrong
@ -767,9 +767,9 @@ from the *support library* (+liblumiera.so+).
[2008-11-13 01:51:00] <ichthyo> but what then is the term for the implementation of an interface? [2008-11-13 01:51:00] <ichthyo> but what then is the term for the implementation of an interface?
[2008-11-13 01:51:08] <ichthyo> because, at an extension point [2008-11-13 01:51:08] <ichthyo> because, at an extension point
[2008-11-13 01:51:21] <ichthyo> you just want to tell: this is the interface to be used at this extension point [2008-11-13 01:51:21] <ichthyo> you just want to tell: this is the interface to be used at this extension point
[2008-11-13 01:51:28] <cehteh> but the module is just a bunch of interfaces .. and module itself doesnt give them a purpose [2008-11-13 01:51:28] <cehteh> but the module is just a bunch of interfaces .. and module itself doesnt give them a purpose
[2008-11-13 01:52:09] <ichthyo> thats clear. Something like the feature bundle could give it a speficic purpose, [2008-11-13 01:52:09] <ichthyo> thats clear. Something like the feature bundle could give it a speficic purpose,
or something similar, which itself is loaded as plugin or something similar, which itself is loaded as plugin
[2008-11-13 01:52:46] <cehteh> modules are just the bucket .. it is pretty unspecified what you put in [2008-11-13 01:52:46] <cehteh> modules are just the bucket .. it is pretty unspecified what you put in
[2008-11-13 01:53:01] <ichthyo> yes thats fine, to start with [2008-11-13 01:53:01] <ichthyo> yes thats fine, to start with
[2008-11-13 01:53:23] <ichthyo> anything more specific can be built on top of such a system [2008-11-13 01:53:23] <ichthyo> anything more specific can be built on top of such a system

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

@ -18,12 +18,12 @@ __Participants__
* Victorsigma * Victorsigma
* pedro * pedro
* thorwil * thorwil
The Lumiera Logo 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: 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.
Recurring Topics Recurring Topics

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

@ -74,14 +74,14 @@ Conclusion
Possible GUI-Integration: Display a frame? 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. 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. 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[] http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=src/common/guifacade.cpp;h=7f781845ad79b4a3e2cd820b96b87f5e702a80d3;hb=8e89506d289f3986af133493a40e3705b7919c87#l64[]
(The thread shall be forked from within the GUI code not from the facade) (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? 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. 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.

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

@ -68,7 +68,7 @@ Point 3: Website
---------------- ----------------
The news in the homepage makes the project look alive. But this is not The news in the homepage makes the project look alive. But this is not
enough to communicate the state of the Lumiera development. Two enough to communicate the state of the Lumiera development. Two
solutions are proposed: solutions are proposed:
* The website needs to be reorganized and made accessible. andrewjames * The website needs to be reorganized and made accessible. andrewjames

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

@ -6,7 +6,7 @@ Lumiera Developers Meeting
March 9, 2011 on +#lumiera+ + March 9, 2011 on +#lumiera+ +
^20:00 GMT - 23:30 GMT^ ^20:00 GMT - 23:30 GMT^
//Menu: label 2011-03-09 //Menu: label 2011-03-09
__Participants__ __Participants__
@ -32,7 +32,7 @@ How do we proceed with the graphical layout?
... ...
21:50 <ichthyo> fsiddi: I liked the way you provided a slightly larger content area 21:50 <ichthyo> fsiddi: I liked the way you provided a slightly larger content area
for the tutorial part 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"] 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"]
image:{img}/meetings/2011-03-09-mockup_dev_2.jpg["Website Proposal Mockup number 2", width=128, link="{img}/meetings/2011-03-09-mockup_dev_2.jpg"] image:{img}/meetings/2011-03-09-mockup_dev_2.jpg["Website Proposal Mockup number 2", width=128, link="{img}/meetings/2011-03-09-mockup_dev_2.jpg"]
@ -157,7 +157,7 @@ Hermann has written an rfc for version numbers.
23:30 <ichthyo> also, it is more in line with the "extreme programming" style 23:30 <ichthyo> also, it is more in line with the "extreme programming" style
23:30 <ichthyo> i.e. don't do too disruptive changes 23:30 <ichthyo> i.e. don't do too disruptive changes
23:30 <cehteh> if you want 'pre' or 'rc' 23:30 <cehteh> if you want 'pre' or 'rc'
23:30 <ichthyo> but rather refactor often 23:30 <ichthyo> but rather refactor often
23:30 <skangas_> OK. 23:30 <skangas_> OK.
23:31 <ichthyo> there is onre concern though 23:31 <ichthyo> there is onre concern though
23:31 <ichthyo> there *needs* to be some stability then 23:31 <ichthyo> there *needs* to be some stability then
@ -199,7 +199,7 @@ Hermann has written an rfc for version numbers.
23:27 <cehteh> (eventually or maybe we might even put tests/bugs there which prevent 23:27 <cehteh> (eventually or maybe we might even put tests/bugs there which prevent
certain staging actions, finally all integration and complete releases certain staging actions, finally all integration and complete releases
could be automatized) could be automatized)
23:26 <cehteh> remember in test.sh i reserved the 90-99* area for 'bugs' 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 23:26 <cehteh> we may put some blocking tests there which prevent staging
Next meeting Next meeting

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

@ -115,7 +115,7 @@ using a »liquid layout«?
[2011-04-13 23:14:08] <ichthyo> so I draw the conclusion, that the documentation pages are optimised for much content [2011-04-13 23:14:08] <ichthyo> so I draw the conclusion, that the documentation pages are optimised for much content
[2011-04-13 23:14:19] <fsiddi> yes [2011-04-13 23:14:19] <fsiddi> yes
[2011-04-13 23:13:30] <cehteh> ok .. settled [2011-04-13 23:13:30] <cehteh> ok .. settled
... ...
[2011-04-13 23:13:54] <fsiddi> i propose to keep the layout not liquid also in that pages [2011-04-13 23:13:54] <fsiddi> i propose to keep the layout not liquid also in that pages
[2011-04-13 23:14:35] <fsiddi> if you prefer i can make them larger [2011-04-13 23:14:35] <fsiddi> if you prefer i can make them larger
[2011-04-13 23:14:49] <fsiddi> but for the moment i'd like to keep the same width [2011-04-13 23:14:49] <fsiddi> but for the moment i'd like to keep the same width
@ -164,7 +164,7 @@ Colour scheme
[caption="☉Transcript☉ "] [caption="☉Transcript☉ "]
---------------------------- ----------------------------
[2011-04-13 23:28:23] <ichthyo> I'd like to bring up the question regarding color [2011-04-13 23:28:23] <ichthyo> I'd like to bring up the question regarding color
[2011-04-13 23:28:36] <ichthyo> and I'll ask especially you, fsiddi [2011-04-13 23:28:36] <ichthyo> and I'll ask especially you, fsiddi
[2011-04-13 23:28:44] <ichthyo> you know, colours are a matter of taste [2011-04-13 23:28:44] <ichthyo> you know, colours are a matter of taste
[2011-04-13 23:29:15] <ichthyo> thus I'd say, as you did the general layout, you have an important say in that [2011-04-13 23:29:15] <ichthyo> thus I'd say, as you did the general layout, you have an important say in that
[2011-04-13 23:28:59] <fsiddi> ah yes colors [2011-04-13 23:28:59] <fsiddi> ah yes colors
@ -298,7 +298,7 @@ Website licensing and legal questions
[2011-04-14 00:11:42] <cehteh> anyeays ... dual license gpl and cc-by-sa [2011-04-14 00:11:42] <cehteh> anyeays ... dual license gpl and cc-by-sa
[2011-04-14 00:11:46] <cehteh> ok for me [2011-04-14 00:11:46] <cehteh> ok for me
[2011-04-14 00:11:55] <ichthyo> fine, seems case is settled [2011-04-14 00:11:55] <ichthyo> fine, seems case is settled
[2011-04-14 00:12:04] <cehteh> eh which gpl ? gpl2+ .. same as lumiera [2011-04-14 00:12:04] <cehteh> eh which gpl ? gpl2+ .. same as lumiera
[2011-04-14 00:12:08] <ichthyo> yes [2011-04-14 00:12:08] <ichthyo> yes
[2011-04-14 00:12:15] <ichthyo> thats important [2011-04-14 00:12:15] <ichthyo> thats important
[2011-04-14 00:12:32] <cehteh> and we may bump lumiera to gplv3 when we release it (and we know all its dependencies) [2011-04-14 00:12:32] <cehteh> and we may bump lumiera to gplv3 when we release it (and we know all its dependencies)
@ -333,7 +333,7 @@ actually repackaging a current version into an pre-release debian package, as th
official debian package isn't on the required level). After a bit of training, official debian package isn't on the required level). After a bit of training,
the Bayesian filter successfully blocked any further spam tickets. the Bayesian filter successfully blocked any further spam tickets.
The remaining problem are spam user accounts though. To deal with that problem, _Ichthyo_ The remaining problem are spam user accounts though. To deal with that problem, _Ichthyo_
designed a custom SQL query based on some obvious heuristics, which seems to pinpoint designed a custom SQL query based on some obvious heuristics, which seems to pinpoint
all spurious accounts. We'll try to execute that SQL for some time manually, and -- all spurious accounts. We'll try to execute that SQL for some time manually, and --
in case it behaves sane -- automate that cleanup as a cronjob in some months. in case it behaves sane -- automate that cleanup as a cronjob in some months.
@ -362,7 +362,7 @@ revisit the relevant design process entries in each developer meeting.
[2011-04-14 00:50:25] <cehteh> maybe we want another state "accepted" .. [2011-04-14 00:50:25] <cehteh> maybe we want another state "accepted" ..
[2011-04-14 00:50:44] <cehteh> that is the interesting things which we know we will not drop but which are not finalized yet [2011-04-14 00:50:44] <cehteh> that is the interesting things which we know we will not drop but which are not finalized yet
[2011-04-14 00:54:29] <cehteh> the application install came first... we need it, you did it well .. it could be 'finalized' or [2011-04-14 00:54:29] <cehteh> the application install came first... we need it, you did it well .. it could be 'finalized' or
rather that would be some 'acceepted' candidate .. rather that would be some 'acceepted' candidate ..
[2011-04-14 00:53:25] <ichthyo> I think, the existing states are enough [2011-04-14 00:53:25] <ichthyo> I think, the existing states are enough
[2011-04-14 00:53:44] <ichthyo> either really discuss something and then decide, or just leave it in draft [2011-04-14 00:53:44] <ichthyo> either really discuss something and then decide, or just leave it in draft
[2011-04-14 00:54:05] <ichthyo> lets just postpone the application install and leave it in draft! [2011-04-14 00:54:05] <ichthyo> lets just postpone the application install and leave it in draft!
@ -502,7 +502,7 @@ That's rather final by now. This link:{rfc}/ProcHighLevelModel.html[proposal]
meanwhile documents the existing design; it's up to date and didn't see significant meanwhile documents the existing design; it's up to date and didn't see significant
additions since almost two years. Generally agreed upon, so it's _final_ now. additions since almost two years. Generally agreed upon, so it's _final_ now.
The same holds true for the The same holds true for the
link:{rfc}/ProcPlacementMetaphor.html[Placement] proposal link:{rfc}/ProcPlacementMetaphor.html[Placement] proposal
@ -519,14 +519,14 @@ Render Optimizer, Resource Management and Profiling
[2011-04-14 01:18:02] <ichthyo> so, maybe just polish a bit [2011-04-14 01:18:02] <ichthyo> so, maybe just polish a bit
[2011-04-14 01:18:18] <cehteh> yes park because it needs some polishing before final [2011-04-14 01:18:18] <cehteh> yes park because it needs some polishing before final
[2011-04-14 01:18:24] <ichthyo> (remove the "pro and con") and then we could accept it right away [2011-04-14 01:18:24] <ichthyo> (remove the "pro and con") and then we could accept it right away
[2011-04-14 01:18:28] <cehteh> i can put a note that its basically accepted [2011-04-14 01:18:28] <cehteh> i can put a note that its basically accepted
[2011-04-14 01:18:38] <cehteh> parking isnt neccessary bad :P [2011-04-14 01:18:38] <cehteh> parking isnt neccessary bad :P
[2011-04-14 01:18:46] <ichthyo> ResourceManagement [2011-04-14 01:18:46] <ichthyo> ResourceManagement
[2011-04-14 01:18:49] <cehteh> (well again that would be a 'accept' candidate) [2011-04-14 01:18:49] <cehteh> (well again that would be a 'accept' candidate)
[2011-04-14 01:18:53] <ichthyo> needs some more work [2011-04-14 01:18:53] <ichthyo> needs some more work
[2011-04-14 01:19:01] <cehteh> that are 2 things .. yes [2011-04-14 01:19:01] <cehteh> that are 2 things .. yes
[2011-04-14 01:19:10] <cehteh> profiling and budgeting .. [2011-04-14 01:19:10] <cehteh> profiling and budgeting ..
[2011-04-14 01:19:21] <cehteh> i think i will implement them and then see how it works [2011-04-14 01:19:21] <cehteh> i think i will implement them and then see how it works
[2011-04-14 01:19:40] <cehteh> (unless someone else shows better alternatives) [2011-04-14 01:19:40] <cehteh> (unless someone else shows better alternatives)
[2011-04-14 01:19:47] <ichthyo> if you change that and e.g. remove the code sample and make it really short and high level, [2011-04-14 01:19:47] <ichthyo> if you change that and e.g. remove the code sample and make it really short and high level,
@ -555,7 +555,7 @@ Stream Type System
[caption="☉Transcript☉ "] [caption="☉Transcript☉ "]
---------------------------- ----------------------------
[2011-04-14 01:24:06] <ichthyo> very important for me -- my vote is for accept [2011-04-14 01:24:06] <ichthyo> very important for me -- my vote is for accept
[2011-04-14 01:24:16] <cehteh> we had some discussion how to maintain metadata .. [2011-04-14 01:24:16] <cehteh> we had some discussion how to maintain metadata ..
[2011-04-14 01:24:40] <cehteh> i vote for accept too but this metadata (which may decribe the type) needs work [2011-04-14 01:24:40] <cehteh> i vote for accept too but this metadata (which may decribe the type) needs work
[2011-04-14 01:24:49] <ichthyo> well, this one is really a heavyweight conceptual RfC [2011-04-14 01:24:49] <ichthyo> well, this one is really a heavyweight conceptual RfC
[2011-04-14 01:25:00] <ichthyo> it is not about *how* to maintain metadata [2011-04-14 01:25:00] <ichthyo> it is not about *how* to maintain metadata
@ -567,7 +567,7 @@ Stream Type System
[2011-04-14 01:26:36] <ichthyo> but well, at the moment I am the only one thinking into more details of this whole topic [2011-04-14 01:26:36] <ichthyo> but well, at the moment I am the only one thinking into more details of this whole topic
[2011-04-14 01:26:24] <cehteh> shall i leave it pending just to nag us? [2011-04-14 01:26:24] <cehteh> shall i leave it pending just to nag us?
[2011-04-14 01:26:50] <ichthyo> yes, leave it pending [2011-04-14 01:26:50] <ichthyo> yes, leave it pending
[2011-04-14 01:27:10] <cehteh> i was thinking too about this .. but not consistently ... [2011-04-14 01:27:10] <cehteh> i was thinking too about this .. but not consistently ...
[2011-04-14 01:27:24] <ichthyo> as said, I vote for accept, but I would really ask you to think it over [2011-04-14 01:27:24] <ichthyo> as said, I vote for accept, but I would really ask you to think it over
[2011-04-14 01:27:38] <cehteh> i think that needs some time to settle to the right point [tm] [2011-04-14 01:27:38] <cehteh> i think that needs some time to settle to the right point [tm]
[2011-04-14 01:27:43] <ichthyo> I'm not right away implementing it, but the implementation is rather trivial [2011-04-14 01:27:43] <ichthyo> I'm not right away implementing it, but the implementation is rather trivial
@ -597,7 +597,7 @@ Threads Signals and important management tasks
[2011-04-14 01:31:39] <cehteh> not only starting and shutdown but also control the direction [2011-04-14 01:31:39] <cehteh> not only starting and shutdown but also control the direction
[2011-04-14 01:32:08] <cehteh> but really this isnt much a difference, if you want an extra thread then let it be so [2011-04-14 01:32:08] <cehteh> but really this isnt much a difference, if you want an extra thread then let it be so
[2011-04-14 01:32:46] <ichthyo> I see the code complexity. It would just look okish for me if we split it into these two [2011-04-14 01:32:46] <ichthyo> I see the code complexity. It would just look okish for me if we split it into these two
[2011-04-14 01:33:26] <cehteh> there is not much complexity, the main thread waits currently .. [2011-04-14 01:33:26] <cehteh> there is not much complexity, the main thread waits currently ..
[2011-04-14 01:34:02] <cehteh> and it can get woken by signals or condvar (convars return when a signal arrives) [2011-04-14 01:34:02] <cehteh> and it can get woken by signals or condvar (convars return when a signal arrives)
[2011-04-14 01:34:29] <cehteh> actually having an extra thread wont make the code simpler because then the main thread [2011-04-14 01:34:29] <cehteh> actually having an extra thread wont make the code simpler because then the main thread
needs to be rigged to ignore the signals. All other threads are created by us and can needs to be rigged to ignore the signals. All other threads are created by us and can

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

@ -10,7 +10,7 @@ __Participants__
* cehteh * cehteh
* ichthyo * ichthyo
* daylife * daylife
_Transcript prepared by Ichthyo_ _Transcript prepared by Ichthyo_
@ -84,7 +84,7 @@ IRC Transcript
.-- Engine Interface ⟺ Scheduler Interface -- .-- Engine Interface ⟺ Scheduler Interface --
[caption="☉Transcript☉ "] [caption="☉Transcript☉ "]
---------------------------- ----------------------------
[2011-05-11 22:08:54] <cehteh> ichthyo: how do we want to proceed with the engine interface, [2011-05-11 22:08:54] <cehteh> ichthyo: how do we want to proceed with the engine interface,
discuss it point by point or only a overview and edit comments in the rfc? discuss it point by point or only a overview and edit comments in the rfc?
[2011-05-11 22:09:08] <ichthyo> well I thought rather the latter...its a rough draft [2011-05-11 22:09:08] <ichthyo> well I thought rather the latter...its a rough draft
[2011-05-11 22:10:52] <cehteh> well generally i agree with your proposal (i'm just reading it) [2011-05-11 22:10:52] <cehteh> well generally i agree with your proposal (i'm just reading it)
@ -95,7 +95,7 @@ IRC Transcript
[2011-05-11 22:13:20] <cehteh> well your proposal sounded like constants (to be defined) [2011-05-11 22:13:20] <cehteh> well your proposal sounded like constants (to be defined)
[2011-05-11 22:13:35] <ichthyo> yes, its constants, but it seems natural to extend that [2011-05-11 22:13:35] <ichthyo> yes, its constants, but it seems natural to extend that
[2011-05-11 22:13:47] <cehteh> i think about a functor or even a trait-class where you can query things [2011-05-11 22:13:47] <cehteh> i think about a functor or even a trait-class where you can query things
[2011-05-11 22:14:19] <cehteh> this class can then react more dynamic [2011-05-11 22:14:19] <cehteh> this class can then react more dynamic
[2011-05-11 22:14:22] <ichthyo> ok, yes, so that you could e.g. combine several independent degrees of freedom [2011-05-11 22:14:22] <ichthyo> ok, yes, so that you could e.g. combine several independent degrees of freedom
[2011-05-11 22:14:31] <cehteh> yes [2011-05-11 22:14:31] <cehteh> yes
[2011-05-11 22:16:02] <cehteh> then we can ask precisely "shall we render this frame now?"... [2011-05-11 22:16:02] <cehteh> then we can ask precisely "shall we render this frame now?"...
@ -134,7 +134,7 @@ IRC Transcript
---------------------------- ----------------------------
[2011-05-11 22:22:49] <ichthyo> e.g think about the following scenario: [2011-05-11 22:22:49] <ichthyo> e.g think about the following scenario:
[2011-05-11 22:23:06] <ichthyo> we're in the middle of playing, and now we want to switch to double speed playback [2011-05-11 22:23:06] <ichthyo> we're in the middle of playing, and now we want to switch to double speed playback
[2011-05-11 22:23:39] <cehteh> yes then the player cancels every other frame job and changes its timebase [2011-05-11 22:23:39] <cehteh> yes then the player cancels every other frame job and changes its timebase
[2011-05-11 22:23:56] <cehteh> or instead canceling it could put them on a lower priority [2011-05-11 22:23:56] <cehteh> or instead canceling it could put them on a lower priority
[2011-05-11 22:24:01] <ichthyo> that means, the player/scheduler/whatever needs to find out a point in time, [2011-05-11 22:24:01] <ichthyo> that means, the player/scheduler/whatever needs to find out a point in time,
*when* this switch can be performed *when* this switch can be performed
@ -178,7 +178,7 @@ IRC Transcript
[2011-05-11 22:35:14] <cehteh> then rescheduling automatically walks all dependencies, reschedules them too [2011-05-11 22:35:14] <cehteh> then rescheduling automatically walks all dependencies, reschedules them too
and by that it can already see if we can met timing constraints and by that it can already see if we can met timing constraints
[2011-05-11 22:36:37] <cehteh> the 'reschedule' can answer if rescheduling is possible [2011-05-11 22:36:37] <cehteh> the 'reschedule' can answer if rescheduling is possible
[2011-05-11 22:37:07] <cehteh> so you just iterate over all frame-job to be rescheduled from shortest to longest time [2011-05-11 22:37:07] <cehteh> so you just iterate over all frame-job to be rescheduled from shortest to longest time
[2011-05-11 22:37:36] <cehteh> the most urgend reschedules may return "hey this job is already running, cant reschedule" [2011-05-11 22:37:36] <cehteh> the most urgend reschedules may return "hey this job is already running, cant reschedule"
[2011-05-11 22:37:49] <cehteh> or even "already done, nothing to do" [2011-05-11 22:37:49] <cehteh> or even "already done, nothing to do"
[2011-05-11 22:38:03] <cehteh> to "sorry, cant do that dave" [2011-05-11 22:38:03] <cehteh> to "sorry, cant do that dave"
@ -227,16 +227,16 @@ IRC Transcript
[2011-05-11 22:52:09] <cehteh> nah not only reference data i am really thinking that jobs have absolutely [2011-05-11 22:52:09] <cehteh> nah not only reference data i am really thinking that jobs have absolutely
no references into the session no references into the session
[2011-05-11 22:52:18] <cehteh> they have references into the backend data [2011-05-11 22:52:18] <cehteh> they have references into the backend data
[2011-05-11 22:52:23] <cehteh> but these are managed there [2011-05-11 22:52:23] <cehteh> but these are managed there
[2011-05-11 22:52:37] <cehteh> while closing a session doesnt require to shutdown the backend [2011-05-11 22:52:37] <cehteh> while closing a session doesnt require to shutdown the backend
[2011-05-11 22:53:01] <ichthyo> well, so to clarify that: there *is* some kind of back reference for sure. [2011-05-11 22:53:01] <ichthyo> well, so to clarify that: there *is* some kind of back reference for sure.
Just it isn't direct. See for example: a job references an exit node Just it isn't direct. See for example: a job references an exit node
[2011-05-11 22:53:35] <ichthyo> and it references an output slot [2011-05-11 22:53:35] <ichthyo> and it references an output slot
[2011-05-11 22:53:38] <cehteh> really? [2011-05-11 22:53:38] <cehteh> really?
[2011-05-11 22:53:47] <cehteh> how about a functor there [2011-05-11 22:53:47] <cehteh> how about a functor there
[2011-05-11 22:53:50] <ichthyo> both are things which are somehow allocated from the session [2011-05-11 22:53:50] <ichthyo> both are things which are somehow allocated from the session
[2011-05-11 22:53:55] <cehteh> jobs references a continutation job [2011-05-11 22:53:55] <cehteh> jobs references a continutation job
[2011-05-11 22:54:16] <cehteh> which is an abstraction of the exit node [2011-05-11 22:54:16] <cehteh> which is an abstraction of the exit node
[2011-05-11 22:54:36] <cehteh> well anyways .. the callback *is* trivially possible [2011-05-11 22:54:36] <cehteh> well anyways .. the callback *is* trivially possible
[2011-05-11 22:54:48] <cehteh> but do not expect that i want to do rescheduling for aborting jobs [2011-05-11 22:54:48] <cehteh> but do not expect that i want to do rescheduling for aborting jobs
[2011-05-11 22:55:30] <ichthyo> well... as said: jobs can't be aborted [2011-05-11 22:55:30] <ichthyo> well... as said: jobs can't be aborted
@ -360,7 +360,7 @@ IRC Transcript
(and later easily adaptable/extendable to new technologies) (and later easily adaptable/extendable to new technologies)
[2011-05-11 23:32:01] <ichthyo> I'd rather doubt that. In all those cases, we're using already existing [2011-05-11 23:32:01] <ichthyo> I'd rather doubt that. In all those cases, we're using already existing
libraries and solutions. and we're rather integrating with them libraries and solutions. and we're rather integrating with them
[2011-05-11 23:32:23] <cehteh> yes so there is no much effort doing so .. [2011-05-11 23:32:23] <cehteh> yes so there is no much effort doing so ..
[2011-05-11 23:32:54] <ichthyo> that extends even more to the media libs, we're intend to use [2011-05-11 23:32:54] <ichthyo> that extends even more to the media libs, we're intend to use
[2011-05-11 23:32:55] <cehteh> but since the backend always knows what memory is in use it can do a clean shutdown [2011-05-11 23:32:55] <cehteh> but since the backend always knows what memory is in use it can do a clean shutdown
[2011-05-11 23:33:18] <cehteh> without all this callbacks and asyncronous messages [2011-05-11 23:33:18] <cehteh> without all this callbacks and asyncronous messages
@ -395,7 +395,7 @@ IRC Transcript
[2011-05-11 23:44:51] <ichthyo> do our jobs have some mechanism to 'yield' or wait or similar? [2011-05-11 23:44:51] <ichthyo> do our jobs have some mechanism to 'yield' or wait or similar?
[2011-05-11 23:45:10] <ichthyo> i.e. go in a wait state (and make room for other jobs to be scheduled meanwhile)? [2011-05-11 23:45:10] <ichthyo> i.e. go in a wait state (and make room for other jobs to be scheduled meanwhile)?
[2011-05-11 23:45:34] <cehteh> waiting on other jobs [2011-05-11 23:45:34] <cehteh> waiting on other jobs
[2011-05-11 23:45:49] <cehteh> i am thinking if i make a generic waiting or only on jobs [2011-05-11 23:45:49] <cehteh> i am thinking if i make a generic waiting or only on jobs
[2011-05-11 23:45:54] <ichthyo> so you call into a funciton on the lumiera scheduler [2011-05-11 23:45:54] <ichthyo> so you call into a funciton on the lumiera scheduler
[2011-05-11 23:45:55] <cehteh> i think only on jobs is good [2011-05-11 23:45:55] <cehteh> i think only on jobs is good
[2011-05-11 23:46:06] <ichthyo> which blocks and reschedules other jobs meanwhile? [2011-05-11 23:46:06] <ichthyo> which blocks and reschedules other jobs meanwhile?
@ -403,15 +403,15 @@ IRC Transcript
[2011-05-11 23:46:34] <ichthyo> just brainstorming [2011-05-11 23:46:34] <ichthyo> just brainstorming
[2011-05-11 23:46:45] <ichthyo> both is thinkable [2011-05-11 23:46:45] <ichthyo> both is thinkable
[2011-05-11 23:46:56] <ichthyo> also it would be thinkable that we disallow any waits [2011-05-11 23:46:56] <ichthyo> also it would be thinkable that we disallow any waits
[2011-05-11 23:47:03] <cehteh> nope i do not want that, rather split the jobs up into small pieces [2011-05-11 23:47:03] <cehteh> nope i do not want that, rather split the jobs up into small pieces
[2011-05-11 23:47:13] <ichthyo> and just say, then the job function has to terminate and another job has to pick up [2011-05-11 23:47:13] <ichthyo> and just say, then the job function has to terminate and another job has to pick up
[2011-05-11 23:47:27] <cehteh> yes thats possible [2011-05-11 23:47:27] <cehteh> yes thats possible
[2011-05-11 23:48:00] <cehteh> but when a job runs it runs until its done (which might be a errorneous/abort on its own) [2011-05-11 23:48:00] <cehteh> but when a job runs it runs until its done (which might be a errorneous/abort on its own)
[2011-05-11 23:48:20] <cehteh> after running a job wont become rescheduled [2011-05-11 23:48:20] <cehteh> after running a job wont become rescheduled
[2011-05-11 23:48:49] <cehteh> if it turns out we need a yield i could implement it .. but not prematurely [2011-05-11 23:48:49] <cehteh> if it turns out we need a yield i could implement it .. but not prematurely
[2011-05-11 23:49:44] <ichthyo> but likely for our purposes we don't even need that [2011-05-11 23:49:44] <ichthyo> but likely for our purposes we don't even need that
[2011-05-11 23:50:16] <cehteh> yes and thats not domain of the scheduler [2011-05-11 23:50:16] <cehteh> yes and thats not domain of the scheduler
[2011-05-11 23:50:32] <cehteh> jobs can block anyways [2011-05-11 23:50:32] <cehteh> jobs can block anyways
[2011-05-11 23:50:40] <cehteh> in running state [2011-05-11 23:50:40] <cehteh> in running state
[2011-05-11 23:50:53] <cehteh> no need to put them on a wait queue or whatever [2011-05-11 23:50:53] <cehteh> no need to put them on a wait queue or whatever
[2011-05-11 23:51:31] <ichthyo> but of course the goal is to write them such that they don't block [2011-05-11 23:51:31] <ichthyo> but of course the goal is to write them such that they don't block
@ -445,8 +445,8 @@ IRC Transcript
[2011-05-12 00:02:59] <ichthyo> the engine interface needs something like these calculation streams [2011-05-12 00:02:59] <ichthyo> the engine interface needs something like these calculation streams
[2011-05-12 00:03:19] <ichthyo> that means, that the individual job needs to cary a marker, so it can be associated [2011-05-12 00:03:19] <ichthyo> that means, that the individual job needs to cary a marker, so it can be associated
to a specific stream to a specific stream
[2011-05-12 00:02:59] <cehteh> first, asking the backend for a frame [2011-05-12 00:02:59] <cehteh> first, asking the backend for a frame
[2011-05-12 00:03:58] <cehteh> i add at least one generic void* to the job where you can put any data along [2011-05-12 00:03:58] <cehteh> i add at least one generic void* to the job where you can put any data along
[2011-05-12 00:04:12] <cehteh> type safety on the level above please :P [2011-05-12 00:04:12] <cehteh> type safety on the level above please :P
[2011-05-12 00:05:20] <ichthyo> I'm fine with that [2011-05-12 00:05:20] <ichthyo> I'm fine with that
[2011-05-12 00:05:27] <cehteh> (caveat about the lifetime and ownership of this void*) [2011-05-12 00:05:27] <cehteh> (caveat about the lifetime and ownership of this void*)
@ -455,7 +455,7 @@ IRC Transcript
(...) (...)
[2011-05-12 00:10:44] <cehteh> next would be a interface how to setup a job... possibly in multiple stages [2011-05-12 00:10:44] <cehteh> next would be a interface how to setup a job... possibly in multiple stages
[2011-05-12 00:11:59] <cehteh> job_new(); job_wait_for(another_job); job_data()=some_calculation_stream; [2011-05-12 00:11:59] <cehteh> job_new(); job_wait_for(another_job); job_data()=some_calculation_stream;
[2011-05-12 00:12:06] <cehteh> job_arm() [2011-05-12 00:12:06] <cehteh> job_arm()
[2011-05-12 00:12:14] <cehteh> something like that [2011-05-12 00:12:14] <cehteh> something like that
[2011-05-12 00:12:38] <ichthyo> sounds ok [2011-05-12 00:12:38] <ichthyo> sounds ok
@ -472,7 +472,7 @@ IRC Transcript
[2011-05-12 00:15:04] <ichthyo> really? [2011-05-12 00:15:04] <ichthyo> really?
[2011-05-12 00:15:11] <cehteh> i wonder -- makes sense or? [2011-05-12 00:15:11] <cehteh> i wonder -- makes sense or?
[2011-05-12 00:15:38] <ichthyo> *could* be done, but somehow goes against that simplicity [2011-05-12 00:15:38] <ichthyo> *could* be done, but somehow goes against that simplicity
[2011-05-12 00:15:53] <cehteh> I mean each of this class shares a lot, how abortion is handled and more [2011-05-12 00:15:53] <cehteh> I mean each of this class shares a lot, how abortion is handled and more
[2011-05-12 00:16:43] <cehteh> Ok on the low level you can always put a job together with all the little [2011-05-12 00:16:43] <cehteh> Ok on the low level you can always put a job together with all the little
details needed and then arm it. I expect that we have maybe half a dozen classes of jobs details needed and then arm it. I expect that we have maybe half a dozen classes of jobs
[2011-05-12 00:17:03] <ichthyo> not only on the low level. That would also be the correct OO aproach [2011-05-12 00:17:03] <ichthyo> not only on the low level. That would also be the correct OO aproach
@ -529,17 +529,17 @@ IRC Transcript
[2011-05-12 00:24:18] <cehteh> this 'timer' possibly wont be singleton too .. you can play unrelated things in parallel [2011-05-12 00:24:18] <cehteh> this 'timer' possibly wont be singleton too .. you can play unrelated things in parallel
[2011-05-12 00:24:51] <ichthyo> well... I'd rather expect that to be quite similar to the jobs [2011-05-12 00:24:51] <ichthyo> well... I'd rather expect that to be quite similar to the jobs
[2011-05-12 00:25:26] <cehteh> well i wonder if the normal jobs become bit more heavyweight [2011-05-12 00:25:26] <cehteh> well i wonder if the normal jobs become bit more heavyweight
[2011-05-12 00:25:40] <cehteh> and the high prio queue gets its own interface [2011-05-12 00:25:40] <cehteh> and the high prio queue gets its own interface
[2011-05-12 00:26:00] <cehteh> no full blown jobs, no waiting (inter-jobs) [2011-05-12 00:26:00] <cehteh> no full blown jobs, no waiting (inter-jobs)
[2011-05-12 00:26:10] <ichthyo> what do you think to add to the normal jobs, beyond what we just discussed? [2011-05-12 00:26:10] <ichthyo> what do you think to add to the normal jobs, beyond what we just discussed?
[2011-05-12 00:26:15] <ichthyo> ah maybe the dependencies [2011-05-12 00:26:15] <ichthyo> ah maybe the dependencies
[2011-05-12 00:26:23] <ichthyo> but besides that? [2011-05-12 00:26:23] <ichthyo> but besides that?
[2011-05-12 00:29:03] <cehteh> so there will be the full blown jobs [2011-05-12 00:29:03] <cehteh> so there will be the full blown jobs
[2011-05-12 00:29:27] <cehteh> which can record dependencies on other jobs, have their state, a jobfunction [2011-05-12 00:29:27] <cehteh> which can record dependencies on other jobs, have their state, a jobfunction
(...) (...)
[2011-05-12 00:34:00] <cehteh> the exact setup for scheduling will likely become little more complicated [2011-05-12 00:34:00] <cehteh> the exact setup for scheduling will likely become little more complicated
[2011-05-12 00:34:46] <cehteh> you dont just set a time when to render but timespans and priorities, [2011-05-12 00:34:46] <cehteh> you dont just set a time when to render but timespans and priorities,
possibly twice for each queue -- at least my plan is that a job can be in the possibly twice for each queue -- at least my plan is that a job can be in the
background render queue and in the high prio queue (we should give this a better name) at once background render queue and in the high prio queue (we should give this a better name) at once
@ -595,7 +595,7 @@ IRC Transcript
[2011-05-12 00:58:46] <cehteh> and depend on backend/proc [2011-05-12 00:58:46] <cehteh> and depend on backend/proc
[2011-05-12 00:59:16] <ichthyo> anyway... that means that there might be thumbnails to process, and I take it that we [2011-05-12 00:59:16] <ichthyo> anyway... that means that there might be thumbnails to process, and I take it that we
handle that somehow through our engine as well, just with lower priority handle that somehow through our engine as well, just with lower priority
[2011-05-12 00:59:23] <cehteh> yes that costs a lot performance there .. [2011-05-12 00:59:23] <cehteh> yes that costs a lot performance there ..
[2011-05-12 01:00:01] <ichthyo> as a *user* I really don't know what to prefer [2011-05-12 01:00:01] <ichthyo> as a *user* I really don't know what to prefer
[2011-05-12 01:00:10] <cehteh> btw if frames or thumbnails have higher priority might be a feature of 'perspectives' [2011-05-12 01:00:10] <cehteh> btw if frames or thumbnails have higher priority might be a feature of 'perspectives'
[2011-05-12 01:00:24] <ichthyo> an application which burns quite some resources, but gets me a steady updating display [2011-05-12 01:00:24] <ichthyo> an application which burns quite some resources, but gets me a steady updating display
@ -650,7 +650,7 @@ IRC Transcript
[2011-05-12 01:14:46] <cehteh> the 'actual' interfaces how the backend queries a frame from proc and how proc [2011-05-12 01:14:46] <cehteh> the 'actual' interfaces how the backend queries a frame from proc and how proc
asks the backend for a frame .. do we need to work this out? asks the backend for a frame .. do we need to work this out?
But i think about not working it offically out at all in a big way, But i think about not working it offically out at all in a big way,
this interfaces prolly just happen and can be improved in small details this interfaces prolly just happen and can be improved in small details
[2011-05-12 01:16:10] <ichthyo> in the (half finished) code in the ProcNode, I used placeholder / facade interfaces [2011-05-12 01:16:10] <ichthyo> in the (half finished) code in the ProcNode, I used placeholder / facade interfaces
[2011-05-12 01:16:21] <ichthyo> that is enough to set up the backbone [2011-05-12 01:16:21] <ichthyo> that is enough to set up the backbone
[2011-05-12 01:16:52] <ichthyo> that is, for node -> backend (to get a frame) [2011-05-12 01:16:52] <ichthyo> that is, for node -> backend (to get a frame)
@ -660,7 +660,7 @@ IRC Transcript
[2011-05-12 01:17:50] <ichthyo> "node invocation interface" [2011-05-12 01:17:50] <ichthyo> "node invocation interface"
[2011-05-12 01:18:22] <ichthyo> well, personally I think I'll first concentrate on the player, to get a rough outline there [2011-05-12 01:18:22] <ichthyo> well, personally I think I'll first concentrate on the player, to get a rough outline there
[2011-05-12 01:18:36] <cehteh> yes that will show us the requirements [2011-05-12 01:18:36] <cehteh> yes that will show us the requirements
[2011-05-12 01:19:15] <ichthyo> and if I recall right, you were rather engaged into the framecache / frame database [2011-05-12 01:19:15] <ichthyo> and if I recall right, you were rather engaged into the framecache / frame database
[2011-05-12 01:20:10] <cehteh> the general interface is simple (in my head) .. but there are some dirty corners to worked out [2011-05-12 01:20:10] <cehteh> the general interface is simple (in my head) .. but there are some dirty corners to worked out
(...) (...)
@ -691,13 +691,13 @@ IRC Transcript
[2011-05-12 01:30:27] <ichthyo> yes... that was kind of the middle ground we agreed on [2011-05-12 01:30:27] <ichthyo> yes... that was kind of the middle ground we agreed on
[2011-05-12 01:31:10] <ichthyo> I retained the possibility to decide if and where a chain of calculations for a single [2011-05-12 01:31:10] <ichthyo> I retained the possibility to decide if and where a chain of calculations for a single
frame should be split and scheduled as separate jobs frame should be split and scheduled as separate jobs
[2011-05-12 01:31:24] <cehteh> ah [2011-05-12 01:31:24] <cehteh> ah
[2011-05-12 01:34:15] <cehteh> run only the heavy lifting in single jobs [2011-05-12 01:34:15] <cehteh> run only the heavy lifting in single jobs
[2011-05-12 01:34:38] <ichthyo> I allways assume that 1 frame is one job [2011-05-12 01:34:38] <ichthyo> I allways assume that 1 frame is one job
[2011-05-12 01:34:40] <ichthyo> at least [2011-05-12 01:34:40] <ichthyo> at least
[2011-05-12 01:34:53] <cehteh> well refine 'rendering one frame is one job' [2011-05-12 01:34:53] <cehteh> well refine 'rendering one frame is one job'
[2011-05-12 01:35:02] <ichthyo> the controversy was to what extend a single frame should be split into multiple jobs [2011-05-12 01:35:02] <ichthyo> the controversy was to what extend a single frame should be split into multiple jobs
[2011-05-12 01:35:10] <cehteh> i dont care if discovery over a sequence is one job for multiple frames [2011-05-12 01:35:10] <cehteh> i dont care if discovery over a sequence is one job for multiple frames
[2011-05-12 01:36:54] <ichthyo> at that point (more than a year ago), you insisted that every calculation [2011-05-12 01:36:54] <ichthyo> at that point (more than a year ago), you insisted that every calculation
be done in a separate job, and I didn't agree to that be done in a separate job, and I didn't agree to that
[2011-05-12 01:37:00] <cehteh> yes [2011-05-12 01:37:00] <cehteh> yes

2
doc/devel/meeting_summary/2012-01-11.txt
View file

@ -29,7 +29,7 @@ Conclusions
. _benny_ and _ichthyo_ follow up on the . _benny_ and _ichthyo_ follow up on the
link:http://libregraphicsmag.com/[Libre Graphics Magazine]'s offer to promote link:http://libregraphicsmag.com/[Libre Graphics Magazine]'s offer to promote
graphics and media projects and try to get into discussion with them and see graphics and media projects and try to get into discussion with them and see
what can be done within our limited time. what can be done within our limited time.
. when it comes to have a working example for media file output, we stick to the . when it comes to have a working example for media file output, we stick to the
mainstream solutions *ffmpeg* and or *gstreamer*, but care not to lock ourselves mainstream solutions *ffmpeg* and or *gstreamer*, but care not to lock ourselves
into a single solution. Concluded that we do this over plugin interfaces -- into a single solution. Concluded that we do this over plugin interfaces --

6
doc/devel/meeting_summary/2012-10-11.txt
View file

@ -11,9 +11,9 @@ __Participants__
* ichthyo * ichthyo
* benn * benn
* mfisher31_ * mfisher31_
* skangas * skangas
Summary of The Meeting Summary of The Meeting
---------------------- ----------------------
. _cehteh_ now also cares for Debian packaging of NoBug, as does _ichthyo_. . _cehteh_ now also cares for Debian packaging of NoBug, as does _ichthyo_.
@ -27,7 +27,7 @@ Summary of The Meeting
documents correct while trying to concentrate on content. documents correct while trying to concentrate on content.
Moreover, we discussed at Froscon the desire of having some Moreover, we discussed at Froscon the desire of having some
automatic means of generating a glossary of terms, i.e., automatically automatic means of generating a glossary of terms, i.e., automatically
generating the glossary.txt files, we decided to do all these things together. generating the glossary.txt files, we decided to do all these things together.
_benn_ agreed to write a script that would do the above. The script will be _benn_ agreed to write a script that would do the above. The script will be
called directly by build_website.sh. called directly by build_website.sh.
. git://www.lumiera.org/website-staging is for experiments and contained the . git://www.lumiera.org/website-staging is for experiments and contained the

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

@ -11,7 +11,7 @@ __Participants__
* ichthyo * ichthyo
* Benny * Benny
* Hendrik * Hendrik
_Summary written by ichthyo_ _Summary written by ichthyo_
@ -52,7 +52,7 @@ Conclusion
~~~~~~~~~~ ~~~~~~~~~~
* create a page with some images * create a page with some images
* conclusion about FrOSCon? ``it was fun'' ... * conclusion about FrOSCon? ``it was fun'' ...
@ -169,12 +169,12 @@ IRC Transcript
---------------------------- ----------------------------
[2013-09-12 22:59:46] <bennI_> what about the dependent jobs? [2013-09-12 22:59:46] <bennI_> what about the dependent jobs?
[2013-09-12 23:00:03] <ichthyo> thats the most important question I think, since *that* is something special [2013-09-12 23:00:03] <ichthyo> thats the most important question I think, since *that* is something special
[2013-09-12 23:00:19] <cehteh> yes dependencies need to be handled by the scheduler [2013-09-12 23:00:19] <cehteh> yes dependencies need to be handled by the scheduler
[2013-09-12 23:00:52] <ichthyo> well... at least the scheduler needs to poll them in some way [2013-09-12 23:00:52] <ichthyo> well... at least the scheduler needs to poll them in some way
[2013-09-12 23:01:01] <ichthyo> poll or notify or re-try or the like [2013-09-12 23:01:01] <ichthyo> poll or notify or re-try or the like
[2013-09-12 23:01:03] <cehteh> one question: shall jobs be in the priority queue even if their dependencies [2013-09-12 23:01:03] <cehteh> one question: shall jobs be in the priority queue even if their dependencies
are not yet satisfied? ... I'd tend to say yes are not yet satisfied? ... I'd tend to say yes
[2013-09-12 23:01:11] <bennI_> so we're not going to have a scheduler with simple jobs [2013-09-12 23:01:11] <bennI_> so we're not going to have a scheduler with simple jobs
[2013-09-12 23:01:31] <cehteh> the scheduler must maintain lists of dependencies. Nodes for these lists are likely [2013-09-12 23:01:31] <cehteh> the scheduler must maintain lists of dependencies. Nodes for these lists are likely
to be allocated by the small object allocator I've written some time ago; to be allocated by the small object allocator I've written some time ago;
@ -195,7 +195,7 @@ IRC Transcript
[2013-09-12 23:04:21] <ichthyo> on that level indeed, yes [2013-09-12 23:04:21] <ichthyo> on that level indeed, yes
[2013-09-12 23:04:45] <ichthyo> any more fancy functionality is encapsulated within that simple job abstraction [2013-09-12 23:04:45] <ichthyo> any more fancy functionality is encapsulated within that simple job abstraction
[2013-09-12 23:06:18] <cehteh> as long some resource (which can become a prerequisite/dependency of any other job) exists [2013-09-12 23:06:18] <cehteh> as long some resource (which can become a prerequisite/dependency of any other job) exists
it has some ultra-lightweight job structure associated with it it has some ultra-lightweight job structure associated with it
[2013-09-12 23:06:45] <ichthyo> now, for example, lets consider the loading of data from a file. [2013-09-12 23:06:45] <ichthyo> now, for example, lets consider the loading of data from a file.
How does this work in practice? do we get a callback when the data arrives? How does this work in practice? do we get a callback when the data arrives?
@ -210,13 +210,13 @@ IRC Transcript
[2013-09-12 23:08:42] <cehteh> yes [2013-09-12 23:08:42] <cehteh> yes
[2013-09-12 23:08:58] <bennI_> from the schedulers perspective, it's juts a callback, so it is defined elsewhere [2013-09-12 23:08:58] <bennI_> from the schedulers perspective, it's juts a callback, so it is defined elsewhere
i.e., data loading and details are implemented elsewhere in the callback itself i.e., data loading and details are implemented elsewhere in the callback itself
[2013-09-12 23:09:43] <ichthyo> But... there is a problem: not the scheduler invokes that callback, [2013-09-12 23:09:43] <ichthyo> But... there is a problem: not the scheduler invokes that callback,
someone else (triggered by the kernel) invokes this callback, and someone else (triggered by the kernel) invokes this callback, and
this must result in the unblocking of the dependant jobs, right? this must result in the unblocking of the dependant jobs, right?
[2013-09-12 23:10:35] <bennI_> the scheduler just has the callback waiting, then when all conditions are met [2013-09-12 23:10:35] <bennI_> the scheduler just has the callback waiting, then when all conditions are met
it just gets scheduled it just gets scheduled
[2013-09-12 23:10:21] <cehteh> nope [2013-09-12 23:10:21] <cehteh> nope
[2013-09-12 23:10:54] <cehteh> note: we need a 'polling' state for a job [2013-09-12 23:10:54] <cehteh> note: we need a 'polling' state for a job
[2013-09-12 23:10:57] <ichthyo> so the scheduler polls a variable, signalling that the data is there (or isn't yet) [2013-09-12 23:10:57] <ichthyo> so the scheduler polls a variable, signalling that the data is there (or isn't yet)
[2013-09-12 23:11:14] <cehteh> yes [2013-09-12 23:11:14] <cehteh> yes
@ -256,7 +256,7 @@ IRC Transcript
[2013-09-12 23:18:22] <cehteh> well the scheduler on the lowest level should be unaware of all that [2013-09-12 23:18:22] <cehteh> well the scheduler on the lowest level should be unaware of all that
.. just dead dumb scheduling. All logic is rolled on higher levels .. just dead dumb scheduling. All logic is rolled on higher levels
that allows us for more smart things depending on the actual use case, that allows us for more smart things depending on the actual use case,
different strategies for different things different strategies for different things
[2013-09-12 23:17:50] <bennI_> we could even have only ONE job: it has a linked lists of jobs [2013-09-12 23:17:50] <bennI_> we could even have only ONE job: it has a linked lists of jobs
but why not -- instead of ONE job, it can have a linked list of small jobs but why not -- instead of ONE job, it can have a linked list of small jobs
once it's scheduled, maybe only one job gets run, i.e. data gets loaded. once it's scheduled, maybe only one job gets run, i.e. data gets loaded.
@ -337,12 +337,12 @@ IRC Transcript
[2013-09-12 23:39:54] <ichthyo> ok, but someone has to do that. [2013-09-12 23:39:54] <ichthyo> ok, but someone has to do that.
Proc certainly can't do that, it can only give you a whole bunch of jobs Proc certainly can't do that, it can only give you a whole bunch of jobs
for background rendering for background rendering
[2013-09-12 23:40:07] <cehteh> the job function might be aware if its scheduled because of in-time or [2013-09-12 23:40:07] <cehteh> the job function might be aware if its scheduled because of in-time or
background queue and adjust itself background queue and adjust itself
[2013-09-12 23:40:57] <cehteh> we only schedule background jobs if nothing else is to do [2013-09-12 23:40:57] <cehteh> we only schedule background jobs if nothing else is to do
[2013-09-12 23:41:18] <ichthyo> what means "nothing else"? [2013-09-12 23:41:18] <ichthyo> what means "nothing else"?
for example, if we're waiting for data to arrive, can we meanwhile schedule for example, if we're waiting for data to arrive, can we meanwhile schedule
background calculation (non-IO) jobs? background calculation (non-IO) jobs?
[2013-09-12 23:41:45] <cehteh> and if I/O becomes the bottleneck some logic to throttle background jobs [2013-09-12 23:41:45] <cehteh> and if I/O becomes the bottleneck some logic to throttle background jobs
might be implemented on the higher level job functions... might be implemented on the higher level job functions...
[2013-09-12 23:42:12] <cehteh> I abstracted "thread classes" in the worker pool remember [2013-09-12 23:42:12] <cehteh> I abstracted "thread classes" in the worker pool remember
@ -355,7 +355,7 @@ IRC Transcript
[2013-09-12 23:43:55] <ichthyo> the planning of new jobs happens within jobs [2013-09-12 23:43:55] <ichthyo> the planning of new jobs happens within jobs
there are some special planning jobs from time to time there are some special planning jobs from time to time
but that certainly remains opaque for the scheduler but that certainly remains opaque for the scheduler
[2013-09-12 23:44:15] <cehteh> the scheduler should not be aware/responsible for any other resource managemnt [2013-09-12 23:44:15] <cehteh> the scheduler should not be aware/responsible for any other resource managemnt
[2013-09-12 23:44:38] <bennI_> you can feed a nice to the scheduler, but the scheduler only uses the nice value [2013-09-12 23:44:38] <bennI_> you can feed a nice to the scheduler, but the scheduler only uses the nice value
to reshuffle. Someone else must decide when to issue a nice to reshuffle. Someone else must decide when to issue a nice
@ -410,7 +410,7 @@ IRC Transcript
[2013-09-12 23:58:00] <ichthyo> namely, (1) we translate them into dependent jobs (jobs that follow) [2013-09-12 23:58:00] <ichthyo> namely, (1) we translate them into dependent jobs (jobs that follow)
and (2) we have conditional jobs, which are polled regularly, and (2) we have conditional jobs, which are polled regularly,
until they signal that a condition is met (or their deadline has passed) until they signal that a condition is met (or their deadline has passed)
[2013-09-12 23:58:59] <cehteh> ichthyo: I think job creation is a (at least) 2 step process .. first you create [2013-09-12 23:58:59] <cehteh> ichthyo: I think job creation is a (at least) 2 step process .. first you create
the job structure, fill in any data (jobs it depends on). These 'jobs it depends on' the job structure, fill in any data (jobs it depends on). These 'jobs it depends on'
might be just created of course .. and then when done you unleash it to the scheduler might be just created of course .. and then when done you unleash it to the scheduler
@ -418,9 +418,9 @@ IRC Transcript
[2013-09-12 23:59:52] <ichthyo> on high-level, I hand over jobs as "transactions" or batches [2013-09-12 23:59:52] <ichthyo> on high-level, I hand over jobs as "transactions" or batches
then, the scheduler-frontend might do some preprocessing and re-grouping then, the scheduler-frontend might do some preprocessing and re-grouping
and finally hands over the right data structures to the low-level interface and finally hands over the right data structures to the low-level interface
[2013-09-13 00:00:35] <cehteh> after you given it to the scheduler, shall the scheduler dispose it when done [2013-09-13 00:00:35] <cehteh> after you given it to the scheduler, shall the scheduler dispose it when done
(I mean really done) or give it back to you (I mean really done) or give it back to you
[2013-09-13 00:00:49] <ichthyo> never give it back [2013-09-13 00:00:49] <ichthyo> never give it back
[2013-09-13 00:00:52] <cehteh> OK [2013-09-13 00:00:52] <cehteh> OK
[2013-09-13 00:00:56] <ichthyo> it is really point-and-shot [2013-09-13 00:00:56] <ichthyo> it is really point-and-shot
@ -464,8 +464,8 @@ IRC Transcript
[2013-09-13 00:08:57] <ichthyo> well yes. but that is not Proc [2013-09-13 00:08:57] <ichthyo> well yes. but that is not Proc
not Proc or the Player is doing that, but the scheduler (in the wider sense) is doing that not Proc or the Player is doing that, but the scheduler (in the wider sense) is doing that
since in my understanding, only the scheduler has access to the jobs, after they since in my understanding, only the scheduler has access to the jobs, after they
have been handed over have been handed over
[2013-09-13 00:09:41] <cehteh> well proc creates the job [2013-09-13 00:09:41] <cehteh> well proc creates the job
[2013-09-13 00:09:47] <cehteh> yes [2013-09-13 00:09:47] <cehteh> yes
[2013-09-13 00:10:12] <cehteh> but you certainly augment the low level job structure with some higher level data [2013-09-13 00:10:12] <cehteh> but you certainly augment the low level job structure with some higher level data
[2013-09-13 00:10:30] <ichthyo> yes [2013-09-13 00:10:30] <ichthyo> yes
@ -475,7 +475,7 @@ IRC Transcript
[2013-09-13 00:11:16] <ichthyo> I'd like to see that entirely as an implementation detail within the scheduler [2013-09-13 00:11:16] <ichthyo> I'd like to see that entirely as an implementation detail within the scheduler
[2013-09-13 00:11:23] <cehteh> the job descriptor must become very small [2013-09-13 00:11:23] <cehteh> the job descriptor must become very small
[2013-09-13 00:11:28] <ichthyo> since it highly depends on thread management and the like [2013-09-13 00:11:28] <ichthyo> since it highly depends on thread management and the like
[2013-09-13 00:11:50] <cehteh> no need [2013-09-13 00:11:50] <cehteh> no need
[2013-09-13 00:12:15] <ichthyo> essentially, Proc will try to keep out of that discussion [2013-09-13 00:12:15] <ichthyo> essentially, Proc will try to keep out of that discussion
[2013-09-13 00:12:16] <cehteh> it can become an implementation detail of some middle layer .. above the scheduler [2013-09-13 00:12:16] <cehteh> it can become an implementation detail of some middle layer .. above the scheduler
---------------------------- ----------------------------
@ -486,7 +486,7 @@ IRC Transcript
.-- how to handle aborting/superseding -- .-- how to handle aborting/superseding --
[caption="☉Transcript☉ "] [caption="☉Transcript☉ "]
---------------------------- ----------------------------
[2013-09-13 00:12:19] <bennI_> how is the proc going to say 'stop some job' [2013-09-13 00:12:19] <bennI_> how is the proc going to say 'stop some job'
[2013-09-13 00:12:28] <ichthyo> yes that's the question. That's what I'm getting at [2013-09-13 00:12:28] <ichthyo> yes that's the question. That's what I'm getting at
[2013-09-13 00:12:49] <ichthyo> Proc will certainly never ask you to stop a specific job [2013-09-13 00:12:49] <ichthyo> Proc will certainly never ask you to stop a specific job
this is sure. this is sure.
@ -502,7 +502,7 @@ IRC Transcript
[2013-09-13 00:14:32] <bennI_> 'IT' ? [2013-09-13 00:14:32] <bennI_> 'IT' ?
the proc? the proc?
[2013-09-13 00:14:44] <cehteh> why number .. why not the low level job pointer? [2013-09-13 00:14:44] <cehteh> why number .. why not the low level job pointer?
that is guaranteed to be a valid unique number for each job that is guaranteed to be a valid unique number for each job
[2013-09-13 00:15:06] <ichthyo> cehteh: since Proc never retains knowledge regarding individual jobs [2013-09-13 00:15:06] <ichthyo> cehteh: since Proc never retains knowledge regarding individual jobs
[2013-09-13 00:15:17] <cehteh> uhm -- when you create a job it does [2013-09-13 00:15:17] <cehteh> uhm -- when you create a job it does
[2013-09-13 00:15:24] <bennI_> 'cause the Proc layer wants to give the job to the scheduler and say goodby, [2013-09-13 00:15:24] <bennI_> 'cause the Proc layer wants to give the job to the scheduler and say goodby,
@ -523,7 +523,7 @@ IRC Transcript
[2013-09-13 00:18:18] <ichthyo> anyway, then "the manager" is also part of "the scheduler" damn it ;-) [2013-09-13 00:18:18] <ichthyo> anyway, then "the manager" is also part of "the scheduler" damn it ;-)
[2013-09-13 00:18:26] <bennI_> is it the WALL where the proc thows over the job [2013-09-13 00:18:26] <bennI_> is it the WALL where the proc thows over the job
[2013-09-13 00:18:31] <cehteh> it just schedules .. and if a job is canceled then the job-function [2013-09-13 00:18:31] <cehteh> it just schedules .. and if a job is canceled then the job-function
has to figure that out and make a no-op has to figure that out and make a no-op
[2013-09-13 00:18:28] <ichthyo> Backend handles that layer. "The scheduler" is a high level thing [2013-09-13 00:18:28] <ichthyo> Backend handles that layer. "The scheduler" is a high level thing
it contains multiple low-level schedulers, priqueues and all the management stuff, it contains multiple low-level schedulers, priqueues and all the management stuff,
and "the scheduler" as a subsystem can arrange this stuff in an optimal way. and "the scheduler" as a subsystem can arrange this stuff in an optimal way.
@ -538,7 +538,7 @@ IRC Transcript
[2013-09-13 00:20:23] <bennI_> its that mystically 'layer' or manager? [2013-09-13 00:20:23] <bennI_> its that mystically 'layer' or manager?
[2013-09-13 00:20:29] <ichthyo> yes [2013-09-13 00:20:29] <ichthyo> yes
[2013-09-13 00:20:43] <ichthyo> and this mystical manager needs internal knowledge how the scheduler works [2013-09-13 00:20:43] <ichthyo> and this mystical manager needs internal knowledge how the scheduler works
[2013-09-13 00:20:45] <cehteh> so the logic is all in the job function .. [2013-09-13 00:20:45] <cehteh> so the logic is all in the job function ..
[2013-09-13 00:20:47] <bennI_> as a client you can expect the manager to do this [2013-09-13 00:20:47] <bennI_> as a client you can expect the manager to do this
[2013-09-13 00:20:55] <bennI_> but the manager belongs not to the scheduler [2013-09-13 00:20:55] <bennI_> but the manager belongs not to the scheduler
[2013-09-13 00:21:00] <ichthyo> but the client doesn't need internal knowledge how the scheduler works [2013-09-13 00:21:00] <ichthyo> but the client doesn't need internal knowledge how the scheduler works
@ -550,7 +550,7 @@ IRC Transcript
[2013-09-13 00:21:26] <bennI_> ok, WHO wants to stop or abort jobs? [2013-09-13 00:21:26] <bennI_> ok, WHO wants to stop or abort jobs?
[2013-09-13 00:21:46] <cehteh> proc :> [2013-09-13 00:21:46] <cehteh> proc :>
[2013-09-13 00:21:48] <ichthyo> the player [2013-09-13 00:21:48] <ichthyo> the player
[2013-09-13 00:22:11] <ichthyo> more precisely: the player doesn't want to stop jobs, but he wants to change the playback mode [2013-09-13 00:22:11] <ichthyo> more precisely: the player doesn't want to stop jobs, but he wants to change the playback mode
[2013-09-13 00:22:29] <cehteh> ichthyo: do you really need a 'scope' or can you have a 'leader' which you abort [2013-09-13 00:22:29] <cehteh> ichthyo: do you really need a 'scope' or can you have a 'leader' which you abort
This leader is practically implemented as a job which is already finished but others wait on it This leader is practically implemented as a job which is already finished but others wait on it
@ -560,7 +560,7 @@ IRC Transcript
Proc can try to support that feature with giving the right information Proc can try to support that feature with giving the right information
grouping or tagging would be one option grouping or tagging would be one option
[2013-09-13 00:24:26] <ichthyo> just look at the requirement from the player: [2013-09-13 00:24:26] <ichthyo> just look at the requirement from the player:
consider the pause button or loop playing, while the user moves the loop boundaries consider the pause button or loop playing, while the user moves the loop boundaries
[2013-09-13 00:24:50] <ichthyo> or think at scrubbing where the user drags the "playhead" marker while it move [2013-09-13 00:24:50] <ichthyo> or think at scrubbing where the user drags the "playhead" marker while it move
[2013-09-13 00:24:19] <cehteh> I opt for the leader implementation [2013-09-13 00:24:19] <cehteh> I opt for the leader implementation
because that needs no complicated scope lookup and can be implemented with the facilities because that needs no complicated scope lookup and can be implemented with the facilities

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

@ -10,7 +10,7 @@ __Participants__
* ichthyo * ichthyo
* benny * benny
* cehteh * cehteh
_Summary written by Ichthyo and reviewed by Benny_ _Summary written by Ichthyo and reviewed by Benny_
'''' ''''
@ -116,7 +116,7 @@ support framework.
Next meeting 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. You are welcome to join.
'''' ''''

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

@ -9,7 +9,7 @@ __Participants__
* ichthyo * ichthyo
* benny * benny
_Summary written by Ichthyo_ _Summary written by Ichthyo_
'''' ''''
@ -65,7 +65,7 @@ but a replacement solution was identified, which still needs to be integrated.
Next meeting 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. You are welcome to join.
'''' ''''

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

@ -10,7 +10,7 @@ __Participants__
* ichthyo * ichthyo
* benny * benny
* cehteh * cehteh
_Summary written by Ichthyo_ _Summary written by Ichthyo_
'''' ''''
@ -93,7 +93,7 @@ able to demonstrate running video display in the GUI.
Next meeting 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. You are welcome to join.
'''' ''''

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

@ -25,7 +25,7 @@ Test Scheduler Suitability
Once the scheduler had been implemented it was necessary to subject it Once the scheduler had been implemented it was necessary to subject it
to various load tests to establish its stability, and stress tests were necessary to to various load tests to establish its stability, and stress tests were necessary to
provide information on performance limitations so that we would be able to establish provide information on performance limitations so that we would be able to establish
whether these limitations met the demands required by Lumiera. whether these limitations met the demands required by Lumiera.
Results were encouraging. Results were encouraging.
_Ichthyo_ reported on stress tests on the new scheduler. After resolving a series _Ichthyo_ reported on stress tests on the new scheduler. After resolving a series

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

@ -427,10 +427,10 @@ Topics
~~~~~~ ~~~~~~
* boilerplate (protocol, what's left from last meeting) * boilerplate (protocol, what's left from last meeting)
* Introduction of Lumiera * Introduction of Lumiera
* handling of config errors. * handling of config errors.
* scripting language. * scripting language.
* editing on small devices (eeePC) * editing on small devices (eeePC)
* uWiki. * uWiki.
* 'musical' timeline in bars and beats * 'musical' timeline in bars and beats
Summary Summary
@ -448,7 +448,7 @@ Topics
* boilerplate (protocol, what's left from last meeting) * boilerplate (protocol, what's left from last meeting)
* Go through Ideas and Drafts in design process * Go through Ideas and Drafts in design process
- processing node interface - processing node interface
- Placement concept - Placement concept
Summary Summary
^^^^^^^ ^^^^^^^

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

@ -170,14 +170,14 @@ Deltafire:: '2007-07-03 12:17:09'
after a talk on irc, we decided to do it this way, further work will be after a talk on irc, we decided to do it this way, further work will be
documented in the repository (tiddlywiki/source) documented in the repository (tiddlywiki/source)
ct:: '2007-07-11 13:10:07' ct:: '2007-07-11 13:10:07'
Development took another direction over course of the years; Development took another direction over course of the years;
Lumiera is not based on a _generic plug-in Architecture_ and the topic Lumiera is not based on a _generic plug-in Architecture_ and the topic
of interfaces for _dedicated plugins_ still needs to be worked out of interfaces for _dedicated plugins_ still needs to be worked out
Ichthyostega:: '2023-10-24 22:55:23' Ichthyostega:: '2023-10-24 22:55:23'
@ -197,7 +197,7 @@ 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 an conclusion: this proposal is now considered as *rejected*.
Instead, Ticket https://issues.lumiera.org/ticket/1212[#1212 »Extension Concept«] Instead, Ticket https://issues.lumiera.org/ticket/1212[#1212 »Extension Concept«]
was added to the list of relevant was added to the list of relevant
https://issues.lumiera.org/report/17[»Focus Topics«] for further development. https://issues.lumiera.org/report/17[»Focus Topics«] for further development.
......... .........

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

@ -116,7 +116,7 @@ Tasks
~~~~~ ~~~~~
// List what needs to be done to implement this Proposal: // List what needs to be done to implement this Proposal:
* identify what impedes such a modern setup procedure ([green]#✔ done#) * identify what impedes such a modern setup procedure ([green]#✔ done#)
* rectify the folder structure created in the build target * rectify the folder structure created in the build target
directory ([green]#✔ done#) directory ([green]#✔ done#)
* build the executables in a way to allow relative resolution of the * build the executables in a way to allow relative resolution of the
internal shared modules ([green]#✔ done#) internal shared modules ([green]#✔ done#)
@ -176,7 +176,7 @@ breeds on 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 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 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 a bit alien
within the classic UNIX environment. within the classic UNIX environment.

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

@ -165,7 +165,7 @@ own internal things too. Imo thats some very valuable service.
-- link:ct[] [[DateTime(2008-11-08T06:26:18Z)]] -- link:ct[] [[DateTime(2008-11-08T06:26:18Z)]]
Some further minor details: We didn't finish the discussion about namespaces on 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 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, or three alternatives I see regarding namespace organisation). But probably,
"lumiera::" will be our top level interface namespace and then probably the "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 directory will be taken by that. I see no problem also putting some

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

@ -14,8 +14,8 @@ This proposal intends to capture envisioned Architecture of the Application.
image:{ldoc}/devel/draw/rendered/Lumi.Architecture-1.png[Overview of Lumiera Architecture] image:{ldoc}/devel/draw/rendered/Lumi.Architecture-1.png[Overview of Lumiera Architecture]
^The SVG source of this drawing is ^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]^ link:http://www.lumiera.org/gitweb?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD[maintained in GIT]^
Description Description
@ -41,7 +41,7 @@ Comments
-------- --------
* Alcarinque made link:/documentation/design/gui/GuiDiscussion/Proposal.Alcarinque.html[some * Alcarinque made link:/documentation/design/gui/GuiDiscussion/Proposal.Alcarinque.html[some
design drafts] for the UI. Here is the design drafts] for the UI. Here is the
link:/documentation/design/gui/GuiDiscussion/Proposal.Alcarinque.svg[SVG source] (converted 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 from OODraw by Ichthyo 2011). This is not a technical draft at all, it is just
an idea. an idea.

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

@ -122,7 +122,7 @@ Parked until someone cares
~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~
Decided on Developer meeting Decided on Developer meeting
Do 14 Apr 2011 02:52:30 CEST Christian Thaeter Do 14 Apr 2011 02:52:30 CEST Christian Thaeter
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview] Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

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

@ -241,10 +241,10 @@ anchor:anchor_types[]provided TYPES
config type C type semantic (example) config type C type semantic (example)
------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------
number signed long long also hex and octal (foo.bar = 12345 #comment) number signed long long also hex and octal (foo.bar = 12345 #comment)
real long double differerent formats as well (foo.bar=1.2345 #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) 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) 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) 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.) ... add more types on demand (ichthyo mentioned a tuple type for color triples etc.)

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

@ -283,7 +283,7 @@ In order to support scenario/take/clip tagging:
x = c:extra ; extra only visible in this clip! x = c:extra ; extra only visible in this clip!
x = tc:extra ; this take and clip show the extra x = tc:extra ; this take and clip show the extra
etc etc
Other keyargs (the part in front of the colon) can be added to account for 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).
@ -293,7 +293,7 @@ associate (with space, multiple tags can be added.). The following specials are
defined: defined:
[:keyarg:]:TAG is special tagging for scenario/take/clip. [:keyarg:]:TAG is special tagging for scenario/take/clip.
!TAG removes TAG if it is present. This is useful because it allows huge !TAG removes TAG if it is present. This is useful because it allows huge
sections of the clip to be defined as a certain tag, then have parts sections of the clip to be defined as a certain tag, then have parts
removed later. removed later.
a:TAG applies TAG only to the audio. a:TAG applies TAG only to the audio.
v:TAG applies TAG only to the video. v:TAG applies TAG only to the video.

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

@ -10,7 +10,7 @@ Developer Documentation Structure
*Proposed by* Cehteh + Ichthyo *Proposed by* Cehteh + Ichthyo
------------------------------------- -------------------------------------
******************************************************************************** ********************************************************************************
We describe here how to bring the Lumiera Developer Documentation into an simple We describe here how to bring the Lumiera Developer Documentation into an simple
yet systematic structure. Previously we accumulated a lot Documentation which yet systematic structure. Previously we accumulated a lot Documentation which
ended in quite a few different places. This will gradually be tidied up. ended in quite a few different places. This will gradually be tidied up.
@ -43,7 +43,7 @@ The Lumiera (developer) documentation shall be organised in the following way:
links into the relevant technical detail documentation. links into the relevant technical detail documentation.
. the extensive link:{ldoc}/technical/[technical documentation] . the extensive link:{ldoc}/technical/[technical documentation]
is comprised of several bodies of information existing side by side is comprised of several bodies of information existing side by side
- there is a hierarchy of written documentation to explain the workings - there is a hierarchy of written documentation to explain the workings
of subsystems and components. Typically, these writings emerge from of subsystems and components. Typically, these writings emerge from
working notes and design drafts. working notes and design drafts.
@ -53,10 +53,10 @@ The Lumiera (developer) documentation shall be organised in the following way:
which can be comprehended by reference to mailing list threads which can be comprehended by reference to mailing list threads
and IRC transcripts and IRC transcripts
- there is a section with link:{ldoc}/technical/howto/[developer HOWTOs and tutorials] - there is a section with link:{ldoc}/technical/howto/[developer HOWTOs and tutorials]
. the documentation of technical details is always kept close to the . the documentation of technical details is always kept close to the
actual source actual source
- file level link:{doxy}/[Doxygen] comments serve as overview and explanations - file level link:{doxy}/[Doxygen] comments serve as overview and explanations
of 'key abstractions' and 'components'. of 'key abstractions' and 'components'.
- unit tests are often written in a ``narative'' fashion and - unit tests are often written in a ``narative'' fashion and
@ -76,7 +76,7 @@ Tasks
[red yellow-background]#TBD# [red yellow-background]#TBD#
* Create a facility to support the cross-linking between the various kinds of documents * Create a facility to support the cross-linking between the various kinds of documents
[yellow-background]#WIP# [yellow-background]#WIP#
Pros Pros
@ -84,7 +84,7 @@ Pros
// add just a fact list/enumeration which make this suitable: // add just a fact list/enumeration which make this suitable:
Much easier entry to the whole developer documentation. Reading the »Inner Core« Much easier entry to the whole developer documentation. Reading the »Inner Core«
document should be sufficient to get a good idea about the Lumiera design and document should be sufficient to get a good idea about the Lumiera design and
layout. All details are linked from there and thus easily findable. layout. All details are linked from there and thus easily findable.
@ -114,9 +114,9 @@ Rationale
--------- ---------
//rationale: Describe why it should be done *this* way: //rationale: Describe why it should be done *this* way:
This approach fits nicely into our overall infrastructure and the way we wanted This approach fits nicely into our overall infrastructure and the way we wanted
to do things. Using git and asciidoc mostly, making the developer documentation to do things. Using git and asciidoc mostly, making the developer documentation
part of the source tree and reasonable easy available/maintainable to part of the source tree and reasonable easy available/maintainable to
developers. developers.
//Conclusion //Conclusion

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

@ -59,7 +59,7 @@ processes exist.
released finally released finally
.Process parameters .Process parameters
A process is linked to a single stream data format (a -> A process is linked to a single stream data format (a ->
link:StreamTypeSystem.html[stream implementation type]). + link:StreamTypeSystem.html[stream implementation type]). +
It is configured with _frame quantisation_ and _timings_, and a _model port_ It is configured with _frame quantisation_ and _timings_, and a _model port_
identifier and _channel selector_. identifier and _channel selector_.
@ -67,16 +67,16 @@ identifier and _channel selector_.
quantisation:: quantisation::
translates time values into frame numbers. (In the most general translates time values into frame numbers. (In the most general
case this is a function, connected to the session) case this is a function, connected to the session)
timings:: timings::
a definition to translate global model time units in real clock time, a definition to translate global model time units in real clock time,
including _alignment_ to an external _time grid_. including _alignment_ to an external _time grid_.
model port:: model port::
a point in the (high level) model where output can be produced. + a point in the (high level) model where output can be produced. +
This might be a global pipe in one of the model's timelines, or This might be a global pipe in one of the model's timelines, or
it might be a _probe point_. it might be a _probe point_.
channel:: channel::
within the session and high level model, details of the stream within the session and high level model, details of the stream
implementation are abstracted. Typically, a global pipe (master bus implementation are abstracted. Typically, a global pipe (master bus

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

@ -168,7 +168,7 @@ ____
> ist, ob wir nicht sogar metaphorische, oder symbolische Namen wählen sollten. > ist, ob wir nicht sogar metaphorische, oder symbolische Namen wählen sollten.
> Etwas, was man vielleicht auch nicht gleich versteht, was aber die Phantasie > Etwas, was man vielleicht auch nicht gleich versteht, was aber die Phantasie
> anregt. Meine Favoriten wären da (Du weißt, was für Filme ich mag....) > anregt. Meine Favoriten wären da (Du weißt, was für Filme ich mag....)
> >
> - Stage > - Stage
> - Steam > - Steam
> - Vault > - Vault

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

@ -95,7 +95,7 @@ need more implementation experience.
Some existing iterators or collection-style interfaces should be retro-fitted. Some existing iterators or collection-style interfaces should be retro-fitted.
See https://issues.lumiera.org/ticket/349[Ticket #349]. + See https://issues.lumiera.org/ticket/349[Ticket #349]. +
Moreover, we need to Moreover, we need to
gain experience about mapping this concept down into a flat C-style API. gain experience about mapping this concept down into a flat C-style API.
@ -147,13 +147,13 @@ concept, but provides an opaque frontend, allowing to decouple completely from t
actual implementation. Besides that, over time I've written several standard adapters actual implementation. Besides that, over time I've written several standard adapters
for the most common STL containers, plus Map, key and value extractors. for the most common STL containers, plus Map, key and value extractors.
Ichthyostega:: 'Sa 16 Apr 2011 00:20:13 CEST' Ichthyostega:: 'Sa 16 Apr 2011 00:20:13 CEST'
minor change: removed support for post-increment. It doesn't fit with the concept minor change: removed support for post-increment. It doesn't fit with the concept
and caused serious problems in practice. A correct implementation of post-increment and caused serious problems in practice. A correct implementation of post-increment
would require a ``deep copy'' of any underlying data structures. would require a ``deep copy'' of any underlying data structures.
Ichthyostega:: 'Sa 07 Jan 2012 21:49:09 CET' ~<prg@ichthyostega.de>~ Ichthyostega:: 'Sa 07 Jan 2012 21:49:09 CET' ~<prg@ichthyostega.de>~
NOTE: Lumiera Forward Iterators can be made to work together with the NOTE: Lumiera Forward Iterators can be made to work together with the
'range for loop', as introduced with C++11. The preferred solution 'range for loop', as introduced with C++11. The preferred solution

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

@ -26,7 +26,7 @@ repositories:
[grid="all"] [grid="all"]
`-------------`----------------------------------------------------`---------------------------- `-------------`----------------------------------------------------`----------------------------
*BRANCHNAME* *DESCRIPTION* *BRANCHNAME* *DESCRIPTION*
*Automatic updated from* *Automatic updated from*
'master' Stable branch, use this as generic entry point. cehteh, 'master' Stable branch, use this as generic entry point. cehteh,
ichthyo ichthyo

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

@ -78,11 +78,11 @@ in general.
The good news is, that: The good news is, that:
1. All commonly used filters are either type 1 or type 2 1. All commonly used filters are either type 1 or type 2
(type 3 are more the fun effects) (type 3 are more the fun effects)
2. Filters of type 2 are colormodel agnostic 2. Filters of type 2 are colormodel agnostic
3. If a filter of type 1 makes only linear transformations of the color 3. If a filter of type 1 makes only linear transformations of the color
vectors (new_color = matrix * old_color), vectors (new_color = matrix * old_color),
the matrix can be transformed from e.g. RGB to YUV, so these filters can the matrix can be transformed from e.g. RGB to YUV, so these filters can
always work in both colorspaces directly always work in both colorspaces directly

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

@ -157,7 +157,7 @@ Comments
.State -> Final .State -> Final
ichthyo wants this to be a dedicated thread (own subsystem) instead running in ichthyo wants this to be a dedicated thread (own subsystem) instead running in
the initial thread. Fixed this in the proposal above, this makes this accepted. the initial thread. Fixed this in the proposal above, this makes this accepted.
Do 14 Apr 2011 03:40:41 CEST Christian Thaeter <ct@pipapo.org> Do 14 Apr 2011 03:40:41 CEST Christian Thaeter <ct@pipapo.org>

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

@ -260,7 +260,7 @@ GUI handling could make use of expanded view features like ;
zoomed and other camera/projector render, or show full rendering including zoomed and other camera/projector render, or show full rendering including
effects - this ties in with the idea of being able to link a monitor with effects - this ties in with the idea of being able to link a monitor with
viewing anywhere in the node system - but is able to be swiftly changed viewing anywhere in the node system - but is able to be swiftly changed
within the monitor view by icons mounted somewhere on each of the respective within the monitor view by icons mounted somewhere on each of the respective
monitors' perimeter. monitors' perimeter.
* the trackview itself, could be considered as a subview of a * the trackview itself, could be considered as a subview of a

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

@ -299,7 +299,7 @@ Tree:: '2008-12-27 08:36:36'
Parked Parked
~~~~~~ ~~~~~~
We have to revisit this, possibly someone (or a group) who wants to work on We have to revisit this, possibly someone (or a group) who wants to work on
the workflow. For now its parked until revisited. the workflow. For now its parked until revisited.
Do 14 Apr 2011 03:06:42 CEST Christian Thaeter Do 14 Apr 2011 03:06:42 CEST Christian Thaeter

14
doc/devel/rfc/VersionNumberScheme.txt
View file

@ -29,7 +29,7 @@ be monotonous increasing according to this ordering.
Version number sequence Version number sequence
~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~
.... ....
0.pre.## < 0.01~dev.20YYMMDDhhmm < 0.01 < 0.99 < 1.0~dev.20YYMMDDhhmm < 1.0 < 1.0.1 0.pre.## < 0.01~dev.20YYMMDDhhmm < 0.01 < 0.99 < 1.0~dev.20YYMMDDhhmm < 1.0 < 1.0.1
.... ....
Specifications Specifications
@ -50,29 +50,29 @@ releases, we distinguish *major* and *minor* and *bugfix* releases.
- besides the releases, we create *development snapshot releases*, which - besides the releases, we create *development snapshot releases*, which
are just _tagged builds_. are just _tagged builds_.
* Not every build/check-in gets promoted to such a tagged build; * Not every build/check-in gets promoted to such a tagged build;
rather there needs to be any reason from the users point of view, rather there needs to be any reason from the users point of view,
e.g. a bugfix we expect to be tried out at least by _someone_. e.g. a bugfix we expect to be tried out at least by _someone_.
* these _development snapshots_ are an _anticipation_ of the * these _development snapshots_ are an _anticipation_ of the
upcoming next release and thus get a numbering _derived_ from this upcoming next release and thus get a numbering _derived_ from this
_next_ release (not the previous one). _next_ release (not the previous one).
* dev snapshots use a _timestamp_ attached with a '~' (tilde char). * dev snapshots use a _timestamp_ attached with a '~' (tilde char).
It is common practice to order a tilde _below_ the release it is It is common practice to order a tilde _below_ the release it is
attached to (and debian follows this practice) attached to (and debian follows this practice)
- when we decide the application to be stable enough for real use and - when we decide the application to be stable enough for real use and
past the _beta_ phase, we switch over to the usual 3-digit version numbering. past the _beta_ phase, we switch over to the usual 3-digit version numbering.
* _major_ releases start with 1.0 and feature high impact changes, usually linked * _major_ releases start with 1.0 and feature high impact changes, usually linked
to some significant breakage of compatibility or some other disruptive event. to some significant breakage of compatibility or some other disruptive event.
* _minor_ releases may include some new features, but can be considered * _minor_ releases may include some new features, but can be considered
evolutionary. Their numbers are incremented on the second digit, like evolutionary. Their numbers are incremented on the second digit, like
1.1, 1.2, 1.3, 1.4, .... 1.1, 1.2, 1.3, 1.4, ....
* _bugfix_ releases are created when we have serious bugfixes to publish, * _bugfix_ releases are created when we have serious bugfixes to publish,
without any real new features. without any real new features.

16
doc/devel/rfc/WebsiteSupportMarkup.txt
View file

@ -39,8 +39,8 @@ Authoring::
is finished or in the final stages of completion. It is crucial for this is finished or in the final stages of completion. It is crucial for this
activity not to impose a _context switch_ on the writer. It must be ``just activity not to impose a _context switch_ on the writer. It must be ``just
writing down the obvious'' -- otherwise developers tend to defer this activity writing down the obvious'' -- otherwise developers tend to defer this activity
``for later''. This situation creates some unique problems... ``for later''. This situation creates some unique problems...
- during the write-up, the coder-author realises several external presuppositions, which, - during the write-up, the coder-author realises several external presuppositions, which,
during the act of coding, seemed to be ``obvious'' and ``self evident''. during the act of coding, seemed to be ``obvious'' and ``self evident''.
- since expanding on all of those secondary topics is out of scope (the author would rather - since expanding on all of those secondary topics is out of scope (the author would rather
@ -50,7 +50,7 @@ Authoring::
nor hunt for URLs; the author is disinclined to consult a markup syntax nor hunt for URLs; the author is disinclined to consult a markup syntax
reference. This arises from the nature of the required text which is reference. This arises from the nature of the required text which is
essentially difficult to grasp in the first place and even more difficult essentially difficult to grasp in the first place and even more difficult
too put into words. A task requiring full mental concentration. too put into words. A task requiring full mental concentration.
Integrating Content:: Integrating Content::
@ -59,7 +59,7 @@ Integrating Content::
Thus, some existing markup is extracted from an external system and pasted into some location, Thus, some existing markup is extracted from an external system and pasted into some location,
``just for the moment''. Of course, this content will be forgotten and rest there for ``just for the moment''. Of course, this content will be forgotten and rest there for
years to come. To counter act such a situation, we propose the following: years to come. To counter act such a situation, we propose the following:
- structural cross-references of the integrated markup needs to be easy to do. - structural cross-references of the integrated markup needs to be easy to do.
- a way in which we can somehow hook the new content into our current scheme - a way in which we can somehow hook the new content into our current scheme
of categories of categories
@ -72,7 +72,7 @@ Editorial work::
trees of pages, even splitting some of them, and adding introductory paragraphs and pages here and trees of pages, even splitting some of them, and adding introductory paragraphs and pages here and
there -- all without the ability to read or understand any of the reviewed there -- all without the ability to read or understand any of the reviewed
material to any degree of depth. material to any degree of depth.
- this work will be performed on the primary content using its ``natural'' representation: that is, - this work will be performed on the primary content using its ``natural'' representation: that is,
the editor will copy and move files in the file system and edit text. There is no room for using the editor will copy and move files in the file system and edit text. There is no room for using
any external system (unless such an external system is a fully integrated authoring environment). any external system (unless such an external system is a fully integrated authoring environment).
@ -96,7 +96,7 @@ to the markup for setting an external link, e.g. `link:SomeTopic[see the explana
Variations and extensions Variations and extensions
- we might consider detecting _CamelCaseWords_. This has some Pros and Cons. If we do so, we need some - we might consider detecting _CamelCaseWords_. This has some Pros and Cons. If we do so, we need some
easy to use escape mechanism, and this CamelCase detection must not trigger within code examples and easy to use escape mechanism, and this CamelCase detection must not trigger within code examples and
other kinds of literal quotes. other kinds of literal quotes.
- specifying the displayed link text should be optional - specifying the displayed link text should be optional
- we might consider adding some domain prefixes, e.g. +link:rfc:SomeTopic+ or +link:ticket:SomeTopic+ - we might consider adding some domain prefixes, e.g. +link:rfc:SomeTopic+ or +link:ticket:SomeTopic+
@ -129,7 +129,7 @@ to take precedence.
Definition entries Definition entries
^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^
Define a suitable format to promote an existing piece of information into a *definition*. While not Define a suitable format to promote an existing piece of information into a *definition*. While not
interfering with the presentation at the textual location of this definition, the mechanism should support the interfering with the presentation at the textual location of this definition, the mechanism should support the
possibility of providing a definition in the source which is then extracted from the text and presented possibility of providing a definition in the source which is then extracted from the text and presented
in a new file as, for example, a glossary of terms. It would be nice if such a generated glossary could in a new file as, for example, a glossary of terms. It would be nice if such a generated glossary could
provide an automatic back-link to the location where the definition was picked up initially. provide an automatic back-link to the location where the definition was picked up initially.
@ -197,7 +197,7 @@ Alternatives
. _using a mature CMS_: this is what most people do, so it can't be uttermost wrong. + . _using a mature CMS_: this is what most people do, so it can't be uttermost wrong. +
Yet still, the benefits of running a CMS need to outweigh the known problems, especially Yet still, the benefits of running a CMS need to outweigh the known problems, especially
* lock-in, ``insular'' ecosystem, being tied to the evolution of a platform ``not invented here'' * lock-in, ``insular'' ecosystem, being tied to the evolution of a platform ``not invented here''
* separation from the code tree, lack of seamless SCM integration * separation from the code tree, lack of seamless SCM integration
* the general penalties of using a database backed system * the general penalties of using a database backed system

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

@ -9,7 +9,7 @@ Design Proposal Pool
This is the pool of all RfC Design Proposals. + This is the pool of all RfC Design Proposals. +
Please use the navigation menu to access individual entries. Please use the navigation menu to access individual entries.
++++ ++++
<br/><br/><br/> <br/><br/><br/>
++++ ++++
'''' ''''
[small]#technically, all the RfC documents are stored within this pool directory; + [small]#technically, all the RfC documents are stored within this pool directory; +

8
doc/devel/transcript/2008-06_BufferAllocation.txt
View file

@ -16,7 +16,7 @@ __cehteh__ and __ichthyo__
[19:21:57] <ichthyo> I have one topic I want to discuss with you, cehteh [19:21:57] <ichthyo> I have one topic I want to discuss with you, cehteh
[19:22:07] <ichthyo> but it need not be now, or in the meeting [19:22:07] <ichthyo> but it need not be now, or in the meeting
[19:22:07] <cehteh> ok [19:22:07] <cehteh> ok
[19:22:24] <ichthyo> it's about allocating processing buffers [19:22:24] <ichthyo> it's about allocating processing buffers
[19:23:20] <cehteh> the backend will provide them as temporary files/cyclic buffers [19:23:20] <cehteh> the backend will provide them as temporary files/cyclic buffers
[19:23:52] <cehteh> its not there yet but in my mind [19:23:52] <cehteh> its not there yet but in my mind
[19:24:11] <ichthyo> haha, same for the builder... it's mostly just in my mind [19:24:11] <ichthyo> haha, same for the builder... it's mostly just in my mind
@ -68,7 +68,7 @@ __cehteh__ and __ichthyo__
[19:39:50] <ichthyo> we can't prepare everything, because, some nodes may include a variable ammount of source frames [19:39:50] <ichthyo> we can't prepare everything, because, some nodes may include a variable ammount of source frames
[19:40:11] <ichthyo> and this number can depend on automation. Classic example is the "time average" video effect [19:40:11] <ichthyo> and this number can depend on automation. Classic example is the "time average" video effect
[19:39:53] <cehteh> problem is only when the builder generates one node which takes X and in-place generates Y from it [19:39:53] <cehteh> problem is only when the builder generates one node which takes X and in-place generates Y from it
[19:40:10] <cehteh> and you have a 2nd node which takes X too [19:40:10] <cehteh> and you have a 2nd node which takes X too
[19:40:23] <cehteh> this needs to be serialized somehow [19:40:23] <cehteh> this needs to be serialized somehow
[19:41:12] <ichthyo> regarding the problem you mention: I want to exclude/avoid this situation already when building [19:41:12] <ichthyo> regarding the problem you mention: I want to exclude/avoid this situation already when building
[19:41:35] <cehteh> yes thats what i was thinking .. thats easiest addressed there [19:41:35] <cehteh> yes thats what i was thinking .. thats easiest addressed there
@ -118,7 +118,7 @@ __cehteh__ and __ichthyo__
[19:52:31] <cehteh> but memory requirements grow quadratic! [19:52:31] <cehteh> but memory requirements grow quadratic!
[19:52:46] <ichthyo> the user should NEVER need to set up the processing buffer size, as is necessary in cinelerra [19:52:46] <ichthyo> the user should NEVER need to set up the processing buffer size, as is necessary in cinelerra
[19:52:59] <cehteh> yes agreed [19:52:59] <cehteh> yes agreed
[19:53:15] <ichthyo> I don't think we need safe-regions allways, [19:53:15] <ichthyo> I don't think we need safe-regions allways,
[19:53:31] <ichthyo> but, as e.g. the motion tracking will create automation data in Lumiera [19:53:31] <ichthyo> but, as e.g. the motion tracking will create automation data in Lumiera
[19:53:38] <cehteh> yes only for some effect .. motion tracker doesnt need it [19:53:38] <cehteh> yes only for some effect .. motion tracker doesnt need it
[19:53:50] <ichthyo> it means the actual buffer size depends on automation data for a given frame [19:53:50] <ichthyo> it means the actual buffer size depends on automation data for a given frame
@ -131,7 +131,7 @@ __cehteh__ and __ichthyo__
[19:55:30] <cehteh> (in case of rotations) [19:55:30] <cehteh> (in case of rotations)
[19:55:36] <ichthyo> yes agreed [19:55:36] <ichthyo> yes agreed
[19:56:16] <cehteh> well temp buffers will be allcocated for frames of the same 'class' i aleready saied that [19:56:16] <cehteh> well temp buffers will be allcocated for frames of the same 'class' i aleready saied that
[19:56:50] <cehteh> and i will group these classes so that some similar sizes fall in the same class [19:56:50] <cehteh> and i will group these classes so that some similar sizes fall in the same class
[19:57:19] <cehteh> that might waste some memory on disk at the end of each frame .. but that doesnt need to be mapped in [19:57:19] <cehteh> that might waste some memory on disk at the end of each frame .. but that doesnt need to be mapped in
[19:57:32] <cehteh> the kernel will do that automatically for us [19:57:32] <cehteh> the kernel will do that automatically for us
[19:57:37] <ichthyo> :) [19:57:37] <ichthyo> :)

4
doc/index.txt
View file

@ -44,10 +44,10 @@ https://Lumiera.org[Lumiera homepage] by the menus on the left hand-side of the
page. This menu is also organised into layers that reflects the organisation of page. This menu is also organised into layers that reflects the organisation of
the documentation to help you navigate through the documentation. the documentation to help you navigate through the documentation.
Source code doc directory structure :: Source code doc directory structure ::
The layout of the sub-directories below the *doc* directory is structured around The layout of the sub-directories below the *doc* directory is structured around
the hierarchy, the hierarchy,
==== The Uppermost Layer ==== The Uppermost Layer
At the highest, uppermost layer is the document At the highest, uppermost layer is the document

6
doc/technical/build/BuildDependencies.txt
View file

@ -13,7 +13,7 @@ the more RAM and the more/faster CPU's you have the better.
Nevertheless lower end 32bit machines are supported too. Nevertheless lower end 32bit machines are supported too.
Secondary targets will be other free operating systems which offer a decent Posix API. Secondary targets will be other free operating systems which offer a decent Posix API.
Porting to other more or less similar platforms will be possible, if -- by coincidence -- Porting to other more or less similar platforms will be possible, if -- by coincidence --
Someone(TM) helps with porting. Someone(TM) helps with porting.
Having said that -- for the time being, the core team won't spend much effort on porting. Having said that -- for the time being, the core team won't spend much effort on porting.
@ -60,7 +60,7 @@ Languages and Tools
On rare occasions in the past, we _did_ use some GCC extensions, like `typeof()`, but we care for On rare occasions in the past, we _did_ use some GCC extensions, like `typeof()`, but we care for
workarounds, in case this becomes a problem. Incidentally, `typeof()` is obsoleted by the new workarounds, in case this becomes a problem. Incidentally, `typeof()` is obsoleted by the new
C++ standard, which provides `decltype()` for this purpose.]. C++ standard, which provides `decltype()` for this purpose.].
* BOOST (listed below are the Debian package names) * BOOST (listed below are the Debian package names)
- libboost-dev (at least *1.67*) - libboost-dev (at least *1.67*)
- libboost-program-options-dev - libboost-program-options-dev
@ -69,7 +69,7 @@ Languages and Tools
* Script languages * Script languages
- Python (*2.x*) might still be handy for build scripts.footnote:[SCons supports both Python 2.x - Python (*2.x*) might still be handy for build scripts.footnote:[SCons supports both Python 2.x
and Python 3.x transparently. Basically there is no reason to stick to Python 2.x -- just the standard and Python 3.x transparently. Basically there is no reason to stick to Python 2.x -- just the standard
python is not yet switched on Debian/stable, and so we might miss out on some scripts.] python is not yet switched on Debian/stable, and so we might miss out on some scripts.]
- bash (some test scripts use bash specific extensions) - bash (some test scripts use bash specific extensions)
Build Tools Build Tools

2
doc/technical/build/LumieraDebianPackage.txt
View file

@ -6,7 +6,7 @@ The Lumiera Debian Package
//Menu: label Debian Package //Menu: label Debian Package
Since several of the Lumiera core developers run a Debian flavour as their primary development platform, Since several of the Lumiera core developers run a Debian flavour as their primary development platform,
it seems natural to care for the debian packaging of Lumiera ourselves. Moreover, we've declared it seems natural to care for the debian packaging of Lumiera ourselves. Moreover, we've declared
Debian/Stable to be our *reference platform* -- we'll provide any additionally required, more recent Debian/Stable to be our *reference platform* -- we'll provide any additionally required, more recent
packages through our own link:http://Lumiera.org/debian[Debian Apt-Repository] (Debian depot). packages through our own link:http://Lumiera.org/debian[Debian Apt-Repository] (Debian depot).

10
doc/technical/build/SCons.txt
View file

@ -32,7 +32,7 @@ That's why, if you rely on any system PATHs or environment variables -- you need
those settings explicitly in your build definition. those settings explicitly in your build definition.
.SConstruct .SConstruct
when SCons executes, it performs a build definition python script written by the user. when SCons executes, it performs a build definition python script written by the user.
By convention, this main script is called 'SConstruct' and is located in the root of the source tree. By convention, this main script is called 'SConstruct' and is located in the root of the source tree.
It is a full featured Python module executed within a specifically prepared environment. It is a full featured Python module executed within a specifically prepared environment.
@ -46,7 +46,7 @@ the sub-trees of the project.
The SCons buildsystem revolves around the metaphor of a _Builder_. This is a SCons object that you explicitly The SCons buildsystem revolves around the metaphor of a _Builder_. This is a SCons object that you explicitly
invoke from the scripts to _define_ that there is something to build, transforming a _source_ into a _target_. invoke from the scripts to _define_ that there is something to build, transforming a _source_ into a _target_.
So the target depends on the sources, and typically those _source nodes_ were created by previous builder invocations. So the target depends on the sources, and typically those _source nodes_ were created by previous builder invocations.
The power of SCons is in the fact that dependencies are tracked automatically. When source files change, the system The power of SCons is in the fact that dependencies are tracked automatically. When source files change, the system
is able to derive which targets to rebuild. is able to derive which targets to rebuild.
.Scanner .Scanner
@ -134,7 +134,7 @@ in SVG and in UML.
.the target directory .the target directory
This is where the results of the build process are created. Lumiera is organised into a This is where the results of the build process are created. Lumiera is organised into a
_self contained folder structure_. As long as the relative locations, as found within +target/+, _self contained folder structure_. As long as the relative locations, as found within +target/+,
are kept intact, the Application will be able to start up and find all its resources. Consequently, are kept intact, the Application will be able to start up and find all its resources. Consequently,
there is no need to ``install'' Lumiera (and the ``install'' target just copies this folder structure there is no need to ``install'' Lumiera (and the ``install'' target just copies this folder structure
into the standard installation locations of a typical Unix system) into the standard installation locations of a typical Unix system)
@ -145,11 +145,11 @@ So, for the time being, we're just building in-tree. Apologies for that.
Invoking the Build Invoking the Build
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~
All of the build process is launched through the `scons` python script, usually installed into All of the build process is launched through the `scons` python script, usually installed into
`/usr/bin` when installing the SCons package onto the system. Just invoking `/usr/bin` when installing the SCons package onto the system. Just invoking
scons -h scons -h
prints a summary of all custom options, targets and toggles defined for our build. prints a summary of all custom options, targets and toggles defined for our build.
Targets Targets

8
doc/technical/code/c++11.txt
View file

@ -68,12 +68,12 @@ funny (char c)
using Funky = function<uint(char)>; // <1> using Funky = function<uint(char)>; // <1>
int int
main (int, char**) main (int, char**)
{ {
Funky fun(funny); // <2> Funky fun(funny); // <2>
Funky empty; // <3> Funky empty; // <3>
cout << "ASCII 'A' = " << fun('A'); cout << "ASCII 'A' = " << fun('A');
cout << " defined: " << bool(fun) // <4> cout << " defined: " << bool(fun) // <4>
<< " undefd; " << bool(empty) << " undefd; " << bool(empty)
@ -207,7 +207,7 @@ September 2014::
which means we're using *GCC-4.7* and *CLang 3.0*. While these compilers both provide a roughly complete which means we're using *GCC-4.7* and *CLang 3.0*. While these compilers both provide a roughly complete
C++11 support, a lot of fine points were discovered in the follow-up versions of the compilers and standard C++11 support, a lot of fine points were discovered in the follow-up versions of the compilers and standard
library -- current versions being GCC-3.9 and CLang 3.4 library -- current versions being GCC-3.9 and CLang 3.4
* GCC-4.7 was too liberal and sloppy at some points, where 4.8 rightfully spotted conceptual problems * GCC-4.7 was too liberal and sloppy at some points, where 4.8 rightfully spotted conceptual problems
* CLang 3.0 turns out to be really immature and even segfaults on some combinations of new language features * CLang 3.0 turns out to be really immature and even segfaults on some combinations of new language features
* Thus we've got some kind of a _situation:_ We need to hold back further modernisation and just hope that * Thus we've got some kind of a _situation:_ We need to hold back further modernisation and just hope that
@ -222,7 +222,7 @@ February 2020::
our »reference system« (platform) is Debian/Buster from now on. our »reference system« (platform) is Debian/Buster from now on.
We have switched to **C\+\+17** and use (even require) GCC-8 or CLang 7 -- we can expect solid support We have switched to **C\+\+17** and use (even require) GCC-8 or CLang 7 -- we can expect solid support
for all C++17 features. for all C++17 features.
* still running into problems with perfect forwarding in combination with overload resolution; * still running into problems with perfect forwarding in combination with overload resolution;
not clear if this is a shortcoming of current compilers, or the current shape of the language not clear if this is a shortcoming of current compilers, or the current shape of the language

8
doc/technical/code/codingGuidelines.txt
View file

@ -20,7 +20,7 @@ The Lumiera project uses GNU indentation style with slight adaptations.
topics into a single line...] topics into a single line...]
- originally, GNU style focused on plain-C code. + - originally, GNU style focused on plain-C code. +
We thus apply some relaxations and clarifications ... We thus apply some relaxations and clarifications ...
* the braces for a class scope are indented by 2 spaces * the braces for a class scope are indented by 2 spaces
* the access modifiers start at this brace level, while all declarations and definitions * the access modifiers start at this brace level, while all declarations and definitions
within the class are again indented by 2 spaces within the class are again indented by 2 spaces
@ -30,12 +30,12 @@ The Lumiera project uses GNU indentation style with slight adaptations.
* the line breaking rules are relaxed. Definitions and statements may be written as single line, * the line breaking rules are relaxed. Definitions and statements may be written as single line,
provided that the length remains below 110 chars and the result _remains legible_. provided that the length remains below 110 chars and the result _remains legible_.
More specifically... More specifically...
** function declarations may be written in one line ** function declarations may be written in one line
** same for definitions with just a single statement in the body ** same for definitions with just a single statement in the body
** same for simple if-statements without else-branch. ** same for simple if-statements without else-branch.
** If in doubt however, we prefer to wrap the lines. ** If in doubt however, we prefer to wrap the lines.
* it is OK to write if-then-else without braces, but only as long as the structure * it is OK to write if-then-else without braces, but only as long as the structure
is uttermost clear and poses no danger for maintenance. Use your common sense on this one. is uttermost clear and poses no danger for maintenance. Use your common sense on this one.
Often, a ternary operator is a viable alternative. When a `?` ... `:` becomes long and Often, a ternary operator is a viable alternative. When a `?` ... `:` becomes long and
@ -50,7 +50,7 @@ The Lumiera project uses GNU indentation style with slight adaptations.
* the body of λ-functions is indented beyond the capture clause, i.e. it is rather * the body of λ-functions is indented beyond the capture clause, i.e. it is rather
starkly offset with respect to the regular code. When capture clauses become complicated starkly offset with respect to the regular code. When capture clauses become complicated
beyond just a short list of names -- especially when including initialisers -- they are beyond just a short list of names -- especially when including initialisers -- they are
preferably written on a separate line, directly above the argument list in parenthesis preferably written on a separate line, directly above the argument list in parenthesis
* the opening brace of namespaces is placed on the same line. Optionally, the namespace * the opening brace of namespaces is placed on the same line. Optionally, the namespace
body may be indented, as long as this helps underpinning the nesting structure. But body may be indented, as long as this helps underpinning the nesting structure. But
there is no need to use 3 indents on a 3 level nested namespace. One level is enough there is no need to use 3 indents on a 3 level nested namespace. One level is enough

6
doc/technical/code/gtk/layout.txt
View file

@ -51,7 +51,7 @@ natural:: the extension necessary to use the widget properly, without wasting sc
size request mode:: size request mode::
by implementing ´get_request_mode_vfunc()`, the widget defines how its allocation shall be treated... by implementing ´get_request_mode_vfunc()`, the widget defines how its allocation shall be treated...
- `SIZE_REQUEST_HEIGHT_FOR_WIDTH` : start with a desired width and then accommodate the vertical extension - `SIZE_REQUEST_HEIGHT_FOR_WIDTH` : start with a desired width and then accommodate the vertical extension
- `SIZE_REQUEST_WIDTH_FOR_HEIGHT` : start with a desired height and expand horizontally as needed - `SIZE_REQUEST_WIDTH_FOR_HEIGHT` : start with a desired height and expand horizontally as needed
- `SIZE_REQUEST_CONSTANT_SIZE` (this seems to be there for sake of completeness, but is typically - `SIZE_REQUEST_CONSTANT_SIZE` (this seems to be there for sake of completeness, but is typically
@ -66,8 +66,8 @@ shifting the pixel coordinates. From the allocation worked out thus far, all hea
proper drawing is then _subtracted,_ and the resulting bare allocation is passed to the widget through proper drawing is then _subtracted,_ and the resulting bare allocation is passed to the widget through
the function `gtk_widget_set_allocation()`, which also invokes the `Gtk::Widget::on_size_allocate()` the function `gtk_widget_set_allocation()`, which also invokes the `Gtk::Widget::on_size_allocate()`
hook. Note that the fully expanded allocation is not stored; GTK just assumes that widgets will hook. Note that the fully expanded allocation is not stored; GTK just assumes that widgets will
draw themselves properly, including their decorations, thereby possibly using extended screen space. draw themselves properly, including their decorations, thereby possibly using extended screen space.
Minimal vs. natural size request Minimal vs. natural size request
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In short: you need to define both, while the natural size request is more relevant in most cases. In short: you need to define both, while the natural size request is more relevant in most cases.

4
doc/technical/code/index.txt
View file

@ -30,8 +30,8 @@ To give a delineation to the other side, a constantly growing project might even
reach the point where the actual coding of new functionality makes up less than 25% reach the point where the actual coding of new functionality makes up less than 25%
of the overall work required. More people might be involved than anyone can recall or of the overall work required. More people might be involved than anyone can recall or
overlook reasonably. A code size of 1 Million LoC seems to exceed any kind of sufficiently overlook reasonably. A code size of 1 Million LoC seems to exceed any kind of sufficiently
precise imagination. From that point on, a rigorosely formalsed organisation is vital precise imagination. From that point on, a rigorously formalised organisation is vital
to keep such a *large scale project* from floundering. to keep such a *large scale project* from floundering.
//// ////
Conventions Conventions

6
doc/technical/howto/DebugGdbPretty.txt
View file

@ -52,15 +52,15 @@ using std::cout;
using std::endl; using std::endl;
int int
main (int, char**) main (int, char**)
{ {
std::string str = "hullo wöld"; std::string str = "hullo wöld";
std::vector<int> vec (1000); std::vector<int> vec (1000);
for (uint i = 0; i < vec.size(); ++i) for (uint i = 0; i < vec.size(); ++i)
vec[i] = i; vec[i] = i;
cout << str << "\n.gulp.\n"; cout << str << "\n.gulp.\n";
return 0; return 0;
} }

2
doc/technical/howto/HashFunctions.txt
View file

@ -101,7 +101,7 @@ Hash-chaining
~~~~~~~~~~~~~ ~~~~~~~~~~~~~
We use a dedicated function `lib::hash::combine(s,h)` to join several source(component) hashes. We use a dedicated function `lib::hash::combine(s,h)` to join several source(component) hashes.
This usage pattern was pioneered by Boost and is based on the This usage pattern was pioneered by Boost and is based on the
https://github.com/aappleby/smhasher/blob/master/src/MurmurHash2.cpp[Murmur-2.64A] hash algorithm. https://github.com/aappleby/smhasher/blob/master/src/MurmurHash2.cpp[Murmur-2.64A] hash algorithm.
WARNING: as of [yellow-background]#11/2024#, portability of hash values is an unresolved issue; WARNING: as of [yellow-background]#11/2024#, portability of hash values is an unresolved issue;
this code does not work on 32bit systems https://issues.lumiera.org/ticket/722#comment:10[see #722] this code does not work on 32bit systems https://issues.lumiera.org/ticket/722#comment:10[see #722]

2
doc/technical/howto/UsingBoost.txt
View file

@ -59,7 +59,7 @@ The `boost::operators` library allows to build families of types/objects with co
algebraic properties. Especially, it eases building _equality comparable_, _totally ordered_, algebraic properties. Especially, it eases building _equality comparable_, _totally ordered_,
_additive_, _mulitplicative_ entities: You're just required to provide some basic operators _additive_, _mulitplicative_ entities: You're just required to provide some basic operators
and the library will define all sorts of additional operations to care for the logical and the library will define all sorts of additional operations to care for the logical
consequences, removing the need for writing lots of boilerplate code. consequences, removing the need for writing lots of boilerplate code.
.lexical_cast .lexical_cast
Converting numerics to string and back without much ado, as you'd expect it from any decent language. Converting numerics to string and back without much ado, as you'd expect it from any decent language.

4
doc/technical/howto/backporting.txt
View file

@ -57,7 +57,7 @@ From this point on, we can switch configuration by
---- ----
sudo update-alternatives --config gcc sudo update-alternatives --config gcc
---- ----
Building on Mint 17.2 (Rafaela) -- gcc and Libstdc++ 4.9 Building on Mint 17.2 (Rafaela) -- gcc and Libstdc++ 4.9
@ -73,7 +73,7 @@ which is indeed linked against the 4.9 libraries. Stay away from Clang on Mint f
Transcript from a build session on a ``pristine'' Mint 17.2 installation: Transcript from a build session on a ``pristine'' Mint 17.2 installation:
* add the following to your `/etc/apt/sources.list` * add the following to your `/etc/apt/sources.list`
+ +
---- ----
deb https://lumiera.org/debian/ rafaela experimental deb https://lumiera.org/debian/ rafaela experimental
deb-src https://lumiera.org/debian/ rafaela experimental deb-src https://lumiera.org/debian/ rafaela experimental

6
doc/technical/howto/crackNuts.txt
View file

@ -18,7 +18,7 @@ Mathematics
- the simple case for _linear regression_ is also implemented there - the simple case for _linear regression_ is also implemented there
- Gnuplot provides also common statistics functions, which may come in handy when the - Gnuplot provides also common statistics functions, which may come in handy when the
goal is anyway to create a visualisation (-> see <<_investigation,below>>) goal is anyway to create a visualisation (-> see <<_investigation,below>>)
@ -126,7 +126,7 @@ IterExplorer::
- can be used to build complex layered search- and evaluation schemes - can be used to build complex layered search- and evaluation schemes
STL-adaptors:: STL-adaptors::
A set of convenience functions like `eachElm(CON)` -- available in 'iter-adapter-stl.hpp'. A set of convenience functions like `eachElm(CON)` -- available in 'iter-adapter-stl.hpp'.
Also allows to iterate _each key_ or _value_, and to take snapshots Also allows to iterate _each key_ or _value_, and to take snapshots
IterSource:: IterSource::
This is a special Lumiera iterator implementation which delegates through a virtual (OO) interface. This is a special Lumiera iterator implementation which delegates through a virtual (OO) interface.
Thus the source of the data can be abstracted away and switched transparently at runtime. Thus the source of the data can be abstracted away and switched transparently at runtime.
@ -170,7 +170,7 @@ build-from-anything::
- prevent shadowing of _automatically generated copy operations._ - prevent shadowing of _automatically generated copy operations._
See https://issues.lumiera.org/ticket/963[#963]. Based on the ``disable if'' SFINAE technique. See https://issues.lumiera.org/ticket/963[#963]. Based on the ``disable if'' SFINAE technique.
A ready-made templated typedef `lib::meta::disable_if_self` can be found in 'lib/meta/util.hpp' A ready-made templated typedef `lib::meta::disable_if_self` can be found in 'lib/meta/util.hpp'
Variadics Variadics

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

@ -28,7 +28,7 @@ The menu generation and display is comprised of several parts working together
menu generator script is invoked menu generator script is invoked
. the +menugen+ python script walks the subdirectories to discover possible . the +menugen+ python script walks the subdirectories to discover possible
menu contents. It visits Asciidoc source files (`*.txt`) and picks up menu contents. It visits Asciidoc source files (`*.txt`) and picks up
- the location / URL - the location / URL
- the title - the title
- special `//MENU:` directives embedded in Asciidoc comments - special `//MENU:` directives embedded in Asciidoc comments
@ -84,7 +84,7 @@ options to deal with special cases. Adjustments can be done on several levels:
script. This code generation is driven by a classical recursive tree visitation script. This code generation is driven by a classical recursive tree visitation
over the menu data structure built up thus far; code generation hooks are called over the menu data structure built up thus far; code generation hooks are called
on each tree leaf and when entering and leaving inner nodes (submenu nodes). on each tree leaf and when entering and leaving inner nodes (submenu nodes).
* the highlighting is done by the client side JavaScript in +js/menu.js+ -- * the highlighting is done by the client side JavaScript in +js/menu.js+ --
mostly just by _adding or removing CSS classes_ dynamically. The actual styling mostly just by _adding or removing CSS classes_ dynamically. The actual styling
of the menu entries is thus largely independent of the menu generation (but of of the menu entries is thus largely independent of the menu generation (but of
course the CSS selectors must line up with the basic structure of the generated course the CSS selectors must line up with the basic structure of the generated
@ -136,11 +136,11 @@ def addPredefined():
root = Node(TREE_ROOT, label='Lumiera') # <1> root = Node(TREE_ROOT, label='Lumiera') # <1>
proj = root.linkChild('project') # <2> proj = root.linkChild('project') # <2>
proj.linkChild('faq') proj.linkChild('faq')
proj.prependChild ('screenshots') # <3> proj.prependChild ('screenshots') # <3>
proj.putChildLast ('press') proj.putChildLast ('press')
proj.putChildAfter('faq', refPoint=Node('screenshots')) # <4> proj.putChildAfter('faq', refPoint=Node('screenshots')) # <4>
proj.link('https://issues.lumiera.org/roadmap',label="Roadmap (Trac)") # <5> proj.link('https://issues.lumiera.org/roadmap',label="Roadmap (Trac)") # <5>
Node('rfc').sortChildren() Node('rfc').sortChildren()
-------------------------------------------------------------------------- --------------------------------------------------------------------------
@ -187,7 +187,7 @@ supported placement directives
putChildLast(id) [attach] child <id> move child to current end of list putChildLast(id) [attach] child <id> move child to current end of list
appendChild(id) [append] child <id> appendChild(id) [append] child <id>
putChildFirst(id) move child to current list start putChildFirst(id) move child to current list start
prependChild(id) prepend [child] <id> prependChild(id) prepend [child] <id>
putChildAfter(id,ref) [attach|put] child <id> after <ref> move child after the given ref entry putChildAfter(id,ref) [attach|put] child <id> after <ref> move child after the given ref entry
link(url[,id][,label]) [child <id>] link ::<url>[<label>] attach an entry, holding an external link link(url[,id][,label]) [child <id>] link ::<url>[<label>] attach an entry, holding an external link
Node(<id>,label=<lbl>) label|title <lbl> define the visible text in the menu entry Node(<id>,label=<lbl>) label|title <lbl> define the visible text in the menu entry
@ -195,8 +195,8 @@ supported placement directives
enable(False) off|disable|deactivate make node passive; any children/parents added later are ignored enable(False) off|disable|deactivate make node passive; any children/parents added later are ignored
enable([True]) on|active|activate make node active again (this is the default) enable([True]) on|active|activate make node active again (this is the default)
detach() detach cut away any parents and children, disable the node detach() detach cut away any parents and children, disable the node
discover(srcdirs=...) include dir <token>[,<token>] instead of current dir, retrieve children from other dirs (relative) discover(srcdirs=...) include dir <token>[,<token>] instead of current dir, retrieve children from other dirs (relative)
discover(includes=...) include <token>[,<token>] explicitly use the listed elements as children discover(includes=...) include <token>[,<token>] explicitly use the listed elements as children
discover(excludes=...) exclude <token>[,<token>] after discovering, filter names matching the <token> (without extension) discover(excludes=...) exclude <token>[,<token>] after discovering, filter names matching the <token> (without extension)
-------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------
@ -206,7 +206,7 @@ commandline options
The behaviour of the +menugen+ script can be influenced by some options: The behaviour of the +menugen+ script can be influenced by some options:
predefined:: using the built-in predefined nodes predefined:: using the built-in predefined nodes
scan:: discover nodes scan:: discover nodes
debug:: dump data structure after discovery debug:: dump data structure after discovery
text:: generate plaintext version of the menu text:: generate plaintext version of the menu
webpage:: actually generate HTML / JavaScript webpage:: actually generate HTML / JavaScript
@ -229,7 +229,7 @@ syntax of the specifications; it was tested to generate suitable HTML and CSS.
The syntactic elements where then added as a collection of parser or matcher objects, The syntactic elements where then added as a collection of parser or matcher objects,
each with the ability to recognise and implement one kind of placement specification. each with the ability to recognise and implement one kind of placement specification.
Each such +Placement+ subclass exposes an +acceptVerb()+ function for handling invocations Each such +Placement+ subclass exposes an +acceptVerb()+ function for handling invocations
of the internal DSL functions, and an +acceptDSL()+ function to parse and accept a of the internal DSL functions, and an +acceptDSL()+ function to parse and accept a
`//Menu:` line from some Asciidoc source file. This approach makes adding further `//Menu:` line from some Asciidoc source file. This approach makes adding further
configuration options simple. configuration options simple.
@ -267,7 +267,7 @@ Known issues
generated as +parentPath/fileID+, to avoid mixing up similarly named generated as +parentPath/fileID+, to avoid mixing up similarly named
files in different directories. (The NodeIndex allows to retrieve files in different directories. (The NodeIndex allows to retrieve
a node just by its bare ID, without path anyway) a node just by its bare ID, without path anyway)
* no escaping: currently any variable text is written to the generated * no escaping: currently any variable text is written to the generated
HTML without any sanitising or escaping. This might be a security issue, HTML without any sanitising or escaping. This might be a security issue,
especially because Git pushes immediately trigger menu generation. especially because Git pushes immediately trigger menu generation.
* the method Node.matches() is implemented sloppily: it uses just a mutual * the method Node.matches() is implemented sloppily: it uses just a mutual

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

@ -92,7 +92,7 @@ to help with automating the build and test execution, test code should adhere to
these are linked together into a single testrunner, which is also linked against the application core. these are linked together into a single testrunner, which is also linked against the application core.
The resulting executable 'test-suite' is able to invoke any of the test classes in The resulting executable 'test-suite' is able to invoke any of the test classes in
isolation, or a group / category of tests. + isolation, or a group / category of tests. +
* simple plain-C tests (names starting with 'test-*') are grouped into several directories thematically, * simple plain-C tests (names starting with 'test-*') are grouped into several directories thematically,
and linked according to the application layer. Each of those simple tests needs to be self contained and linked according to the application layer. Each of those simple tests needs to be self contained
and provide a main method. and provide a main method.
@ -114,25 +114,25 @@ using std::cout;
using std::endl; using std::endl;
namespace test { namespace test {
class HelloWorld_test class HelloWorld_test
: public Test : public Test
{ {
virtual void virtual void
run (Arg) run (Arg)
{ {
greeting(); greeting();
} }
void void
greeting() greeting()
{ {
cout << "goodbye cruel world..." <<endl; cout << "goodbye cruel world..." <<endl;
} }
}; };
/** Register this test class to be invoked in some test groups (suites) */ /** Register this test class to be invoked in some test groups (suites) */
LAUNCHER (HelloWorld_test, "unit function common"); LAUNCHER (HelloWorld_test, "unit function common");
} }
---------------------------------------------------------------- ----------------------------------------------------------------
@ -151,7 +151,7 @@ invoking a testrunner executable
The class `test::TestOption` predefines a boost-commandlineparser to support the following options: The class `test::TestOption` predefines a boost-commandlineparser to support the following options:
[width="90%",cols="<.<,^4"] [width="90%",cols="<.<,^4"]
|==== |====
2+<| `./test-suite --group <groupID> [testID [arguments...]]` 2+<| `./test-suite --group <groupID> [testID [arguments...]]`
|`--help` | options summary |`--help` | options summary
|`-g <groupID>` | run all tests from this group as suite. If missing, ALL tests will be included |`-g <groupID>` | run all tests from this group as suite. If missing, ALL tests will be included
@ -159,7 +159,7 @@ The class `test::TestOption` predefines a boost-commandlineparser to support the
|`--describe`| print all registered tests to stdout in a format suited for use with test.sh |`--describe`| print all registered tests to stdout in a format suited for use with test.sh
|==== |====
Further commandline arguments are deliverd to a single testcase only if you specify a `testID`. Further commandline arguments are deliverd to a single testcase only if you specify a `testID`.
Otherwise, all commandline arguments remaining after options parsing will be discarded and all tests of the suite Otherwise, all commandline arguments remaining after options parsing will be discarded and all tests of the suite
ill be run with an commandline vector of `size()==0` ill be run with an commandline vector of `size()==0`
@ -175,7 +175,7 @@ Options for running the Test Script
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- Valgrind can be disabled with `VALGRINDFLAGS=DISABLE` - Valgrind can be disabled with `VALGRINDFLAGS=DISABLE`
- one may define `TESTMODE` containing any one of the following strings: - one may define `TESTMODE` containing any one of the following strings:
* `FAST` only run tests which failed recently * `FAST` only run tests which failed recently
* `FIRSTFAIL` abort the tests at the first failure * `FIRSTFAIL` abort the tests at the first failure
@ -187,8 +187,8 @@ Options for running the Test Script
. running a very fast check while hacking:: . running a very fast check while hacking::
(cd target; TESTSUITES=41 VALGRINDFLAGS=DISABLE TESTMODE=FAST+FIRSTFAIL ../tests/test.sh) (cd target; TESTSUITES=41 VALGRINDFLAGS=DISABLE TESTMODE=FAST+FIRSTFAIL ../tests/test.sh)
. invoking the buildsystem, rebuilding if necessary, then invoking just the steam-layer test collections:: . invoking the buildsystem, rebuilding if necessary, then invoking just the steam-layer test collections::
scons VALGRIND=false TESTSUITES=4 check scons VALGRIND=false TESTSUITES=4 check

6
doc/technical/infra/debianDepot.txt
View file

@ -90,7 +90,7 @@ this will __re__generate all of the indices, signatures and metadata of the 'squ
Configuration Configuration
~~~~~~~~~~~~~ ~~~~~~~~~~~~~
The current configuration and the state of the Debian Depot index files is tracked The current configuration and the state of the Debian Depot index files is tracked
is a separate branch in the is a separate branch in the
link:http://git.lumiera.org/gitweb?p=debian/lumiera;a=shortlog;h=refs/heads/depot[debian/lumiera] link:http://git.lumiera.org/gitweb?p=debian/lumiera;a=shortlog;h=refs/heads/depot[debian/lumiera]
repository. (Note: this is a somewhat unconventional setup, insofar the 'depot' branch tracks repository. (Note: this is a somewhat unconventional setup, insofar the 'depot' branch tracks
a directory tree completely separete from the main lumiera source tree tracked by the deb branch; a directory tree completely separete from the main lumiera source tree tracked by the deb branch;
@ -104,10 +104,10 @@ want to create _yet another not so useful Git repository..._)
.some special details to note in our setup .some special details to note in our setup
======================================================================================================================= =======================================================================================================================
- each block in the 'distributions' file defines a repository for a ``distribution'' (e.g. Jessie, Trusty, Rafaela). - each block in the 'distributions' file defines a repository for a ``distribution'' (e.g. Jessie, Trusty, Rafaela).
Within such a repo, there are sections named 'Components'. Within such a repo, there are sections named 'Components'.
- The _override_ files mentioned in the configuration allow to overwrite / replace arbitrary fields in the metadata of - The _override_ files mentioned in the configuration allow to overwrite / replace arbitrary fields in the metadata of
all packages added to that distribution. all packages added to that distribution.
- In this setup, we enabled the 'tracking' function: thereby reprepro will keep track of the dependencies between - In this setup, we enabled the 'tracking' function: thereby reprepro will keep track of the dependencies between
binary packages, signatures, debianisation patches and original upstream tarballs. Never packages overwirte older binary packages, signatures, debianisation patches and original upstream tarballs. Never packages overwirte older
ones -- _at any time there is at most one version of a package in the repository._ Parts not referred to anymore ones -- _at any time there is at most one version of a package in the repository._ Parts not referred to anymore
are automatically discareded. In our configuration, they are moved into the 'morguedir' are automatically discareded. In our configuration, they are moved into the 'morguedir'

4
doc/technical/library/DiffFramework.txt
View file

@ -44,7 +44,7 @@ diff verb::
when applied consuming the input sequence, will produce the target sequence of the diff. when applied consuming the input sequence, will produce the target sequence of the diff.
diff application:: diff application::
the process of consuming a diff (sequence of diff verbs), with the goal to produce some effect at the the process of consuming a diff (sequence of diff verbs), with the goal to produce some effect at the
_target_ of diff application. Typically we want to apply a diff to a data sequence, to mutate it _target_ of diff application. Typically we want to apply a diff to a data sequence, to mutate it
into a new shape, conforming with the shape of the diff's ``target sequence'' into a new shape, conforming with the shape of the diff's ``target sequence''
@ -52,7 +52,7 @@ tree mutator::
a customisable intermediary, allowing to apply a diff sequence against an opaque data structure. a customisable intermediary, allowing to apply a diff sequence against an opaque data structure.
For the purpose of diff application, the TreeMutator serves as target object, while in fact it is itself For the purpose of diff application, the TreeMutator serves as target object, while in fact it is itself
attached by a _binding_ to the actual target data structure, which remains a hidden implementation detail. attached by a _binding_ to the actual target data structure, which remains a hidden implementation detail.
This allows to manipulate the target data structure without knowing its concrete representation. This allows to manipulate the target data structure without knowing its concrete representation.
diff generator:: diff generator::
a facility producing a diff, which is a sequence of diff verbs. a facility producing a diff, which is a sequence of diff verbs.

4
doc/technical/stage/style/Timeline.txt
View file

@ -79,7 +79,7 @@ slopes::
header:: header::
The track header area to the left of the timeline display is built up „conventionally“, by nested widgets The track header area to the left of the timeline display is built up „conventionally“, by nested widgets
+ +
- the container spanning the total height of the timeline display (moving with the scrollbar): `.timeline__head` - the container spanning the total height of the timeline display (moving with the scrollbar): `.timeline__head`
- at the top sits a small navigator control with class `.timeline__navi` - at the top sits a small navigator control with class `.timeline__navi`
- the remaining space below is taken by a »Patchbay« container with class `.timeline__pbay` - the remaining space below is taken by a »Patchbay« container with class `.timeline__pbay`
fork head:: fork head::
@ -134,4 +134,4 @@ image:{imgd}/TimelineCSS.png["Demonstration of CSS for custom drawing"]
[red]##TODO 3/2023:## [red]##TODO 3/2023:##
- [red]##should also document the selector for an actual Clip element in a concrete timeline## - [red]##should also document the selector for an actual Clip element in a concrete timeline##

14
doc/user/intro/Glossary.txt
View file

@ -61,9 +61,9 @@ NOTE: Draft, please help rephrase/review and shorten explanations!
anchor:InputDevice[] link:#InputDevice[->]Input Device:: anchor:InputDevice[] link:#InputDevice[->]Input Device::
Some hardware controler, like an extra keyboard, midi mixer, Jog, .. Some hardware controler, like an extra keyboard, midi mixer, Jog, ..
TODO: we still need to decide on whether we can treat the main keyboard TODO: we still need to decide on whether we can treat the main keyboard
as special global state or whether we can handle the keyboard as a generic as special global state or whether we can handle the keyboard as a generic
input devide. input devide.
anchor:LowLevelModel[] link:#LowLevelModel[->]Low Level Model:: anchor:LowLevelModel[] link:#LowLevelModel[->]Low Level Model::
The generated Processing Graph, to be ``performed'' within the engine The generated Processing Graph, to be ``performed'' within the engine
@ -80,7 +80,7 @@ NOTE: Draft, please help rephrase/review and shorten explanations!
A specification denoting where to connect the output of a pipe. A specification denoting where to connect the output of a pipe.
It might either be given _absoulutely_, i.e as a Pipe-ID, It might either be given _absoulutely_, i.e as a Pipe-ID,
or by a _relative_ or an _indirect_ specification or by a _relative_ or an _indirect_ specification
anchor:OutputManager[] link:#OutputManager[->]OutputManager:: anchor:OutputManager[] link:#OutputManager[->]OutputManager::
Manages all external outputs of the application and provides output Manages all external outputs of the application and provides output
slots targetting these. slots targetting these.
@ -126,7 +126,7 @@ NOTE: Draft, please help rephrase/review and shorten explanations!
The top-level context in which all editing is done over an extended The top-level context in which all editing is done over an extended
period of time. A Project can be saved and re-opened. It consists of period of time. A Project can be saved and re-opened. It consists of
various things a user is working on: user-information, assets, state and various things a user is working on: user-information, assets, state and
objects to be edited. objects to be edited.
anchor:RenderTask[] link:#RenderTask[->]RenderTask:: anchor:RenderTask[] link:#RenderTask[->]RenderTask::
This is basically a PlayController, but directly collects output without This is basically a PlayController, but directly collects output without
@ -138,7 +138,7 @@ NOTE: Draft, please help rephrase/review and shorten explanations!
some logic and knowledge about handling/converting data. This may be some logic and knowledge about handling/converting data. This may be
configued with this Rules System. Typically Lumiera will provide sane configued with this Rules System. Typically Lumiera will provide sane
defaults for most purposes but may extended/refined for site specific defaults for most purposes but may extended/refined for site specific
things. things.
anchor:Sequence[] link:#Sequence[->]Sequence:: anchor:Sequence[] link:#Sequence[->]Sequence::
A collection of *Media Objects* (clips, effects, transitions, labels, A collection of *Media Objects* (clips, effects, transitions, labels,
@ -213,7 +213,7 @@ NOTE: Draft, please help rephrase/review and shorten explanations!
elements contained within this track, unfold nested tracks and so on. elements contained within this track, unfold nested tracks and so on.
To a large extent, it corresponds to the placement of this track and To a large extent, it corresponds to the placement of this track and
allows to manipulate this placement allows to manipulate this placement
- *TODO*: better term for this - *TODO*: better term for this
- Note by Ichthyo: while I like the term "patchbay", my concern with - Note by Ichthyo: while I like the term "patchbay", my concern with
this is that it has already a very specific meaning in audio this is that it has already a very specific meaning in audio

4
doc/user/tutorials/DebianBuilding.txt
View file

@ -31,7 +31,7 @@ relies on some other libraries, which somehow need to be installed on your syste
building from source package building from source package
---------------------------- ----------------------------
NOTE: Generally speaking, operations which _modify_ the installation/configuration of your NOTE: Generally speaking, operations which _modify_ the installation/configuration of your
linux system require root permissions. To the contrary, just _building_ a package linux system require root permissions. To the contrary, just _building_ a package
should _not_ be done as root. should _not_ be done as root.
. add a suitable source line to your *Apt configuration* ('/etc/apt/sources.lst') . add a suitable source line to your *Apt configuration* ('/etc/apt/sources.lst')
@ -179,7 +179,7 @@ It is recommended to build with normal user permissions (not as root).
necessary for building the denoted package. (however, it does _not_ download the necessary for building the denoted package. (however, it does _not_ download the
source package itself) source package itself)
- 'sudo dpkg -i' BIN-PACKAGE.deb finally installs the result of your building efforts. - 'sudo dpkg -i' BIN-PACKAGE.deb finally installs the result of your building efforts.
Note, if several packages depend on each other, you need to give them all as list Note, if several packages depend on each other, you need to give them all as list
in a single command invocation. in a single command invocation.
After having prepared the sources this way, you need to step into the root of the After having prepared the sources this way, you need to step into the root of the

8
doc/user/tutorials/building.txt
View file

@ -54,7 +54,7 @@ in addition to the following tools and libraries:
* link:http://www.boost.org/[Boost libraries] * link:http://www.boost.org/[Boost libraries]
* link:http://gmerlin.sourceforge.net/[GAVL library] * link:http://gmerlin.sourceforge.net/[GAVL library]
* link:http://nobug.pipapo.org/[NoBug] (see below) * link:http://nobug.pipapo.org/[NoBug] (see below)
* Lumiera source code * Lumiera source code
The GUI depends on the following: The GUI depends on the following:
@ -83,7 +83,7 @@ Build Directory
You'll need to check out the source code in some directory or other. You'll also You'll need to check out the source code in some directory or other. You'll also
have to use this directory to build Lumiera. This could be a temporary have to use this directory to build Lumiera. This could be a temporary
directory, or some "workspace" directory below your home directory. We'll refer directory, or some "workspace" directory below your home directory. We'll refer
to this directory as _workspace directory_ . to this directory as _workspace directory_ .
Lumiera Specific Libraries Lumiera Specific Libraries
@ -110,7 +110,7 @@ NoBug: building and installing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
link:http://nobug.pipapo.org/[NoBug] is an instrumentation and diagnostics library. + link:http://nobug.pipapo.org/[NoBug] is an instrumentation and diagnostics library. +
Enter _workspace direcory_ as explained above. Enter _workspace direcory_ as explained above.
Get the NoBug source code: Get the NoBug source code:
------------------------------------------------------------ ------------------------------------------------------------
@ -140,7 +140,7 @@ the following shows how to build the latter
Version limitation:: Version limitation::
we rely on GTK-3 and thus need a compatible GDL-3. we rely on GTK-3 and thus need a compatible GDL-3.
There is a dependency on `xmlto`, which is an xml converter. To install on Debian: There is a dependency on `xmlto`, which is an xml converter. To install on Debian:
------------------------------------------------------------ ------------------------------------------------------------
apt-get install xmlto apt-get install xmlto

8
doc/user/tutorials/contributing.txt
View file

@ -184,7 +184,7 @@ tend to cause difficulties).
The line following your one line summary should be blank. Then on the third The line following your one line summary should be blank. Then on the third
line, you can begin your exposition in as much detail as you like on your line, you can begin your exposition in as much detail as you like on your
changes. changes.
Publishing Your Contribution Publishing Your Contribution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -197,18 +197,18 @@ Finally you can *push* your changes to the Lumiera server on the 'mob'
repository: repository:
------------------------------------------------------------ ------------------------------------------------------------
$ git push git://git.lumiera.org/lumiera/mob master:refs/heads/YOURNAME $ git push git://git.lumiera.org/lumiera/mob master:refs/heads/YOURNAME
------------------------------------------------------------ ------------------------------------------------------------
This creates a new branch +YOURNAME+ on the mob repository. This creates a new branch +YOURNAME+ on the mob repository.
Check that indeed your changes are public by visiting Check that indeed your changes are public by visiting
link:http://Lumiera.org/gitweb[the Git-Web]: + link:http://Lumiera.org/gitweb[the Git-Web]: +
The lumiera/mob repository should indicate The lumiera/mob repository should indicate
[green]#right now# as its ``Last Change'' entry. [green]#right now# as its ``Last Change'' entry.
Thereafter, notify the other developers on the mailing list and they may examine Thereafter, notify the other developers on the mailing list and they may examine
your code into the main project line. your code into the main project line.
Lumiera Communication Channels Lumiera Communication Channels

2
src/SConscript
View file

@ -33,7 +33,7 @@ env.SymLink('#$DESTDIR/bin/lumiera',env.path.installExe+'lumiera','../lib/lumier
# building Lumiera Plugins # building Lumiera Plugins
plugins = [] # currently none plugins = [] # currently none
# the Lumiera GTK GUI # the Lumiera GTK GUI

8
src/common/advice/advice.cpp
View file

@ -220,13 +220,13 @@ namespace advice {
{ {
Lock sync{this}; Lock sync{this};
if (!previousProvision && newProvision) if (not previousProvision and newProvision)
index_.addProvision (*newProvision); index_.addProvision (*newProvision);
else else
if (previousProvision && newProvision) if (previousProvision and newProvision)
index_.modifyProvision (*previousProvision, *newProvision); index_.modifyProvision (*previousProvision, *newProvision);
else else
if (previousProvision && !newProvision) if (previousProvision and not newProvision)
index_.removeProvision (*previousProvision); index_.removeProvision (*previousProvision);
discardEntry (unConst(previousProvision)); discardEntry (unConst(previousProvision));
@ -276,7 +276,7 @@ namespace advice {
void void
AdviceLink::releaseBuffer (void* buff, size_t siz) AdviceLink::releaseBuffer (void* buff, size_t siz)
{ {
aSys().releaseBuffer(buff, siz); aSys().releaseBuffer(buff, siz);
} }

10
src/common/advice/binding.cpp
View file

@ -54,7 +54,7 @@ namespace advice {
namespace{ // Implementation details namespace{ // Implementation details
const string matchSym = "(\\w+(?:[\\.\\-]\\w+)*)"; const string matchSym = "(\\w+(?:[\\.\\-]\\w+)*)";
const string matchArg = "\\(\\s*"+matchSym+"?\\s*\\)"; const string matchArg = "\\(\\s*"+matchSym+"?\\s*\\)";
regex findPredicate ("\\s*"+matchSym+"("+matchArg+")?\\s*,?"); ///< \c sym(arg), groups: [symbol, parenthesis, argument symbol] regex findPredicate ("\\s*"+matchSym+"("+matchArg+")?\\s*,?"); ///< \c sym(arg), groups: [symbol, parenthesis, argument symbol]
/** detect the _arity_ of an predicate, as matched by #findPredicate. /** detect the _arity_ of an predicate, as matched by #findPredicate.
@ -75,12 +75,12 @@ namespace advice {
void void
Binding::parse_and_append (Literal lit) Binding::parse_and_append (Literal lit)
{ {
string def(lit); string def(lit);
string::const_iterator end_of_last_match = def.begin(); string::const_iterator end_of_last_match = def.begin();
sregex_iterator end; sregex_iterator end;
sregex_iterator pos (def.begin(),def.end(), findPredicate, sregex_iterator pos (def.begin(),def.end(), findPredicate,
match_continuous); // continuous: don't allow garbage *not* matched by the RegExp match_continuous); // continuous: don't allow garbage *not* matched by the RegExp
while (pos != end) while (pos != end)
{ {
@ -91,8 +91,8 @@ namespace advice {
} }
if ( end_of_last_match !=def.end() if ( end_of_last_match !=def.end()
&& *end_of_last_match !='.' and *end_of_last_match !='.'
) // if the match did *not stop at the end of the pattern definition list ) // if the match did *not stop at the end of the pattern definition list
throw lumiera::error::Invalid ("Trailing garbage in binding pattern definition" ///////////////TICKET #197 should include the garbage, i.e. where the parsing stops throw lumiera::error::Invalid ("Trailing garbage in binding pattern definition" ///////////////TICKET #197 should include the garbage, i.e. where the parsing stops
, LUMIERA_ERROR_BINDING_PATTERN_SYNTAX); , LUMIERA_ERROR_BINDING_PATTERN_SYNTAX);
} }

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

@ -16,7 +16,7 @@
** A pattern to define and identify a specific attachment to the Advice system. ** A pattern to define and identify a specific attachment to the Advice system.
** This pattern is comprised of a predicate list and intended to be matched or unified ** This pattern is comprised of a predicate list and intended to be matched or unified
** against a similar pattern associated with the attachment of a possible collaboration partner. ** against a similar pattern associated with the attachment of a possible collaboration partner.
** Semantically, this list of atoms forms an conjunction of predicates to be resolved against ** Semantically, this list of atoms forms an conjunction of predicates to be resolved against
** similar predicates of the partner. Informally, when two entities attach to the Advice system, ** similar predicates of the partner. Informally, when two entities attach to the Advice system,
** each specifying a binding, they can be paired up if any condition included into the binding ** each specifying a binding, they can be paired up if any condition included into the binding
** holds true for both sides. ** holds true for both sides.
@ -125,8 +125,8 @@ namespace advice {
identical (Atom const& oa) const identical (Atom const& oa) const
{ {
return ari_ == oa.ari_ return ari_ == oa.ari_
&& sym_ == oa.sym_ and sym_ == oa.sym_
&& arg_ == oa.arg_; and arg_ == oa.arg_;
} }
int int
@ -141,7 +141,7 @@ namespace advice {
friend bool friend bool
operator< (Atom const& a1, Atom const& a2) operator< (Atom const& a1, Atom const& a2)
{ {
return a1.compare(a2) < 0; return a1.compare(a2) < 0;
} }
}; };

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

@ -122,14 +122,14 @@ namespace advice {
* by invoking the \c setSolution() function on the * by invoking the \c setSolution() function on the
* corresponding PointOfAdvice entity. * corresponding PointOfAdvice entity.
* *
* @note element \em identity is defined in terms of pointing * @note element \em identity is defined in terms of pointing
* to the same memory location of a POA (point of advice). * to the same memory location of a POA (point of advice).
* Thus e.g. #hasProvision means this index holds an entry * Thus e.g. #hasProvision means this index holds an entry
* pointing to exactly this given data entity. * pointing to exactly this given data entity.
* @note the implementation of modifying a Request entry * @note the implementation of modifying a Request entry
* explicitly relies on that definition of equality. * explicitly relies on that definition of equality.
* @note the diagnostic API is mainly intended for unit testing * @note the diagnostic API is mainly intended for unit testing
* and \em not implemented with focus on performance. * and \em not implemented with focus on performance.
* *
* \par Exception safety * \par Exception safety
* Adding new registrations might throw error::Fatal or bad_alloc. * Adding new registrations might throw error::Fatal or bad_alloc.
@ -325,7 +325,7 @@ namespace advice {
/* ==== Index Tables ===== */ /* ==== Index Tables ===== */
typedef unordered_map<HashVal, RequestCluster> RTable; typedef unordered_map<HashVal, RequestCluster> RTable;
typedef unordered_map<HashVal, ProvisionCluster> PTable; typedef unordered_map<HashVal, ProvisionCluster> PTable;
@ -350,7 +350,7 @@ namespace advice {
* Thus we can use the already modified Request to find * Thus we can use the already modified Request to find
* the old entry within the index pointing to this Request. * the old entry within the index pointing to this Request.
* @param oKey the binding hash value prior to modification * @param oKey the binding hash value prior to modification
*/ */
void void
modifyRequest (HashVal oKey, POA& entry) modifyRequest (HashVal oKey, POA& entry)
{ {
@ -459,11 +459,11 @@ namespace advice {
{ {
return provisionEntries_[hash_value(refEntry)].contains (refEntry); return provisionEntries_[hash_value(refEntry)].contains (refEntry);
} // note: even just lookup might create a new (empty) cluster; } // note: even just lookup might create a new (empty) cluster;
// thus the tables are defined as mutable // thus the tables are defined as mutable
private: private:
/** internal: sum element count over all /** internal: sum element count over all
* clusters in the given hashtable */ * clusters in the given hashtable */
template<class IT> template<class IT>
static size_t static size_t
@ -569,9 +569,9 @@ namespace advice {
verify_Entry (e,hash); verify_Entry (e,hash);
POA& request = *(e.second); POA& request = *(e.second);
const POA* solution (request.getSolution()); const POA* solution (request.getSolution());
if (solution && hasProvision(*solution)) if (solution and hasProvision (*solution))
{ {
POA* currentSolution = provisionEntries_[hash].find_latest_solution (request); POA* currentSolution = provisionEntries_[hash].find_latest_solution (request);
VERIFY (e.first.matches (solution->getMatcher()),"stored advice solution not supported by binding match"); VERIFY (e.first.matches (solution->getMatcher()),"stored advice solution not supported by binding match");
VERIFY (bool(currentSolution), "unable to reproduce stored solution with the current provisions") VERIFY (bool(currentSolution), "unable to reproduce stored solution with the current provisions")
VERIFY (solution == currentSolution, "stored advice solution isn't the topmost solution for this request") VERIFY (solution == currentSolution, "stored advice solution isn't the topmost solution for this request")

6
src/common/basic-setup.hpp
View file

@ -54,7 +54,7 @@
/** "bootstrapIni" : the basic setup configuration to load */ /** "bootstrapIni" : the basic setup configuration to load */
#define LUMIERA_LOCATION_OF_BOOTSTRAP_INI "$ORIGIN/setup.ini" #define LUMIERA_LOCATION_OF_BOOTSTRAP_INI "$ORIGIN/setup.ini"
@ -83,7 +83,7 @@ namespace lumiera {
* configuration as a replacement for the time being. * configuration as a replacement for the time being.
* *
* @see configfacade.hpp * @see configfacade.hpp
* @see AppState * @see AppState
*/ */
class BasicSetup class BasicSetup
: util::NonCopyable : util::NonCopyable
@ -117,7 +117,7 @@ namespace lumiera {
throw error::Logic ("Key \""+key+"\" not found in setup.ini"); throw error::Logic ("Key \""+key+"\" not found in setup.ini");
} }
}; };
} // namespace lumiera } // namespace lumiera
#endif #endif

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

@ -15,7 +15,7 @@
/** @file config-rules.hpp /** @file config-rules.hpp
** Interface for accessing rule based configuration. ** Interface for accessing rule based configuration.
** By using the Query template, you can pose a query in prolog syntax and get some ** By using the Query template, you can pose a query in prolog syntax and get some
** existing or newly created object fulfilling the requested predicates. The actual ** existing or newly created object fulfilling the requested predicates. The actual
** implementation will be hidden behind a `instance` (Singleton factory). As of 1/2008, ** implementation will be hidden behind a `instance` (Singleton factory). As of 1/2008,
** it is _planned_ to use an embedded YAP Prolog system at some point in the future, ** it is _planned_ to use an embedded YAP Prolog system at some point in the future,
** for now we use a [mock implementation](\ref fake-configrules.hpp) based on lookup in ** for now we use a [mock implementation](\ref fake-configrules.hpp) based on lookup in
@ -43,7 +43,7 @@
** **
** @see lumiera::Query ** @see lumiera::Query
** @see mobject::session::DefsManager ** @see mobject::session::DefsManager
** @see asset::StructFactory ** @see asset::StructFactory
** @see config-resolver.hpp specialised setup for the Steam-Layer ** @see config-resolver.hpp specialised setup for the Steam-Layer
** @see fake-configrules.hpp currently used dummy-implementation ** @see fake-configrules.hpp currently used dummy-implementation
** **
@ -117,12 +117,12 @@ namespace lumiera {
/** /**
* the "back side" interface towards the classes participating * the "back side" interface towards the classes participating
* in the configuration system (the config system will be * in the configuration system (the config system will be
* delivering instances of these classes for a given query). * delivering instances of these classes for a given query).
* This one currently is just brainstorming. The idea is that * This one currently is just brainstorming. The idea is that
* a participating class would provide such and TypeHandler * a participating class would provide such and TypeHandler
* implementing the predicates which make sense for this special * implementing the predicates which make sense for this special
* type of object. Registering such a TypeHandler should create * type of object. Registering such a TypeHandler should create
* the necessary handler functions to be installed into * the necessary handler functions to be installed into
* the Prolog system. * the Prolog system.
* @deprecated it can't be done exactly this way, but I leave it in the * @deprecated it can't be done exactly this way, but I leave it in the
* current shape as a reminder for later, to show the intention... * current shape as a reminder for later, to show the intention...
@ -140,11 +140,11 @@ namespace lumiera {
TY make (Pred<SYM,SIG> capability, TY& refObj =NIL); TY make (Pred<SYM,SIG> capability, TY& refObj =NIL);
}; };
/** /**
* the "front side" interface: the Steam-Layer code can * the "front side" interface: the Steam-Layer code can
* use this QueryHandler to retrieve instances of the * use this QueryHandler to retrieve instances of the
* type TY fulfilling the given Query. To start with, * type TY fulfilling the given Query. To start with,
* we use a mock implementation. * we use a mock implementation.
* (this code works and is already used 2/2008) * (this code works and is already used 2/2008)
* @todo retrofit this to install and use a QueryResolver * @todo retrofit this to install and use a QueryResolver
* @see lumiera::query::LookupPreconfigured * @see lumiera::query::LookupPreconfigured
@ -156,7 +156,7 @@ namespace lumiera {
protected: protected:
virtual ~QueryHandler() { } virtual ~QueryHandler() { }
public: public:
/** try to find or create an object of type TY /** try to find or create an object of type TY
* fulfilling the given query. * fulfilling the given query.
* @param solution object fulfilling the query. Will be bound or * @param solution object fulfilling the query. Will be bound or
* unified (in case it's already bound) with the first solution. * unified (in case it's already bound) with the first solution.
@ -176,16 +176,16 @@ namespace lumiera {
/** /**
* Generic query interface for retrieving objects matching * Generic query interface for retrieving objects matching
* some capability query. To be instantiated using a typelist, * some capability query. To be instantiated using a typelist,
* thus inheriting from the Handler classes for each type. In * thus inheriting from the Handler classes for each type. In
* the (future) version using YAP Prolog, this will drive the * the (future) version using YAP Prolog, this will drive the
* generation and registration of the necessary predicate * generation and registration of the necessary predicate
* implementations for each concrete type, using the specialisations * implementations for each concrete type, using the specialisations
* given alongside with the types. For now it just serves to generate * given alongside with the types. For now it just serves to generate
* the necessary resolve(Query<TY>) virtual functions (implemented * the necessary resolve(Query<TY>) virtual functions (implemented
* by MockConfigRules) * by MockConfigRules)
*/ */
template<typename TYPES> template<typename TYPES>
class ConfigRules class ConfigRules
@ -193,7 +193,7 @@ namespace lumiera {
{ {
protected: protected:
ConfigRules () {} ConfigRules () {}
virtual ~ConfigRules() {} virtual ~ConfigRules() {}
public: public:
/** roll back to a pristine yet operational state. /** roll back to a pristine yet operational state.

4
src/common/guifacade.cpp
View file

@ -75,7 +75,7 @@ namespace stage {
* loading and startup process. Don't call it manually. * loading and startup process. Don't call it manually.
*/ */
bool launchUI (Subsys::SigTerm& terminationHandle) bool launchUI (Subsys::SigTerm& terminationHandle)
{ {
return theGUI_->launchUI (reinterpret_cast<void*> (&terminationHandle)); return theGUI_->launchUI (reinterpret_cast<void*> (&terminationHandle));
} }
}; };
@ -94,7 +94,7 @@ namespace stage {
{ {
operator string() const { return "Lumiera GTK GUI"; } operator string() const { return "Lumiera GTK GUI"; }
bool bool
shouldStart (lumiera::Option& opts) override shouldStart (lumiera::Option& opts) override
{ {
if (opts.isHeadless() or 0 < opts.getPort()) if (opts.isHeadless() or 0 < opts.getPort())

4
src/common/integration/common-services.cpp
View file

@ -13,7 +13,7 @@
/** @file common-services.cpp /** @file common-services.cpp
** Wire library facilities directly into application core services ** Wire library facilities directly into application core services
** This translation unit serves to complete the definition of some parts of the Lumiera library. ** This translation unit serves to complete the definition of some parts of the Lumiera library.
** While library facilities usually are written to be self-contained, at places we want "magic" ** While library facilities usually are written to be self-contained, at places we want "magic"
** integration with central services, without incurring tight coupling to the application core. ** integration with central services, without incurring tight coupling to the application core.
@ -76,7 +76,7 @@ namespace time {
}//(End) implementation helpers }//(End) implementation helpers
/** /**
* build a quantised time value, referring the time grid by-name. * build a quantised time value, referring the time grid by-name.
* This is the preferred standard way of establishing a quantisation, * This is the preferred standard way of establishing a quantisation,
* but it requires an existing time scale defined in the Lumiera Session, * but it requires an existing time scale defined in the Lumiera Session,

6
src/common/interface.h
View file

@ -28,13 +28,13 @@
** number of macros here which ease this process. ** number of macros here which ease this process.
** **
** The interface is declared by placing the following macro in a ** The interface is declared by placing the following macro in a
** header file: ** header file:
** \code ** \code
** LUMIERA_INTERFACE_DECLARE(name, version, ** LUMIERA_INTERFACE_DECLARE(name, version,
** LUMIERA_INTERFACE_SLOT(ret, name, params), ** LUMIERA_INTERFACE_SLOT(ret, name, params),
** ... ** ...
** ) ** )
** **
** \endcode ** \endcode
** Any code that wants to use this interface must then include the header file. ** Any code that wants to use this interface must then include the header file.
** **
@ -51,7 +51,7 @@
** **
** A collection of interfaces can be defined in 2 different ways depending on ** A collection of interfaces can be defined in 2 different ways depending on
** where whether the interface is exported by the core, or by a plugin: ** where whether the interface is exported by the core, or by a plugin:
** \code ** \code
** LUMIERA_EXPORT(queryfunc, ** LUMIERA_EXPORT(queryfunc,
** LUMIERA_INTERFACE_DEFINE(...), ** LUMIERA_INTERFACE_DEFINE(...),
** ... ** ...

20
src/common/option.cpp
View file

@ -67,15 +67,15 @@ namespace lumiera {
op::positional_options_description posopt; op::positional_options_description posopt;
posopt.add("session", 1); // ... can be given as 1st positional parameter posopt.add("session", 1); // ... can be given as 1st positional parameter
op::parsed_options parsed = op::parsed_options parsed =
op::command_line_parser (cmdline) op::command_line_parser (cmdline)
.options (syntax) .options (syntax)
.positional(posopt) .positional(posopt)
.allow_unregistered() .allow_unregistered()
.run(); .run();
op::store (parsed, parameters); op::store (parsed, parameters);
op::notify(parameters); op::notify(parameters);
// remove all recognised options from original cmdline vector // remove all recognised options from original cmdline vector
cmdline = op::collect_unrecognized(parsed.options, op::include_positional); cmdline = op::collect_unrecognized(parsed.options, op::include_positional);
@ -104,14 +104,14 @@ namespace lumiera {
/** @return the name of the session file to open */ /** @return the name of the session file to open */
const string const string
Option::getSessName () Option::getSessName ()
{ {
ASSERT (parameters.count ("session")); ASSERT (parameters.count ("session"));
return parameters["session"].as<string>(); return parameters["session"].as<string>();
} }
/** @return an (maybe empty) vector /** @return an (maybe empty) vector
* containing all specified scripts to run. */ * containing all specified scripts to run. */
const VectS const VectS
Option::getScripts () Option::getScripts ()
@ -119,7 +119,7 @@ namespace lumiera {
return parameters["script"].as<VectS>(); return parameters["script"].as<VectS>();
} }
/** @return an (maybe empty) vector /** @return an (maybe empty) vector
* containing any additional Config definitions to set. */ * containing any additional Config definitions to set. */
const VectS const VectS
Option::getConfigDefs () Option::getConfigDefs ()
@ -128,7 +128,7 @@ namespace lumiera {
} }
/** @return \c true if --headless switch was given */ /** @return \c true if --headless switch was given */
bool bool
Option::isHeadless () Option::isHeadless ()
{ {
return parameters["headless"].as<bool>(); return parameters["headless"].as<bool>();
@ -146,13 +146,13 @@ namespace lumiera {
} }
ostream& ostream&
operator<< (ostream& os, const Option& ops) operator<< (ostream& os, const Option& ops)
{ {
return os << ops.syntax; return os << ops.syntax;
} }
} // namespace lumiera } // namespace lumiera

6
src/common/option.hpp
View file

@ -89,11 +89,11 @@ namespace lumiera {
friend ostream& operator<< (ostream&, const Option&); friend ostream& operator<< (ostream&, const Option&);
}; };
/** for outputting the help messages. Forward accumulated /** for outputting the help messages. Forward accumulated
* help messages from all contained option definitions */ * help messages from all contained option definitions */
ostream& operator<< (ostream& os, const Option& to); ostream& operator<< (ostream& os, const Option& to);
} // namespace lumiera } // namespace lumiera
#endif #endif

2
src/common/plugin.c
View file

@ -12,7 +12,7 @@
* *****************************************************************/ * *****************************************************************/
/** @file plugin.c /** @file plugin.c
** Plugin loader implementation. ** Plugin loader implementation.
*/ */

29
src/common/query.hpp
View file

@ -53,11 +53,11 @@
** **
** @see lumiera::QueryResolver ** @see lumiera::QueryResolver
** @see mobject::session::DefsManager ** @see mobject::session::DefsManager
** @see asset::StructFactory ** @see asset::StructFactory
** @see config-resolver.hpp specialised setup for the Steam-Layer ** @see config-resolver.hpp specialised setup for the Steam-Layer
** @see fake-configrules.hpp currently used dummy-implementation ** @see fake-configrules.hpp currently used dummy-implementation
** @see SessionServiceExploreScope ** @see SessionServiceExploreScope
** @see PlacementIndexQueryResolver ** @see PlacementIndexQueryResolver
** **
*/ */
@ -98,7 +98,7 @@ namespace lumiera {
class Goal; class Goal;
class Resolution; class Resolution;
class QueryResolver; class QueryResolver;
class QueryKey; class QueryKey;
@ -145,7 +145,7 @@ namespace lumiera {
} }
/** /**
* Single Solution, possibly part of a result set. * Single Solution, possibly part of a result set.
* A pointer-like object, usually to be down-casted * A pointer-like object, usually to be down-casted
* to a specifically typed Query::Cursor * to a specifically typed Query::Cursor
@ -189,14 +189,14 @@ namespace lumiera {
operator< (Goal::QueryID const& id1, Goal::QueryID const& id2) operator< (Goal::QueryID const& id1, Goal::QueryID const& id2)
{ {
return id1.kind < id2.kind return id1.kind < id2.kind
||(id1.kind == id2.kind && id1.type < id2.type); or(id1.kind == id2.kind and id1.type < id2.type);
} }
inline bool inline bool
operator== (Goal::QueryID const& id1, Goal::QueryID const& id2) operator== (Goal::QueryID const& id1, Goal::QueryID const& id2)
{ {
return id1.kind == id2.kind return id1.kind == id2.kind
&& id1.type == id2.type; and id1.type == id2.type;
} }
inline bool inline bool
@ -319,7 +319,7 @@ namespace lumiera {
Query (QueryID typeID, string querySpec) Query (QueryID typeID, string querySpec)
: Goal (defineQueryTypeID(typeID.kind)) : Goal (defineQueryTypeID(typeID.kind))
, def_(querySpec) , def_(querySpec)
{ {
REQUIRE (this->getQID().type == typeID.type); REQUIRE (this->getQID().type == typeID.type);
} }
@ -380,7 +380,7 @@ namespace lumiera {
/** /**
* Wrapper for indexing and ordering. * Wrapper for indexing and ordering.
* Defines a synthetic totally ordered index value. * Defines a synthetic totally ordered index value.
* Implicitly convertible to and from Query instances. * Implicitly convertible to and from Query instances.
@ -388,7 +388,7 @@ namespace lumiera {
class QueryKey class QueryKey
: boost::totally_ordered<QueryKey> : boost::totally_ordered<QueryKey>
{ {
Goal::QueryID id_; Goal::QueryID id_;
lib::QueryText def_; lib::QueryText def_;
public: public:
@ -448,15 +448,15 @@ namespace lumiera {
uint d1 = q1.degree(); uint d1 = q1.degree();
uint d2 = q2.degree(); uint d2 = q2.degree();
return d1 < d2 return d1 < d2
||(d1 == d2 && ( q1.def_ < q2.def_ or(d1 == d2 and ( q1.def_ < q2.def_
||(q1.def_ == q2.def_ && q1.id_ < q2.id_))); or (q1.def_ == q2.def_ and q1.id_ < q2.id_)));
} }
friend bool friend bool
operator== (QueryKey const& q1, QueryKey const& q2) operator== (QueryKey const& q1, QueryKey const& q2)
{ {
return q1.def_ == q2.def_; return q1.def_ == q2.def_;
} }
friend size_t friend size_t
hash_value (QueryKey const& q) hash_value (QueryKey const& q)
@ -553,7 +553,6 @@ namespace lumiera {
this->predicateForm_ = queryPredicates; this->predicateForm_ = queryPredicates;
return *this; return *this;
} }
}; };
@ -608,8 +607,6 @@ namespace lumiera {
{ {
return QueryKey (this->id_, getQueryDefinition()); return QueryKey (this->id_, getQueryDefinition());
} }

2
src/common/query/config-rules.cpp
View file

@ -43,7 +43,7 @@ namespace lumiera {
namespace query { namespace query {
namespace { // local definitions: implementing a backdoor for tests namespace { // local definitions: implementing a backdoor for tests
QueryKey fakeBypass; QueryKey fakeBypass;
} }
void setFakeBypass(QueryKey const& q) { fakeBypass = q; } void setFakeBypass(QueryKey const& q) { fakeBypass = q; }
bool isFakeBypass (QueryKey const& q) { return q == fakeBypass; } bool isFakeBypass (QueryKey const& q) { return q == fakeBypass; }

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

@ -22,7 +22,7 @@
** For the standard use-case within the session / Steam-Layer, this is performed for the ** For the standard use-case within the session / Steam-Layer, this is performed for the
** core MObject types, alongside with the definition of the generic config-query-resolver. ** core MObject types, alongside with the definition of the generic config-query-resolver.
** **
** @see config-resolver.cpp definition of the explicit specialisations for the session ** @see config-resolver.cpp definition of the explicit specialisations for the session
** @see steam::ConfigResolver ** @see steam::ConfigResolver
** **
*/ */
@ -94,7 +94,7 @@ namespace query {
template<class TAR> template<class TAR>
P<TAR> P<TAR>
DefsManager::create (const Query<TAR>& capabilities) DefsManager::create (const Query<TAR>& capabilities)
{ {
P<TAR> res; P<TAR> res;
@ -107,11 +107,11 @@ namespace query {
template<class TAR> template<class TAR>
bool bool
DefsManager::define (const P<TAR>& defaultObj, const Query<TAR>& capabilities) DefsManager::define (const P<TAR>& defaultObj, const Query<TAR>& capabilities)
{ {
P<TAR> candidate (defaultObj); P<TAR> candidate (defaultObj);
QueryHandler<TAR>& typeHandler = ConfigResolver::instance(); QueryHandler<TAR>& typeHandler = ConfigResolver::instance();
typeHandler.resolve (candidate, capabilities); typeHandler.resolve (candidate, capabilities);
if (!candidate) if (!candidate)
return false; return false;
@ -133,7 +133,7 @@ namespace query {
DefsManager::operator() (const Query<TAR>& capabilities) DefsManager::operator() (const Query<TAR>& capabilities)
{ {
P<TAR> res (search (capabilities)); P<TAR> res (search (capabilities));
if (res) if (res)
return res; return res;
else else
res = create (capabilities); // not yet known as default, create new res = create (capabilities); // not yet known as default, create new

14
src/common/query/defs-manager.hpp
View file

@ -117,8 +117,8 @@ namespace query {
* For various kinds of objects we can tweak the default parametrisation * For various kinds of objects we can tweak the default parametrisation
* as part of the general session configuration. A ref to an instance of * as part of the general session configuration. A ref to an instance of
* this class is accessible through the current session and can be used * this class is accessible through the current session and can be used
* to fill in parts of the configuration of new objects, if the user * to fill in parts of the configuration of new objects, if the user
* code didn't give more specific parameters. Necessary sub-objects * code didn't give more specific parameters. Necessary sub-objects
* will be created on demand, and any default configuration, once * will be created on demand, and any default configuration, once
* found, will be remembered and stored with the current session. * found, will be remembered and stored with the current session.
* *
@ -139,23 +139,23 @@ namespace query {
/** common access point: retrieve the default object fulfilling /** common access point: retrieve the default object fulfilling
* some given conditions. May silently trigger object creation. * some given conditions. May silently trigger object creation.
* @throw error::Config in case no solution is possible, which * @throw error::Config in case no solution is possible, which
* is considered \e misconfiguration. * is considered \e misconfiguration.
*/ */
template<class TAR> template<class TAR>
lib::P<TAR> operator() (Query<TAR> const&); lib::P<TAR> operator() (Query<TAR> const&);
/** search through the registered defaults, never create anything. /** search through the registered defaults, never create anything.
* @return object fulfilling the query, \c empty ptr if not found. * @return object fulfilling the query, \c empty ptr if not found.
*/ */
template<class TAR> template<class TAR>
lib::P<TAR> search (Query<TAR> const&); lib::P<TAR> search (Query<TAR> const&);
/** retrieve an object fulfilling the query and register it as default. /** retrieve an object fulfilling the query and register it as default.
* The resolution is delegated to the ConfigQuery system (which may cause * The resolution is delegated to the ConfigQuery system (which may cause
* creation of new object instances) * creation of new object instances)
* @return object fulfilling the query, \c empty ptr if no solution. * @return object fulfilling the query, \c empty ptr if no solution.
*/ */
template<class TAR> template<class TAR>
lib::P<TAR> create (Query<TAR> const&); lib::P<TAR> create (Query<TAR> const&);
@ -182,7 +182,7 @@ namespace query {
// Q: can we have something along the line of...? // Q: can we have something along the line of...?
// //
// template // template
// < class TAR, ///< the target to query for // < class TAR, ///< the target to query for
// template <class> class SMP ///< smart pointer class to wrap the result // template <class> class SMP ///< smart pointer class to wrap the result
// > // >
// SMP<TAR> operator() (const lumiera::Query<TAR>&); // SMP<TAR> operator() (const lumiera::Query<TAR>&);

40
src/common/query/defs-registry.hpp
View file

@ -25,7 +25,7 @@
** @remarks as of 2017, we're still using a fake implementation of the resolution, ** @remarks as of 2017, we're still using a fake implementation of the resolution,
** no real resolution engine. While the basic idea of this "defaults registry" ** no real resolution engine. While the basic idea of this "defaults registry"
** is likely to stay, the actual order relation and maybe even the components ** is likely to stay, the actual order relation and maybe even the components
** to be stored in this registry might be subject to change. ** to be stored in this registry might be subject to change.
** **
** @see mobject::session::DefsManager ** @see mobject::session::DefsManager
** @see DefsRegistryImpl_test ** @see DefsRegistryImpl_test
@ -71,7 +71,7 @@ namespace query {
} }
struct TableEntry struct TableEntry
{ {
virtual ~TableEntry() {}; virtual ~TableEntry() {};
}; };
@ -82,7 +82,7 @@ namespace query {
/** /**
* holding a single "default object" entry * holding a single "default object" entry
*/ */
template<class TAR> template<class TAR>
struct Record struct Record
@ -105,11 +105,11 @@ namespace query {
P<TAR> const& obj_; P<TAR> const& obj_;
bool bool
operator() (Record const& rec) operator() (Record const& rec)
{ {
P<TAR> storedObj (rec.objRef.lock()); P<TAR> storedObj (rec.objRef.lock());
return storedObj && (storedObj == obj_); return storedObj and (storedObj == obj_);
} }
}; };
@ -124,7 +124,7 @@ namespace query {
}; };
/** every new kind of object (Type) creates a new /** every new kind of object (Type) creates a new
* slot in the main Table holding all registered * slot in the main Table holding all registered
* default objects. Each slot actually holds a * default objects. Each slot actually holds a
* separate tree (set) of registry entries * separate tree (set) of registry entries
*/ */
@ -140,12 +140,12 @@ namespace query {
static Registry& static Registry&
access (Table& table) access (Table& table)
{ {
if ( !index if ( not index
|| index > table.size() or index > table.size()
||!table[index-1]) or not table[index-1])
createSlot (table); createSlot (table);
ASSERT (0 < index && index<=table.size() && table[index-1]); ASSERT (0 < index and index<=table.size() and table[index-1]);
Slot* item = static_cast<Slot*> (table[index-1].get()); Slot* item = static_cast<Slot*> (table[index-1].get());
return item->registry; return item->registry;
} }
@ -159,7 +159,7 @@ namespace query {
index = ++maxSlots; index = ++maxSlots;
if (index > table.size()) if (index > table.size())
table.resize (index); table.resize (index);
table[index-1].reset(new Slot); table[index-1].reset(new Slot);
} }
}; };
@ -191,7 +191,7 @@ namespace query {
public: public:
/** used for enumerating solutions */ /** used for enumerating solutions */
template<class TAR> template<class TAR>
class Iter class Iter
{ {
friend class DefsRegistry; friend class DefsRegistry;
typedef typename Slot<TAR>::Registry::iterator II; typedef typename Slot<TAR>::Registry::iterator II;
@ -199,16 +199,16 @@ namespace query {
II p,i,e; II p,i,e;
P<TAR> next, ptr; P<TAR> next, ptr;
Iter (II from, II to) ///< just enumerates the given range Iter (II from, II to) ///< just enumerates the given range
: p(from), i(from), e(to) : p(from), i(from), e(to)
{ {
if (i!=e) ++i; // p is next to be tested, i always one ahead if (i!=e) ++i; // p is next to be tested, i always one ahead
operator++ (); operator++ ();
} }
Iter (II match, II from, II to) ///< returns direct match first, then enumerates Iter (II match, II from, II to) ///< returns direct match first, then enumerates
: p(match), i(from), e(to) : p(match), i(from), e(to)
{ {
operator++ (); // init to first element (or to null if empty) operator++ (); // init to first element (or to null if empty)
} }
@ -227,12 +227,12 @@ namespace query {
public: public:
P<TAR> operator* () { return ptr; } P<TAR> operator* () { return ptr; }
bool hasNext () { return next || findNext(); } bool hasNext () { return next or findNext(); }
Iter& operator++ () Iter& operator++ ()
{ {
ptr=findNext(); ptr=findNext();
next.reset(); next.reset();
return *this; return *this;
} }
}; };
@ -282,8 +282,8 @@ namespace query {
Registry& registry = Slot<TAR>::access(table_); Registry& registry = Slot<TAR>::access(table_);
RIter pos = registry.lower_bound (entry); RIter pos = registry.lower_bound (entry);
if ( pos!=registry.end() if (pos!=registry.end() and
&& pos->queryKey == query) pos->queryKey == query)
{ {
P<TAR> storedObj (pos->objRef.lock()); P<TAR> storedObj (pos->objRef.lock());
if (storedObj) if (storedObj)

4
src/common/query/query-resolver.cpp
View file

@ -94,10 +94,10 @@ namespace lumiera {
* Thus, the individual resolution function can (re)establish a * Thus, the individual resolution function can (re)establish a
* typed context and downcast the Goal appropriately * typed context and downcast the Goal appropriately
*/ */
PReso PReso
QueryResolver::issue (Goal const& query) const QueryResolver::issue (Goal const& query) const
{ {
REQUIRE (!dispatcher_->empty(), "attempt to issue a query without having installed any resolver (yet)"); REQUIRE (!dispatcher_->empty(), "attempt to issue a query without having installed any resolver (yet)");
if (!canHandle (query)) if (!canHandle (query))
throw lumiera::error::Invalid ("unable to resolve this kind of query"); //////////////////////////////////TICKET #197 throw lumiera::error::Invalid ("unable to resolve this kind of query"); //////////////////////////////////TICKET #197

2
src/common/query/query-resolver.hpp
View file

@ -50,7 +50,7 @@ namespace lumiera {
typedef std::shared_ptr<Resolution> PReso; typedef std::shared_ptr<Resolution> PReso;
/** /**
* ABC representing the result set * ABC representing the result set
* of an individual query resolution * of an individual query resolution
*/ */

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