ichthyo/LUMIERA.clone
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
# ./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_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
# 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
# # Why do we require ListType?
# To do something like

12
admin/scons/Buildhelper.py
View file

@ -30,8 +30,8 @@ def isCleanupOperation(env):
def isHelpRequest():
""" this is a hack: SCons does all configure tests even if only
the help message is requested. SCons doesn't export the
help option for retrieval by env.GetOption(),
so we scan the commandline directly.
help option for retrieval by env.GetOption(),
so we scan the commandline directly.
"""
return '-h' in sys.argv or '--help' in sys.argv
@ -48,8 +48,8 @@ def srcSubtree(tree, **args):
SRCPATTERNS = ['*.c','*.cpp','*.cc']
def scanSubtree(roots, patterns=SRCPATTERNS):
""" first expand (possible) wildcards and filter out non-dirs.
Then scan the given subtree for source filenames
""" first expand (possible) wildcards and filter out non-dirs.
Then scan the given subtree for source filenames
(python generator function)
"""
for root in globRootdirs(roots):
@ -92,7 +92,7 @@ def findSrcTrees(location, patterns=SRCPATTERNS):
def isSrcDir(path, patterns=SRCPATTERNS):
""" 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
"""
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.
@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)
, **kw
)

24
admin/scons/IconSvgRenderer.py
View file

@ -27,10 +27,10 @@ artworkLayerPrefix = "artwork:"
# The purpose of this python script is
# - to parse a SVG
# - 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',
# which is built during the Lumiera build process.
#
#
# 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.
# 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
# parsed from the height and width attributes of the mentioned bounding box
# rectangles.
#
#
# 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,
# which resulted in an invalid, zero sized output icon
@ -61,7 +61,7 @@ def copyMergeDirectory (src, dst):
listing = os.listdir (src)
for file_name in listing:
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)
def getDocumentSize (svg_element):
@ -112,10 +112,10 @@ def renderSvgRsvg (file_path, out_dir, artwork_name, rectangle, _doc_size):
# Prepare a Cairo context
width = int(rectangle[2])
height = int(rectangle[3])
if not os.path.exists(rsvgPath):
print("Error: executable %s not found." % rsvgPath)
os.spawnlp(os.P_WAIT, rsvgPath, rsvgPath,
"--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)),
@ -140,35 +140,35 @@ def printHelp():
def parseArguments(argv):
_optlist, args = getopt.getopt(argv, "")
if len(args) == 2:
return args[0], args[1]
printHelp()
return None, None
def main (argv):
in_path, out_dir = parseArguments(argv)
if not (in_path and out_dir):
print("Missing arguments in_path and out_dir.")
sys.exit(1)
if os.path.isfile(out_dir):
print("Unable to use '%s' as output directory, because it\'s a file." % out_dir)
sys.exit(1)
if not os.path.isdir(out_dir):
print("Output directory '%s' not found." % out_dir)
sys.exit(1)
# Create the icons folders
createDirectory(os.path.join(out_dir, "48x48"))
createDirectory(os.path.join(out_dir, "32x32"))
createDirectory(os.path.join(out_dir, "24x24"))
createDirectory(os.path.join(out_dir, "22x22"))
createDirectory(os.path.join(out_dir, "16x16"))
renderSvgIcon (in_path, out_dir)

22
admin/scons/LumieraEnvironment.py
View file

@ -26,7 +26,7 @@ from Buildhelper import *
class LumieraEnvironment(Environment):
""" Custom SCons build environment for Lumiera
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):
kw.update(VERSION = buildSetup.VERSION
@ -62,7 +62,7 @@ class LumieraEnvironment(Environment):
self.mergeConf(self.libInfo[other])
else:
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 (LINKFLAGS = other.get('LINKFLAGS', []))
@ -72,7 +72,7 @@ class LumieraEnvironment(Environment):
def addLibInfo (self, libID, minVersion=0, alias=None):
""" use pkg-config to create an Environment describing the lib.
Don't add this defs to the current Environment, rather store
them in the libInfo Dictionary.
them in the libInfo Dictionary.
"""
minVersion = str(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):
""" Registers Custom Builders for generating and installing Icons.
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)
@ -142,7 +142,7 @@ def register_LumieraResourceBuilder(env):
icon = targetdir+icon
subdir = getDirname(str(icon))
env.Install (installLocation+subdir, icon)
generateTargets.append(icon)
generateTargets.append(icon)
return (generateTargets, source)
@ -168,7 +168,7 @@ def register_LumieraResourceBuilder(env):
target dir is either the install location configured (in SConstruct),
or an explicitly given absolute or relative path segment, which might refer
to the location of the executable through the $ORIGIN token
"""
"""
source = path.join(prefix,str(source))
subdir = getDirname(source, prefix) # removes source location path prefix
if targetDir:
@ -218,13 +218,13 @@ class WrappedStandardExeBuilder(SCons.Util.Proxy):
create a clone environment for specific configuration
and then pass on the call to the wrapped original builder.
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
buildTarget = self.buildLocation(customisedEnv, target)
buildTarget = self.invokeOriginalBuilder(customisedEnv, buildTarget, source, **kw)
self.installTarget(customisedEnv, buildTarget, **kw)
return buildTarget
self.installTarget(customisedEnv, buildTarget, **kw)
return buildTarget
def invokeOriginalBuilder(self, env, target, source, **kw):
@ -269,7 +269,7 @@ class LumieraExeBuilder(WrappedStandardExeBuilder):
def getBuildDestination(self, lumiEnv): return lumiEnv.path.buildExe
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,
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
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.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):
""" several toggles and configuration variables can be set on the commandline,
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.
"""
buildVars.AddVariables(
@ -39,7 +39,7 @@ def defineCmdlineVariables(buildVars):
,('TESTSUITES', 'Run only test suites matching the given pattern', '')
,('TESTMODE', 'test suite error mode for test.sh', '')
# ,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)
,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)

8
admin/scons/Platform.py
View file

@ -94,7 +94,7 @@ def configure(env):
if not conf.CheckPkgConfig('gtkmm-3.0', '3.10'):
problems.append('Unable to configure the mm-bindings for GTK-3')
if not conf.CheckPkgConfig('glibmm-2.4', '2.39'):
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))
if not conf.CheckPkgConfig('gdlmm-3.0', verGDLmm, alias='gdl'):
problems.append('We need the C++ bindings for GDL by Fabien Parent: GDLmm >=%s '
'(either from GNOME %s or use the debian package from %s)' %
'(either from GNOME %s or use the debian package from %s)' %
(verGDLmm, urlGDLmm, urlGDLmmDEB))
if not conf.CheckPkgConfig('librsvg-2.0', '2.30'):
problems.append('Need rsvg Library for rendering icons.')
if not conf.CheckCHeader(['X11/Xutil.h', 'X11/Xlib.h'],'<>'):
problems.append('Xlib.h and Xutil.h required. Please install libx11-dev.')
# 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('x11') : problems.append('Need X-lib...') # for the xvdisplayer widget
if not conf.CheckPkgConfig('xext'): problems.append('Need libXext.')

12
admin/scons/Setup.py
View file

@ -24,7 +24,7 @@ import Options
TARGDIR = 'target'
VERSION = '0.pre.03'
TOOLDIR = './admin/scons' # SCons plugins
OPTCACHE = 'optcache'
OPTCACHE = 'optcache'
CUSTOPTFILE = 'custom-options'
# 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
, CCFLAGS='-Wall -Wextra -Wformat-security'
, 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,--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)
handleNoBugSwitches(env)
@ -82,9 +82,9 @@ def defineBuildEnvironment():
# setup search path for Lumiera plugins
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/:.\\"'
,'LUMIERA_CONFIG_PATH=\\"$DESTDIR/share/lumiera/:.\\"')
,'LUMIERA_CONFIG_PATH=\\"$DESTDIR/share/lumiera/:.\\"')
Options.prepareOptionsHelp(buildVars,env)
buildVars.Save(OPTCACHE, env)
@ -104,7 +104,7 @@ def appendVal(env,var,targetVar,val=None):
def handleNoBugSwitches(env):
""" set the build level for NoBug.
""" set the build level for NoBug.
Release builds imply no 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
#
#
# 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>`
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
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
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::
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.
* discussions regarding time values and timecode handling shed some light on the requirements
to be fulfilled by a player subsystem
- link:http://article.gmane.org/gmane.comp.video.lumiera.general/2116[Timecode Widget and Framerates]
- link:http://article.gmane.org/gmane.comp.video.lumiera.general/2109[Time, Time-spans, Quatisation and Timecode]
- link:{l}/wiki/renderengine.html#TimeQuant[Definition of Time entities]
@ -33,7 +33,7 @@ discussions and brainstorming sessions.
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 lines of ``_render- and playback-process coordination subsystem_''.
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
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
the government of _time-bound delivery_, combined with _live reconfiguration_.
@ -90,8 +90,7 @@ reconfiguration driven by user interactions:
Conclusions for the Design
~~~~~~~~~~~~~~~~~~~~~~~~~~
Based on these observations, the following design would appear to be pretty much
obvious:
Based on these observations, the following design would appear to be pretty much obvious:
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''
@ -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,
``get a clean state soon'' -- and hasn't frame quantisation something to do
with media data, which is handled in the vault?
+
+
Well, actually, all of those are pitfalls to trap the unwary. About
cleanliness, well, sigh! Doing rounding soon will leave us with a huge
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;
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
principle.
principle.
Which leaves us with the player and the session. Both positions could
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
- It doesn't have to be a menu.
- Contains a a way to manage proyects, render as movie, setup the preferences,
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.
. 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
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
@ -92,7 +92,7 @@ Modules
node (to convert audio to video), oscilators, noise, etc. For example, we
could drive a brightness/contrast node with a one dimension noise generator,
to obtain an scene with lightnings or broken lamps like “doom”
* Sound
* Media Library:
@ -161,7 +161,7 @@ Modules
different timelines, maybe when selecting in one module the others could
switch inmmediatly, but maybe it is useful in some case.
- It would be divided into three parts.
. A list of nodes into the node layout
. The options of the selected node in the list.
. 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 +
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)]]
* 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.
-- 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)]]
+
--
* 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)]]
--
@ -118,7 +118,7 @@ Xinerama and twinView test comparison http://www.phoronix.com/scan.php?page=arti
* Automatic Clip Creation based on video content. +
When scanning through an hour long video clip, it can be tedious to go through it all making clips. It would allow the user to get right to work if Lumiera could split the video into clips based on scene changes. Each clip would begin at precisely the frame the current shot begins and end at the last frame before the next shot. As long as the user could then edit these clips on the timeline, this would decrease the time spent sifting through the raw footage.
- Comment: This seems like a good idea, and quite easy to implement. I think that when we get the video-capture and media manager code working this would a be a good subproject for someone to take on.
- 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)]]
* 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, ...)
-- 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)]]
+
--
@ -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)]]
+
--
* 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)]]
--

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

@ -5,7 +5,7 @@ GuiBrainstorming Reviewed - Won't Implement
* 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
- 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)]]
@ -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.
-- 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)]]
* 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.
-- 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)]]
- 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)]]
* 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..
--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)]]
* 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.
-- link:ct[] [[DateTime(2008-04-08T01:26:06Z)]]
- Comment:The thing about tooltips is that one usually uses them to aid the user in figuring out what a toolbar button (which would otherwise be a crytic icon bitmap) actually does - and so in this sense they're not a waste - they help users figure out how the application works. Users expect to find those hints in tooltips, and so it's rather unkind to the user to do something different and unexpected, and so we should avoid breaking the norms if we can. The actual state of the widget should be visible to see straight off and editing that value should be allowed straight off. That functionality should not be hidden inside a tooltips. People will find it really counter-intuitive to have to edit a value inside a tooltip in order to make a change.
-- link:JoelHoldsworth[] [[DateTime(2008-07-22T21:42:32Z)]]
+

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

@ -40,7 +40,7 @@ Akhil
the linkage to change in the middle of the timeline.
Richard Spindler
Richard Spindler
~~~~~~~~~~~~~~~~
-> 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.
Alcarinque
Alcarinque
~~~~~~~~~~
-> link:ConceptProposals/Alcarinque.html[Proposal by »Alcarinque« (Francisco G. Rodriguez)] (http://telniratha.atspace.com/spec.html[original page])
.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.
* Keyable parameters, automatable on the timeline
* Having a transform trajectory applied to every track
@ -83,7 +83,7 @@ Alcarinque
clips.
Hermann Vosseler (Ichthyo)
Hermann Vosseler (Ichthyo)
~~~~~~~~~~~~~~~~~~~~~~~~~~
-> 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._
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.
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..."
and (b) working on a larger software compound, comprised of multiple parts, which may even be deployed distributed.
I think none of these applies to film editing. (Maybe the situation is a bit different for putting together a TV show)
According to my own editing experiences, both film and sound, the "bringing in media into the project"-phase makes only a very small percentage of the overall time spent with a given project. Initially, after bringing in the raw footage, for me there is a long lasting phase where I just explore the material, i.e. I am viewing (or listening) to the footage and maybe try out some possible cuts and combinations in a throwaway fashion, just to get a feeling about the material. Then I build up the backbone of the cut rather quickly (and this is the only time where I could imagine having muliple projects opened at the same time). What follows is a long fine tuning and augmenting phase. So, for me, setting things up so I can work comfortably in a rather focussed and limited part of the application couold be more important then exploring multiple projects at the same time. +
-- link:Ichthyostega[] [[DateTime(2009-01-29T03:31:54Z)]]
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)]]

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
---------------
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.
@ -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.
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="classes" visible="yes" title="">
<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="classmembers" visible="yes" title="" intro=""/>
</tab>
@ -20,7 +20,7 @@
<tab type="globals" visible="yes" title="" intro=""/>
</tab>
<tab type="pages" visible="yes" title="" intro=""/>
<tab type="examples" visible="yes" title="" intro=""/>
<tab type="examples" visible="yes" title="" intro=""/>
</navindex>
<!-- 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 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, ...)
- 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
- no difference between compositor and viewer
@ -42,14 +42,14 @@ _Aug 10, 2007 in #lumiera_
- they do the mixing of contained things
- can be recursive, the GUI represents basically a tree
- we need some ``wiring'' abstraction for the GUI to make it a real graph
- 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)
- 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...
* 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 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.

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

@ -2,7 +2,7 @@ Initial Lumiera Developers Meeting
==================================
: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__
@ -71,7 +71,7 @@ Since the render nodes are stateless they can be driven in multiple threads (but
The naming discussion
---------------------
The discussion looks healthy so far... People can add new proposals on the http://www.pipapo.org/pipawiki/Lumiera/Names[pipawiki]. Interesting names are still coming in, so we should just let the name-choosing game go on for a while. And, btw, we _can_ depart from beeing similar to "Cinelerra" ;-)
The discussion looks healthy so far... People can add new proposals on the 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:
* 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.
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.
@ -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:
* 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
* 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.
@ -111,7 +111,7 @@ some discussion:
Some brainstorming points about usability:
* 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).
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:53 gmerlin 2. Generic <-> format specific
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 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 gmerlin intrusive?
12:55 cehteh struct frame { uint64_t timecode; } vs...
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 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; }
@ -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 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 thats gmerlins decision ...
12:59 cehteh thats gmerlins decision ...
12:59 gmerlin I'm against gavl integration of metadata
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: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 bgav_get_next_timecode()
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 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 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 well for lumiera :-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 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: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 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: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
@ -243,7 +243,7 @@ The next meeting will be at thuesday 8th may 21:00GMT
.about 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 Author, Artist title...
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 ichthyo important for the more modern sound formats
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 gmerlin Channel locations are handles by gavl
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: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 :)
----

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

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

@ -11,7 +11,7 @@ __Participants__
* ichthyo
* joelholdsworth
* raffa
_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
----------------------------------
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
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
@ -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:59] <joelholdsworth> we implement some kind of parameters system
[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: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.
[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
and you have a presentation ..
[2008-11-12 22:11:53] <ichthyo> next problem is:
and you have a presentation ..
[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
the workspace this is a tough really tough interface design problem
because some plugins aren't just some "optional stuff", but wired
right into the core operation
[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
[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
and now you have multiple instances of the same panner plugin
so we need a naming scheme
[2008-11-12 22:19:03] <cehteh> how i thought about this:
1) plugin provides the list of its parameters (maybe as tree)
2) there is a config file (config system) which gets installed
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
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
@ -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: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: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 :)
@ -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
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
[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
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
for several different clips ...plus, maybe the possibility to "pin" some of the plugin
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: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
[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
which receives keybord input
[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
config system + some sort of automatic persistent references within proc + some
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
to create GUIs on their own
[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
by putting them in a strict framework. Then, on top of that we allow
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: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
[2008-11-12 23:35:49] * ichthyo nods
[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: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
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
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
[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::
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
meaning: I don't want *.c and *.cpp files in this package/directory/namespace,
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
and the implementation might adapt the code for example the config system
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:
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: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
all together and relative easy to clean up when done, and I don't have a differentiation
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
over 'Interfaces'
[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,
rather I guess we get a (very small) tree of interfaces.
That's the rationale behind my keeping the implementation namespaces completely apart
[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: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:
My proposal would be to use src/lumiera/... and namespace lumiera::...
(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: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
@ -483,7 +483,7 @@ from the *support library* (+liblumiera.so+).
which need to be in the .h and need full public structure definitions
which expose private details. I think these will stay private
but if not i wont really care.
[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: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)
and implementation is in a different namespace then the exported interface
basically I see two scenarios:
so, the first scenario I'd call "libarry type"
it means that the implementation namespace is nested
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
for a real library, the situation is reversed: Often you have much code close
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
and the more technical parts are in shallow sub-namespaces below
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
that was my rationale for keeping the implementation part
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:50] <joelholdsworth> yes that's right!
[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: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?
[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: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...
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
[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: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: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: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:59:04] <ichthyo> not even the lumiera support lib?
[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: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: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
but the nature of plugins is to extend the system ..
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
"build everything below this root dir into a dynamic module"
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:42] <ichthyo> we have two tools directories currently
[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
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
[2008-11-13 01:34:03] <cehteh> in a mail to you i explained that i would like mockup plugins which
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: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
@ -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
(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:41:16] <ichthyo> you have an interface and now you have two subclasses
[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:
load this module for use as interface A
[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:23] <ichthyo> meaning, each of them can "stand-in" for the interface
[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: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: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,
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: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

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

@ -18,12 +18,12 @@ __Participants__
* Victorsigma
* pedro
* thorwil
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

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

@ -74,14 +74,14 @@ Conclusion
Possible GUI-Integration: Display a frame?
------------------------------------------
There was some discussion about the need for a component which does the timing and communicates with the scheduler and where it should sit in the stack.
For example: a render controler would be `for (frame i=0; i < end; ++i){pull_frame_without_timing_constraints(i);}` and a player would be the same with timing constraints and possibly lower quality. The GUI just has to remember that a play button is pushed, and that a certain instance of the play control is associated with a certain playback task in the backend. It was decided that this doesn't need to be resolved at the moment and requires further discussion and planning. It was felt that device dependnet things shouldn't be in the backend since it may one day run remotely as a frame server. It may need to sit between the gui and the backend. It was noted that the backend will run on constraints rather than ticks. For now the focus is on getting a single frame into the gui and there will be time to flesh out final interfaces later.
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.
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[]
(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?
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)
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.

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
enough to communicate the state of the Lumiera development. Two
enough to communicate the state of the Lumiera development. Two
solutions are proposed:
* 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+ +
^20:00 GMT - 23:30 GMT^
//Menu: label 2011-03-09
//Menu: label 2011-03-09
__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
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_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> i.e. don't do too disruptive changes
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:31 <ichthyo> there is onre concern though
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
certain staging actions, finally all integration and complete releases
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
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:19] <fsiddi> yes
[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: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
@ -164,7 +164,7 @@ Colour scheme
[caption="☉Transcript☉ "]
----------------------------
[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: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
@ -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:46] <cehteh> ok for me
[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: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)
@ -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,
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
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.
@ -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: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
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: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!
@ -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
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
@ -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: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: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:46] <ichthyo> ResourceManagement
[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: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: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,
@ -555,7 +555,7 @@ Stream Type System
[caption="☉Transcript☉ "]
----------------------------
[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: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
@ -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: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: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: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
@ -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: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: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: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

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

@ -10,7 +10,7 @@ __Participants__
* cehteh
* ichthyo
* daylife
_Transcript prepared by Ichthyo_
@ -84,7 +84,7 @@ IRC Transcript
.-- Engine Interface ⟺ Scheduler Interface --
[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?
[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)
@ -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: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: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:31] <cehteh> yes
[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: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:24:01] <ichthyo> that means, the player/scheduler/whatever needs to find out a point in time,
*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
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: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:49] <cehteh> or even "already done, nothing to do"
[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
no references into the session
[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: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
[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: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: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: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
@ -360,7 +360,7 @@ IRC Transcript
(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
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: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
@ -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: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: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:55] <cehteh> i think only on jobs is good
[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: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: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: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: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: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: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: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
@ -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:03:19] <ichthyo> that means, that the individual job needs to cary a marker, so it can be associated
to a specific stream
[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: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: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: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: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:14] <cehteh> something like that
[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: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: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
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
@ -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: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: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: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: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:27] <cehteh> which can record dependencies on other jobs, have their state, a jobfunction
[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: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,
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
@ -595,7 +595,7 @@ IRC Transcript
[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
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: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
@ -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
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,
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: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)
@ -660,7 +660,7 @@ IRC Transcript
[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: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
(...)
@ -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: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
[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: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: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: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
be done in a separate job, and I didn't agree to that
[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
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
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
mainstream solutions *ffmpeg* and or *gstreamer*, but care not to lock ourselves
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
* benn
* mfisher31_
* skangas
* skangas
Summary of The Meeting
Summary of The Meeting
----------------------
. _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.
Moreover, we discussed at Froscon the desire of having some
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
called directly by build_website.sh.
. 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
* Benny
* Hendrik
_Summary written by ichthyo_
@ -52,7 +52,7 @@ Conclusion
~~~~~~~~~~
* 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 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: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
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: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;
@ -195,7 +195,7 @@ IRC Transcript
[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: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.
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: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
[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
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
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: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
@ -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
.. just dead dumb scheduling. All logic is rolled on higher levels
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
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.
@ -337,12 +337,12 @@ IRC Transcript
[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
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
[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"?
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
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
@ -355,7 +355,7 @@ IRC Transcript
[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
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: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
@ -410,7 +410,7 @@ IRC Transcript
[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,
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
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
@ -418,9 +418,9 @@ IRC Transcript
[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
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
(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:52] <cehteh> OK
[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
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
have been handed over
[2013-09-13 00:09:41] <cehteh> well proc creates the job
have been handed over
[2013-09-13 00:09:41] <cehteh> well proc creates the job
[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: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: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: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: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 --
[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:49] <ichthyo> Proc will certainly never ask you to stop a specific job
this is sure.
@ -502,7 +502,7 @@ IRC Transcript
[2013-09-13 00:14:32] <bennI_> 'IT' ?
the proc?
[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: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,
@ -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: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
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
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.
@ -538,7 +538,7 @@ IRC Transcript
[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: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: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
@ -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: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: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
@ -560,7 +560,7 @@ IRC Transcript
Proc can try to support that feature with giving the right information
grouping or tagging would be one option
[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:19] <cehteh> I opt for the leader implementation
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
* benny
* cehteh
_Summary written by Ichthyo and reviewed by Benny_
''''
@ -116,7 +116,7 @@ support framework.
Next meeting
------------
The next meeting will be Wednesday Oct 11, 20:00 UTC.
The next meeting will be Wednesday Oct 11, 20:00 UTC.
You are welcome to join.
''''

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

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

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

@ -10,7 +10,7 @@ __Participants__
* ichthyo
* benny
* cehteh
_Summary written by Ichthyo_
''''
@ -93,7 +93,7 @@ able to demonstrate running video display in the GUI.
Next meeting
------------
The next meeting will be Wednesday Dec 13, 20:00 UTC.
The next meeting will be Wednesday Dec 13, 20:00 UTC.
You are welcome to join.
''''

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
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
whether these limitations met the demands required by Lumiera.
whether these limitations met the demands required by Lumiera.
Results were encouraging.
_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)
* Introduction of Lumiera
* handling of config errors.
* scripting language.
* editing on small devices (eeePC)
* uWiki.
* handling of config errors.
* scripting language.
* editing on small devices (eeePC)
* uWiki.
* 'musical' timeline in bars and beats
Summary
@ -448,7 +448,7 @@ Topics
* boilerplate (protocol, what's left from last meeting)
* Go through Ideas and Drafts in design process
- processing node interface
- Placement concept
- Placement concept
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
documented in the repository (tiddlywiki/source)
ct:: '2007-07-11 13:10:07'
Development took another direction over course of the years;
Lumiera is not based on a _generic plug-in Architecture_ and the topic
of interfaces for _dedicated plugins_ still needs to be worked out
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*.
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.
.........

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

@ -116,7 +116,7 @@ Tasks
~~~~~
// List what needs to be done to implement this Proposal:
* 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#)
* build the executables in a way to allow relative resolution of the
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
are more like the objects within our implementation. The concept of large
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)]]
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,
"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

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]
^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]^
^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]^
Description
@ -41,7 +41,7 @@ Comments
--------
* 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
from OODraw by Ichthyo 2011). This is not a technical draft at all, it is just
an idea.

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

@ -122,7 +122,7 @@ Parked until someone cares
~~~~~~~~~~~~~~~~~~~~~~~~~~
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]

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

@ -241,10 +241,10 @@ anchor:anchor_types[]provided TYPES
config type C type semantic (example)
-------------------------------------------------------------------------------------------------------------------
number signed long long also hex and octal (foo.bar = 12345 #comment)
real long double differerent formats as well (foo.bar=1.2345 #comment)
real long double differerent formats as well (foo.bar=1.2345 #comment)
string const char* optionaly quoted string (foo.bar="this string" #this not)
word const char* first optionaly quoted word of the config (foo.bar= first this # not)
bool int common representations for bools (0,1,true,false,yes,no,on,off,set,clear)
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.)

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 = tc:extra ; this take and clip show the extra
etc
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).
@ -293,7 +293,7 @@ associate (with space, multiple tags can be added.). The following specials are
defined:
[:keyarg:]:TAG is special tagging for scenario/take/clip.
!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.
a:TAG applies TAG only to the audio.
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
-------------------------------------
********************************************************************************
********************************************************************************
We describe here how to bring the Lumiera Developer Documentation into an simple
yet systematic structure. Previously we accumulated a lot Documentation which
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.
. the extensive link:{ldoc}/technical/[technical documentation]
is comprised of several bodies of information existing side by side
- there is a hierarchy of written documentation to explain the workings
of subsystems and components. Typically, these writings emerge from
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
and IRC transcripts
- there is a section with link:{ldoc}/technical/howto/[developer HOWTOs and tutorials]
. the documentation of technical details is always kept close to the
actual source
- file level link:{doxy}/[Doxygen] comments serve as overview and explanations
of 'key abstractions' and 'components'.
- unit tests are often written in a ``narative'' fashion and
@ -76,7 +76,7 @@ Tasks
[red yellow-background]#TBD#
* Create a facility to support the cross-linking between the various kinds of documents
[yellow-background]#WIP#
Pros
@ -84,7 +84,7 @@ Pros
// add just a fact list/enumeration which make this suitable:
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.
@ -114,9 +114,9 @@ Rationale
---------
//rationale: Describe why it should be done *this* way:
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
part of the source tree and reasonable easy available/maintainable to
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
part of the source tree and reasonable easy available/maintainable to
developers.
//Conclusion

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

@ -59,7 +59,7 @@ processes exist.
released finally
.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]). +
It is configured with _frame quantisation_ and _timings_, and a _model port_
identifier and _channel selector_.
@ -67,16 +67,16 @@ identifier and _channel selector_.
quantisation::
translates time values into frame numbers. (In the most general
case this is a function, connected to the session)
timings::
a definition to translate global model time units in real clock time,
including _alignment_ to an external _time grid_.
model port::
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
it might be a _probe point_.
channel::
within the session and high level model, details of the stream
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.
> 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....)
>
>
> - Stage
> - Steam
> - 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.
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.
@ -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
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
and caused serious problems in practice. A correct implementation of post-increment
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
'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"]
`-------------`----------------------------------------------------`----------------------------
*BRANCHNAME* *DESCRIPTION*
*BRANCHNAME* *DESCRIPTION*
*Automatic updated from*
'master' Stable branch, use this as generic entry point. cehteh,
ichthyo

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

@ -78,11 +78,11 @@ in general.
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)
2. Filters of type 2 are colormodel agnostic
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
always work in both colorspaces directly

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

@ -157,7 +157,7 @@ Comments
.State -> Final
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>

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
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
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.
* 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
~~~~~~
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.
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
~~~~~~~~~~~~~~~~~~~~~~~
....
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
@ -50,29 +50,29 @@ releases, we distinguish *major* and *minor* and *bugfix* releases.
- besides the releases, we create *development snapshot releases*, which
are just _tagged builds_.
* 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,
e.g. a bugfix we expect to be tried out at least by _someone_.
* these _development snapshots_ are an _anticipation_ of the
upcoming next release and thus get a numbering _derived_ from this
_next_ release (not the previous one).
* dev snapshots use a _timestamp_ attached with a '~' (tilde char).
It is common practice to order a tilde _below_ the release it is
attached to (and debian follows this practice)
- 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.
* _major_ releases start with 1.0 and feature high impact changes, usually linked
to some significant breakage of compatibility or some other disruptive event.
* _minor_ releases may include some new features, but can be considered
evolutionary. Their numbers are incremented on the second digit, like
1.1, 1.2, 1.3, 1.4, ....
* _bugfix_ releases are created when we have serious bugfixes to publish,
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
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
``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 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
@ -50,7 +50,7 @@ Authoring::
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
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::
@ -59,7 +59,7 @@ Integrating Content::
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
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.
- a way in which we can somehow hook the new content into our current scheme
of categories
@ -72,7 +72,7 @@ Editorial work::
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
material to any degree of depth.
- 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
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
- 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.
- specifying the displayed link text should be optional
- 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
^^^^^^^^^^^^^^^^^^
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
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.
@ -197,7 +197,7 @@ Alternatives
. _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
* 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
* 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. +
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; +

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:22:07] <ichthyo> but it need not be now, or in the meeting
[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: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
@ -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: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: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: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
@ -118,7 +118,7 @@ __cehteh__ and __ichthyo__
[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: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: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
@ -131,7 +131,7 @@ __cehteh__ and __ichthyo__
[19:55:30] <cehteh> (in case of rotations)
[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: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:32] <cehteh> the kernel will do that automatically for us
[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
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 hierarchy,
==== The Uppermost Layer
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.
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.
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
workarounds, in case this becomes a problem. Incidentally, `typeof()` is obsoleted by the new
C++ standard, which provides `decltype()` for this purpose.].
* BOOST (listed below are the Debian package names)
- libboost-dev (at least *1.67*)
- libboost-program-options-dev
@ -69,7 +69,7 @@ Languages and Tools
* Script languages
- 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
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)
Build Tools

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

@ -6,7 +6,7 @@ The Lumiera Debian Package
//Menu: label Debian Package
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
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.
.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.
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
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.
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.
.Scanner
@ -134,7 +134,7 @@ in SVG and in UML.
.the target directory
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,
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)
@ -145,11 +145,11 @@ So, for the time being, we're just building in-tree. Apologies for that.
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
scons -h
prints a summary of all custom options, targets and toggles defined for our build.
Targets

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

@ -68,12 +68,12 @@ funny (char c)
using Funky = function<uint(char)>; // <1>
int
int
main (int, char**)
{
Funky fun(funny); // <2>
Funky empty; // <3>
cout << "ASCII 'A' = " << fun('A');
cout << " defined: " << bool(fun) // <4>
<< " 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
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
* 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
* 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.
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.
* 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

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...]
- originally, GNU style focused on plain-C code. +
We thus apply some relaxations and clarifications ...
* the braces for a class scope are indented by 2 spaces
* the access modifiers start at this brace level, while all declarations and definitions
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,
provided that the length remains below 110 chars and the result _remains legible_.
More specifically...
** function declarations may be written in one line
** same for definitions with just a single statement in the body
** same for simple if-statements without else-branch.
** 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
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
@ -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
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
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
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

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::
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_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
@ -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
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
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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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%
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
precise imagination. From that point on, a rigorosely formalsed organisation is vital
to keep such a *large scale project* from floundering.
precise imagination. From that point on, a rigorously formalised organisation is vital
to keep such a *large scale project* from floundering.
////
Conventions

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

@ -52,15 +52,15 @@ using std::cout;
using std::endl;
int
int
main (int, char**)
{
std::string str = "hullo wöld";
std::vector<int> vec (1000);
for (uint i = 0; i < vec.size(); ++i)
vec[i] = i;
cout << str << "\n.gulp.\n";
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.
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;
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_,
_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
consequences, removing the need for writing lots of boilerplate code.
consequences, removing the need for writing lots of boilerplate code.
.lexical_cast
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
----
----
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:
* add the following to your `/etc/apt/sources.list`
+
+
----
deb 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
- Gnuplot provides also common statistics functions, which may come in handy when the
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
STL-adaptors::
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::
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.
@ -170,7 +170,7 @@ build-from-anything::
- prevent shadowing of _automatically generated copy operations._
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

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
. the +menugen+ python script walks the subdirectories to discover possible
menu contents. It visits Asciidoc source files (`*.txt`) and picks up
- the location / URL
- the title
- 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
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).
* 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
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
@ -136,11 +136,11 @@ def addPredefined():
root = Node(TREE_ROOT, label='Lumiera') # <1>
proj = root.linkChild('project') # <2>
proj.linkChild('faq')
proj.prependChild ('screenshots') # <3>
proj.putChildLast ('press')
proj.putChildAfter('faq', refPoint=Node('screenshots')) # <4>
proj.link('https://issues.lumiera.org/roadmap',label="Roadmap (Trac)") # <5>
Node('rfc').sortChildren()
--------------------------------------------------------------------------
@ -187,7 +187,7 @@ supported placement directives
putChildLast(id) [attach] child <id> move child to current end of list
appendChild(id) [append] child <id>
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
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
@ -195,8 +195,8 @@ supported placement directives
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)
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(includes=...) include <token>[,<token>] explicitly use the listed elements as children
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(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:
predefined:: using the built-in predefined nodes
scan:: discover nodes
scan:: discover nodes
debug:: dump data structure after discovery
text:: generate plaintext version of the menu
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,
each with the ability to recognise and implement one kind of placement specification.
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
configuration options simple.
@ -267,7 +267,7 @@ Known issues
generated as +parentPath/fileID+, to avoid mixing up similarly named
files in different directories. (The NodeIndex allows to retrieve
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,
especially because Git pushes immediately trigger menu generation.
* 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.
The resulting executable 'test-suite' is able to invoke any of the test classes in
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 provide a main method.
@ -114,25 +114,25 @@ using std::cout;
using std::endl;
namespace test {
class HelloWorld_test
: public Test
{
virtual void
run (Arg)
run (Arg)
{
greeting();
}
}
void
greeting()
{
cout << "goodbye cruel world..." <<endl;
greeting()
{
cout << "goodbye cruel world..." <<endl;
}
};
/** 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:
[width="90%",cols="<.<,^4"]
|====
|====
2+<| `./test-suite --group <groupID> [testID [arguments...]]`
|`--help` | options summary
|`-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
|====
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`
@ -175,7 +175,7 @@ Options for running the Test Script
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
- Valgrind can be disabled with `VALGRINDFLAGS=DISABLE`
- one may define `TESTMODE` containing any one of the following strings:
* `FAST` only run tests which failed recently
* `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::
(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

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
~~~~~~~~~~~~~
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]
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;
@ -104,10 +104,10 @@ want to create _yet another not so useful Git repository..._)
.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).
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
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
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'

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.
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
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.
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.
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::
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::
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`
- the remaining space below is taken by a »Patchbay« container with class `.timeline__pbay`
fork head::
@ -134,4 +134,4 @@ image:{imgd}/TimelineCSS.png["Demonstration of CSS for custom drawing"]
[red]##TODO 3/2023:##
- [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::
Some hardware controler, like an extra keyboard, midi mixer, Jog, ..
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
input devide.
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
input devide.
anchor:LowLevelModel[] link:#LowLevelModel[->]Low Level Model::
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.
It might either be given _absoulutely_, i.e as a Pipe-ID,
or by a _relative_ or an _indirect_ specification
anchor:OutputManager[] link:#OutputManager[->]OutputManager::
Manages all external outputs of the application and provides output
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
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
objects to be edited.
objects to be edited.
anchor:RenderTask[] link:#RenderTask[->]RenderTask::
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
configued with this Rules System. Typically Lumiera will provide sane
defaults for most purposes but may extended/refined for site specific
things.
things.
anchor:Sequence[] link:#Sequence[->]Sequence::
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.
To a large extent, it corresponds to the placement of this track and
allows to manipulate this placement
- *TODO*: better term for this
- Note by Ichthyo: while I like the term "patchbay", my concern with
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
----------------------------
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.
. 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
source package itself)
- '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.
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://gmerlin.sourceforge.net/[GAVL library]
* link:http://nobug.pipapo.org/[NoBug] (see below)
* Lumiera source code
* Lumiera source code
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
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
to this directory as _workspace directory_ .
to this directory as _workspace directory_ .
Lumiera Specific Libraries
@ -110,7 +110,7 @@ NoBug: building and installing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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:
------------------------------------------------------------
@ -140,7 +140,7 @@ the following shows how to build the latter
Version limitation::
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

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
line, you can begin your exposition in as much detail as you like on your
changes.
Publishing Your Contribution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -197,18 +197,18 @@ Finally you can *push* your changes to the Lumiera server on the 'mob'
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.
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]: +
The lumiera/mob repository should indicate
[green]#right now# as its ``Last Change'' entry.
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

2
src/SConscript
View file

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

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

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

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

@ -54,7 +54,7 @@ namespace advice {
namespace{ // Implementation details
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]
/** detect the _arity_ of an predicate, as matched by #findPredicate.
@ -75,12 +75,12 @@ namespace advice {
void
Binding::parse_and_append (Literal lit)
{
{
string def(lit);
string::const_iterator end_of_last_match = def.begin();
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
while (pos != end)
{
@ -91,8 +91,8 @@ namespace advice {
}
if ( end_of_last_match !=def.end()
&& *end_of_last_match !='.'
) // if the match did *not stop at the end of the pattern definition list
and *end_of_last_match !='.'
) // 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
, 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.
** 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.
** 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,
** each specifying a binding, they can be paired up if any condition included into the binding
** holds true for both sides.
@ -125,8 +125,8 @@ namespace advice {
identical (Atom const& oa) const
{
return ari_ == oa.ari_
&& sym_ == oa.sym_
&& arg_ == oa.arg_;
and sym_ == oa.sym_
and arg_ == oa.arg_;
}
int
@ -141,7 +141,7 @@ namespace advice {
friend bool
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
* 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).
* Thus e.g. #hasProvision means this index holds an entry
* pointing to exactly this given data entity.
* @note the implementation of modifying a Request entry
* explicitly relies on that definition of equality.
* @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
* 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, ProvisionCluster> PTable;
@ -350,7 +350,7 @@ namespace advice {
* Thus we can use the already modified Request to find
* the old entry within the index pointing to this Request.
* @param oKey the binding hash value prior to modification
*/
*/
void
modifyRequest (HashVal oKey, POA& entry)
{
@ -459,11 +459,11 @@ namespace advice {
{
return provisionEntries_[hash_value(refEntry)].contains (refEntry);
} // 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:
/** internal: sum element count over all
/** internal: sum element count over all
* clusters in the given hashtable */
template<class IT>
static size_t
@ -569,9 +569,9 @@ namespace advice {
verify_Entry (e,hash);
POA& request = *(e.second);
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 (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")

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

@ -54,7 +54,7 @@
/** "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.
*
* @see configfacade.hpp
* @see AppState
* @see AppState
*/
class BasicSetup
: util::NonCopyable
@ -117,7 +117,7 @@ namespace lumiera {
throw error::Logic ("Key \""+key+"\" not found in setup.ini");
}
};
} // namespace lumiera
#endif

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

@ -15,7 +15,7 @@
/** @file config-rules.hpp
** Interface for accessing rule based configuration.
** 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,
** 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
@ -43,7 +43,7 @@
**
** @see lumiera::Query
** @see mobject::session::DefsManager
** @see asset::StructFactory
** @see asset::StructFactory
** @see config-resolver.hpp specialised setup for the Steam-Layer
** @see fake-configrules.hpp currently used dummy-implementation
**
@ -117,12 +117,12 @@ namespace lumiera {
/**
* the "back side" interface towards the classes participating
* 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
* a participating class would provide such and TypeHandler
* implementing the predicates which make sense for this special
* 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.
* @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...
@ -140,11 +140,11 @@ namespace lumiera {
TY make (Pred<SYM,SIG> capability, TY& refObj =NIL);
};
/**
/**
* the "front side" interface: the Steam-Layer code can
* use this QueryHandler to retrieve instances of the
* type TY fulfilling the given Query. To start with,
* we use a mock implementation.
* we use a mock implementation.
* (this code works and is already used 2/2008)
* @todo retrofit this to install and use a QueryResolver
* @see lumiera::query::LookupPreconfigured
@ -156,7 +156,7 @@ namespace lumiera {
protected:
virtual ~QueryHandler() { }
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.
* @param solution object fulfilling the query. Will be bound or
* unified (in case it's already bound) with the first solution.
@ -176,16 +176,16 @@ namespace lumiera {
/**
/**
* Generic query interface for retrieving objects matching
* some capability query. To be instantiated using a typelist,
* thus inheriting from the Handler classes for each type. In
* 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
* given alongside with the types. For now it just serves to generate
* the necessary resolve(Query<TY>) virtual functions (implemented
* by MockConfigRules)
* by MockConfigRules)
*/
template<typename TYPES>
class ConfigRules
@ -193,7 +193,7 @@ namespace lumiera {
{
protected:
ConfigRules () {}
virtual ~ConfigRules() {}
virtual ~ConfigRules() {}
public:
/** 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.
*/
bool launchUI (Subsys::SigTerm& terminationHandle)
{
{
return theGUI_->launchUI (reinterpret_cast<void*> (&terminationHandle));
}
};
@ -94,7 +94,7 @@ namespace stage {
{
operator string() const { return "Lumiera GTK GUI"; }
bool
bool
shouldStart (lumiera::Option& opts) override
{
if (opts.isHeadless() or 0 < opts.getPort())

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

@ -13,7 +13,7 @@
/** @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.
** 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.
@ -76,7 +76,7 @@ namespace time {
}//(End) implementation helpers
/**
/**
* build a quantised time value, referring the time grid by-name.
* This is the preferred standard way of establishing a quantisation,
* 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.
**
** The interface is declared by placing the following macro in a
** header file:
** header file:
** \code
** LUMIERA_INTERFACE_DECLARE(name, version,
** LUMIERA_INTERFACE_SLOT(ret, name, params),
** ...
** )
**
**
** \endcode
** 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
** where whether the interface is exported by the core, or by a plugin:
** \code
** \code
** LUMIERA_EXPORT(queryfunc,
** LUMIERA_INTERFACE_DEFINE(...),
** ...

20
src/common/option.cpp
View file

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

6
src/common/option.hpp
View file

@ -89,11 +89,11 @@ namespace lumiera {
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 */
ostream& operator<< (ostream& os, const Option& to);
} // namespace lumiera
#endif

2
src/common/plugin.c
View file

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

29
src/common/query.hpp
View file

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

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

@ -43,7 +43,7 @@ namespace lumiera {
namespace query {
namespace { // local definitions: implementing a backdoor for tests
QueryKey fakeBypass;
}
}
void setFakeBypass(QueryKey const& q) { fakeBypass = q; }
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
** 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
**
*/
@ -94,7 +94,7 @@ namespace query {
template<class TAR>
P<TAR>
P<TAR>
DefsManager::create (const Query<TAR>& capabilities)
{
P<TAR> res;
@ -107,11 +107,11 @@ namespace query {
template<class TAR>
bool
bool
DefsManager::define (const P<TAR>& defaultObj, const Query<TAR>& capabilities)
{
P<TAR> candidate (defaultObj);
QueryHandler<TAR>& typeHandler = ConfigResolver::instance();
QueryHandler<TAR>& typeHandler = ConfigResolver::instance();
typeHandler.resolve (candidate, capabilities);
if (!candidate)
return false;
@ -133,7 +133,7 @@ namespace query {
DefsManager::operator() (const Query<TAR>& capabilities)
{
P<TAR> res (search (capabilities));
if (res)
if (res)
return res;
else
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
* 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
* to fill in parts of the configuration of new objects, if the user
* code didn't give more specific parameters. Necessary sub-objects
* to fill in parts of the configuration of new objects, if the user
* code didn't give more specific parameters. Necessary sub-objects
* will be created on demand, and any default configuration, once
* found, will be remembered and stored with the current session.
*
@ -139,23 +139,23 @@ namespace query {
/** common access point: retrieve the default object fulfilling
* some given conditions. May silently trigger object creation.
* @throw error::Config in case no solution is possible, which
* is considered \e misconfiguration.
* is considered \e misconfiguration.
*/
template<class TAR>
lib::P<TAR> operator() (Query<TAR> const&);
/** 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>
lib::P<TAR> search (Query<TAR> const&);
/** retrieve an object fulfilling the query and register it as default.
* 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.
*/
*/
template<class TAR>
lib::P<TAR> create (Query<TAR> const&);
@ -182,7 +182,7 @@ namespace query {
// Q: can we have something along the line of...?
//
// 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
// >
// 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,
** 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
** 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 DefsRegistryImpl_test
@ -71,7 +71,7 @@ namespace query {
}
struct TableEntry
struct TableEntry
{
virtual ~TableEntry() {};
};
@ -82,7 +82,7 @@ namespace query {
/**
* holding a single "default object" entry
* holding a single "default object" entry
*/
template<class TAR>
struct Record
@ -105,11 +105,11 @@ namespace query {
P<TAR> const& obj_;
bool
bool
operator() (Record const& rec)
{
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
* slot in the main Table holding all registered
* slot in the main Table holding all registered
* default objects. Each slot actually holds a
* separate tree (set) of registry entries
*/
@ -140,12 +140,12 @@ namespace query {
static Registry&
access (Table& table)
{
if ( !index
|| index > table.size()
||!table[index-1])
if ( not index
or index > table.size()
or not table[index-1])
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());
return item->registry;
}
@ -159,7 +159,7 @@ namespace query {
index = ++maxSlots;
if (index > table.size())
table.resize (index);
table[index-1].reset(new Slot);
table[index-1].reset(new Slot);
}
};
@ -191,7 +191,7 @@ namespace query {
public:
/** used for enumerating solutions */
template<class TAR>
class Iter
class Iter
{
friend class DefsRegistry;
typedef typename Slot<TAR>::Registry::iterator II;
@ -199,16 +199,16 @@ namespace query {
II p,i,e;
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)
{
if (i!=e) ++i; // p is next to be tested, i always one ahead
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)
{
{
operator++ (); // init to first element (or to null if empty)
}
@ -227,12 +227,12 @@ namespace query {
public:
P<TAR> operator* () { return ptr; }
bool hasNext () { return next || findNext(); }
bool hasNext () { return next or findNext(); }
Iter& operator++ ()
{
{
ptr=findNext();
next.reset();
return *this;
return *this;
}
};
@ -282,8 +282,8 @@ namespace query {
Registry& registry = Slot<TAR>::access(table_);
RIter pos = registry.lower_bound (entry);
if ( pos!=registry.end()
&& pos->queryKey == query)
if (pos!=registry.end() and
pos->queryKey == query)
{
P<TAR> storedObj (pos->objRef.lock());
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
* typed context and downcast the Goal appropriately
*/
PReso
PReso
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))
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;
/**
/**
* ABC representing the result set
* of an individual query resolution
*/

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