diff --git a/admin/rfc.sh b/admin/rfc.sh index 17a78b456..b1f2e0e44 100755 --- a/admin/rfc.sh +++ b/admin/rfc.sh @@ -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/ # diff --git a/admin/scons/BuilderGCH.py b/admin/scons/BuilderGCH.py index e115579f1..a8705885f 100644 --- a/admin/scons/BuilderGCH.py +++ b/admin/scons/BuilderGCH.py @@ -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 diff --git a/admin/scons/Buildhelper.py b/admin/scons/Buildhelper.py index bfaeb4911..a6cc7006f 100644 --- a/admin/scons/Buildhelper.py +++ b/admin/scons/Buildhelper.py @@ -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 ) diff --git a/admin/scons/IconSvgRenderer.py b/admin/scons/IconSvgRenderer.py index bfc156715..ebed5aef0 100644 --- a/admin/scons/IconSvgRenderer.py +++ b/admin/scons/IconSvgRenderer.py @@ -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) diff --git a/admin/scons/LumieraEnvironment.py b/admin/scons/LumieraEnvironment.py index 6f87c2629..d50b4db04 100644 --- a/admin/scons/LumieraEnvironment.py +++ b/admin/scons/LumieraEnvironment.py @@ -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)) diff --git a/admin/scons/Options.py b/admin/scons/Options.py index 4cb33978d..842fea5ba 100644 --- a/admin/scons/Options.py +++ b/admin/scons/Options.py @@ -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) diff --git a/admin/scons/Platform.py b/admin/scons/Platform.py index d26e36d34..9083a39cf 100644 --- a/admin/scons/Platform.py +++ b/admin/scons/Platform.py @@ -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.') diff --git a/admin/scons/Setup.py b/admin/scons/Setup.py index 38c0af7d5..fbed43a70 100644 --- a/admin/scons/Setup.py +++ b/admin/scons/Setup.py @@ -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 """ diff --git a/data/config/dummy_lumiera.ini b/data/config/dummy_lumiera.ini index a8408c41b..9b7289470 100644 --- a/data/config/dummy_lumiera.ini +++ b/data/config/dummy_lumiera.ini @@ -1,4 +1,4 @@ # This is an dummy Lumiera config file -# +# # Actually Lumiera can't yet load any extended config, as of 1/2011 # diff --git a/doc/design/architecture/ETD.txt b/doc/design/architecture/ETD.txt index ecdaa23b3..b2a828f94 100644 --- a/doc/design/architecture/ETD.txt +++ b/doc/design/architecture/ETD.txt @@ -71,7 +71,7 @@ Basically, we can expect to encounter the following kinds of fundamental data el - `diff::Record` 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.] diff --git a/doc/design/architecture/TimeQuant.txt b/doc/design/architecture/TimeQuant.txt index 320531981..155fd7e00 100644 --- a/doc/design/architecture/TimeQuant.txt +++ b/doc/design/architecture/TimeQuant.txt @@ -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* diff --git a/doc/design/architecture/playRender.txt b/doc/design/architecture/playRender.txt index 6a5dbc9e8..9c866e0e1 100644 --- a/doc/design/architecture/playRender.txt +++ b/doc/design/architecture/playRender.txt @@ -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 diff --git a/doc/design/gui/GuiDiscussion/ConceptProposals/Alcarinque.txt b/doc/design/gui/GuiDiscussion/ConceptProposals/Alcarinque.txt index 5e290b295..104ca8d8c 100644 --- a/doc/design/gui/GuiDiscussion/ConceptProposals/Alcarinque.txt +++ b/doc/design/gui/GuiDiscussion/ConceptProposals/Alcarinque.txt @@ -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. diff --git a/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt b/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt index b791bf535..ca21bc5ab 100644 --- a/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt +++ b/doc/design/gui/GuiDiscussion/GuiBrainstormingReviewed.txt @@ -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)]] -- diff --git a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt index 97aee51d9..8a3f92e15 100644 --- a/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt +++ b/doc/design/gui/GuiDiscussion/GuiBrainstormingWontImplement.txt @@ -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)]] + diff --git a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt b/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt index 0faa1a779..7a5d8ecd8 100644 --- a/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt +++ b/doc/design/gui/GuiDiscussion/TimelineDiscussion.txt @@ -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[] diff --git a/doc/design/gui/GuiDiscussion/Workspaces.txt b/doc/design/gui/GuiDiscussion/Workspaces.txt index e00f7bdbc..3e42239f0 100644 --- a/doc/design/gui/GuiDiscussion/Workspaces.txt +++ b/doc/design/gui/GuiDiscussion/Workspaces.txt @@ -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)]] diff --git a/doc/design/gui/GuiDiscussion/scrolling.txt b/doc/design/gui/GuiDiscussion/scrolling.txt index 2ea078d21..4dbe92bd9 100644 --- a/doc/design/gui/GuiDiscussion/scrolling.txt +++ b/doc/design/gui/GuiDiscussion/scrolling.txt @@ -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. diff --git a/doc/devel/DoxygenLayout.xml b/doc/devel/DoxygenLayout.xml index 60ce05bbe..63a67fff4 100644 --- a/doc/devel/DoxygenLayout.xml +++ b/doc/devel/DoxygenLayout.xml @@ -7,7 +7,7 @@ - + @@ -20,7 +20,7 @@ - + diff --git a/doc/devel/meeting_summary/2007-08-10.txt b/doc/devel/meeting_summary/2007-08-10.txt index a692b6499..8635f8f9a 100644 --- a/doc/devel/meeting_summary/2007-08-10.txt +++ b/doc/devel/meeting_summary/2007-08-10.txt @@ -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. diff --git a/doc/devel/meeting_summary/2008-02-01.txt b/doc/devel/meeting_summary/2008-02-01.txt index 46e3ef793..98a2655ef 100644 --- a/doc/devel/meeting_summary/2008-02-01.txt +++ b/doc/devel/meeting_summary/2008-02-01.txt @@ -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 diff --git a/doc/devel/meeting_summary/2008-04-03.txt b/doc/devel/meeting_summary/2008-04-03.txt index ebfee3f01..36cad109f 100644 --- a/doc/devel/meeting_summary/2008-04-03.txt +++ b/doc/devel/meeting_summary/2008-04-03.txt @@ -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 :) ---- diff --git a/doc/devel/meeting_summary/2008-06-06.txt b/doc/devel/meeting_summary/2008-06-06.txt index 473edd6f5..20088b68c 100644 --- a/doc/devel/meeting_summary/2008-06-06.txt +++ b/doc/devel/meeting_summary/2008-06-06.txt @@ -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. diff --git a/doc/devel/meeting_summary/2008-11-12.txt b/doc/devel/meeting_summary/2008-11-12.txt index c33fc3c74..f48d4e6e0 100644 --- a/doc/devel/meeting_summary/2008-11-12.txt +++ b/doc/devel/meeting_summary/2008-11-12.txt @@ -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] so bundling GUI together with plugins is easier now, right? [2008-11-12 22:05:59] we implement some kind of parameters system [2008-11-12 22:06:03] yes -[2008-11-12 22:06:14] joelholdsworth: thats up to you .. but the plugin system is ready +[2008-11-12 22:06:14] joelholdsworth: thats up to you .. but the plugin system is ready [2008-11-12 22:06:27] yeah that's fine [2008-11-12 22:06:38] 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] 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] next problem is: + and you have a presentation .. + +[2008-11-12 22:11:53] next problem is: [2008-11-12 22:12:16] 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] 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] 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] 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] which means, some GUI code in the plugin takes over. That is something I utterly dislike [2008-11-12 22:33:29] no thats not needed -[2008-11-12 22:33:29] in the session each object has a uuid thats its address +[2008-11-12 22:33:29] in the session each object has a uuid thats its address [2008-11-12 22:33:29] each parameter has a uuid too(interface system) [2008-11-12 22:33:31] so you can say parameter 0x2344545645654534 of object 0x4543765732525t643 .... [2008-11-12 22:33:34] "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] 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] I guess we need some modeless way of putting plugin controls in a panel -[2008-11-12 23:15:32] so maybe having panels open up - or do it like inkscape with a scrollable panel +[2008-11-12 23:15:32] 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] Cinelerra's plugin guis who constantly get lost behind the main window are really a mess -[2008-11-12 23:19:28] joelholdsworth: have you already any ideas about focus handling? +[2008-11-12 23:19:28] joelholdsworth: have you already any ideas about focus handling? [2008-11-12 23:20:15] joelholdsworth: do we get a "current object", a "current track" or the like which receives keybord input [2008-11-12 23:20:37] keybaord focus, yes - that was the plan @@ -285,7 +285,7 @@ panel layouts would be covered easily [2008-11-12 23:31:54] 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] 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] 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] Steinberg failed to address this problem properly and VST bears on this heritage until today [2008-11-12 23:35:35] 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] yes -[2008-11-12 23:36:07] note the 'any' ... +[2008-11-12 23:36:07] note the 'any' ... [2008-11-12 23:36:20] :-P -[2008-11-12 23:36:26] means mad programmers, beginner programmers, experienced programmers, html programmers ... +[2008-11-12 23:36:26] means mad programmers, beginner programmers, experienced programmers, html programmers ... [2008-11-12 23:36:52] 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] 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] 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] 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] 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] and only the class SessManagerImpl knows of the implementation class SessionImpl [2008-11-13 00:04:32] and so on -[2008-11-13 00:04:50] well thats not important yet... +[2008-11-13 00:04:50] 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] b) i was under the impression that i only wanted to export interfaces over 'Interfaces' [2008-11-13 00:06:25] ...which is fine @@ -413,7 +413,7 @@ from the *support library* (+liblumiera.so+). [2008-11-13 00:08:29] 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] ok [2008-11-13 00:09:43] the _interface.c is the glue code which can stay in the implementation dir imo [2008-11-13 00:10:16] 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] 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] mhm thats the usual reversal operation [2008-11-13 00:17:31] src/lumiera/include/ ... gets installed in /usr/include/lumiera :P [2008-11-13 00:17:40] 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] ah, I see [2008-11-13 00:27:59] probably those just count as "reasonable exceptions from the rule" [2008-11-13 00:28:33] 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] 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] joelholdsworth: so you moved your gui code within namespace gui, is that correct? [2008-11-13 00:43:50] yes that's right! [2008-11-13 00:43:59] because, then the issue seems to be settled. @@ -570,7 +570,7 @@ from the *support library* (+liblumiera.so+). [2008-11-13 00:51:56] we really dont need a 1:1 relation between dirs and namespaces [2008-11-13 00:52:08] 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] would the following rule be ok for you? [2008-11-13 00:52:58] start with dir src/plugins and descend [2008-11-13 00:53:12] 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 .lum in the corresponding bin dir - + [2008-11-13 00:55:17] thats prolly a good choice anyways [2008-11-13 00:55:28] plugins shall be only at the leaves of the tree -[2008-11-13 00:55:42] be careful when linking +[2008-11-13 00:55:42] be careful when linking [2008-11-13 00:56:16] the autoconf build included a lot libs from configure which where not needed for plugins [2008-11-13 00:56:57] 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] and I match them from the directory name [2008-11-13 00:58:20] 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] a bare plugin doesnt need any lib [2008-11-13 00:59:04] not even the lumiera support lib? [2008-11-13 00:59:11] liblumiera.a @@ -618,7 +618,7 @@ from the *support library* (+liblumiera.so+). [2008-11-13 01:00:54] but what is when a plugin wants to open another interface [2008-11-13 01:01:11] it asks the host to do it [2008-11-13 01:01:17] doesn't it need to link against your plugin system impl? -[2008-11-13 01:01:32] nope .. just the interface.h +[2008-11-13 01:01:32] nope .. just the interface.h [2008-11-13 01:02:49] 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] 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] ah, another little issue [2008-11-13 01:10:42] we have two tools directories currently [2008-11-13 01:10:53] 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] in a mail to you i explained that i would like mockup plugins which override core functionality - + [2008-11-13 01:35:07] so, wouldn't the mockup just be another implementation of interface A ? [2008-11-13 01:35:09] well you query an interface+implementation tuple [2008-11-13 01:35:35] 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] 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] I'd just try to relate it to the similar situation with classes [2008-11-13 01:41:16] you have an interface and now you have two subclasses [2008-11-13 01:41:12] nah classes are different @@ -753,7 +753,7 @@ from the *support library* (+liblumiera.so+). [2008-11-13 01:48:12] 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] nah -[2008-11-13 01:48:37] but you forget that modules != interfaces +[2008-11-13 01:48:37] but you forget that modules != interfaces [2008-11-13 01:49:07] I understand the modules as being like a "subclass" of the interface [2008-11-13 01:49:23] meaning, each of them can "stand-in" for the interface [2008-11-13 01:49:18] nope wrong @@ -767,9 +767,9 @@ from the *support library* (+liblumiera.so+). [2008-11-13 01:51:00] but what then is the term for the implementation of an interface? [2008-11-13 01:51:08] because, at an extension point [2008-11-13 01:51:21] you just want to tell: this is the interface to be used at this extension point -[2008-11-13 01:51:28] but the module is just a bunch of interfaces .. and module itself doesnt give them a purpose +[2008-11-13 01:51:28] but the module is just a bunch of interfaces .. and module itself doesnt give them a purpose [2008-11-13 01:52:09] 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] modules are just the bucket .. it is pretty unspecified what you put in [2008-11-13 01:53:01] yes thats fine, to start with [2008-11-13 01:53:23] anything more specific can be built on top of such a system diff --git a/doc/devel/meeting_summary/2008-12-10.txt b/doc/devel/meeting_summary/2008-12-10.txt index 29f8090d8..412a89a95 100644 --- a/doc/devel/meeting_summary/2008-12-10.txt +++ b/doc/devel/meeting_summary/2008-12-10.txt @@ -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 diff --git a/doc/devel/meeting_summary/2009-01-14.txt b/doc/devel/meeting_summary/2009-01-14.txt index d7019d6a7..2a6f0b4ba 100644 --- a/doc/devel/meeting_summary/2009-01-14.txt +++ b/doc/devel/meeting_summary/2009-01-14.txt @@ -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. diff --git a/doc/devel/meeting_summary/2009-09-09.txt b/doc/devel/meeting_summary/2009-09-09.txt index 9d5ebc33a..c4a95db77 100644 --- a/doc/devel/meeting_summary/2009-09-09.txt +++ b/doc/devel/meeting_summary/2009-09-09.txt @@ -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 diff --git a/doc/devel/meeting_summary/2011-03-09.txt b/doc/devel/meeting_summary/2011-03-09.txt index 0daf2303a..34d372a44 100644 --- a/doc/devel/meeting_summary/2011-03-09.txt +++ b/doc/devel/meeting_summary/2011-03-09.txt @@ -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 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 also, it is more in line with the "extreme programming" style 23:30 i.e. don't do too disruptive changes 23:30 if you want 'pre' or 'rc' - 23:30 but rather refactor often + 23:30 but rather refactor often 23:30 OK. 23:31 there is onre concern though 23:31 there *needs* to be some stability then @@ -199,7 +199,7 @@ Hermann has written an rfc for version numbers. 23:27 (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 remember in test.sh i reserved the 90-99* area for 'bugs' + 23:26 remember in test.sh i reserved the 90-99* area for 'bugs' 23:26 we may put some blocking tests there which prevent staging Next meeting diff --git a/doc/devel/meeting_summary/2011-04-13.txt b/doc/devel/meeting_summary/2011-04-13.txt index 0a5c3fa87..08de58437 100644 --- a/doc/devel/meeting_summary/2011-04-13.txt +++ b/doc/devel/meeting_summary/2011-04-13.txt @@ -115,7 +115,7 @@ using a »liquid layout«? [2011-04-13 23:14:08] so I draw the conclusion, that the documentation pages are optimised for much content [2011-04-13 23:14:19] yes [2011-04-13 23:13:30] ok .. settled -... +... [2011-04-13 23:13:54] i propose to keep the layout not liquid also in that pages [2011-04-13 23:14:35] if you prefer i can make them larger [2011-04-13 23:14:49] 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] I'd like to bring up the question regarding color -[2011-04-13 23:28:36] and I'll ask especially you, fsiddi +[2011-04-13 23:28:36] and I'll ask especially you, fsiddi [2011-04-13 23:28:44] you know, colours are a matter of taste [2011-04-13 23:29:15] thus I'd say, as you did the general layout, you have an important say in that [2011-04-13 23:28:59] ah yes colors @@ -298,7 +298,7 @@ Website licensing and legal questions [2011-04-14 00:11:42] anyeays ... dual license gpl and cc-by-sa [2011-04-14 00:11:46] ok for me [2011-04-14 00:11:55] fine, seems case is settled -[2011-04-14 00:12:04] eh which gpl ? gpl2+ .. same as lumiera +[2011-04-14 00:12:04] eh which gpl ? gpl2+ .. same as lumiera [2011-04-14 00:12:08] yes [2011-04-14 00:12:15] thats important [2011-04-14 00:12:32] 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] maybe we want another state "accepted" .. [2011-04-14 00:50:44] that is the interesting things which we know we will not drop but which are not finalized yet [2011-04-14 00:54:29] 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] I think, the existing states are enough [2011-04-14 00:53:44] either really discuss something and then decide, or just leave it in draft [2011-04-14 00:54:05] 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] so, maybe just polish a bit [2011-04-14 01:18:18] yes park because it needs some polishing before final [2011-04-14 01:18:24] (remove the "pro and con") and then we could accept it right away -[2011-04-14 01:18:28] i can put a note that its basically accepted +[2011-04-14 01:18:28] i can put a note that its basically accepted [2011-04-14 01:18:38] parking isnt neccessary bad :P [2011-04-14 01:18:46] ResourceManagement [2011-04-14 01:18:49] (well again that would be a 'accept' candidate) [2011-04-14 01:18:53] needs some more work [2011-04-14 01:19:01] that are 2 things .. yes -[2011-04-14 01:19:10] profiling and budgeting .. +[2011-04-14 01:19:10] profiling and budgeting .. [2011-04-14 01:19:21] i think i will implement them and then see how it works [2011-04-14 01:19:40] (unless someone else shows better alternatives) [2011-04-14 01:19:47] 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] very important for me -- my vote is for accept -[2011-04-14 01:24:16] we had some discussion how to maintain metadata .. +[2011-04-14 01:24:16] we had some discussion how to maintain metadata .. [2011-04-14 01:24:40] i vote for accept too but this metadata (which may decribe the type) needs work [2011-04-14 01:24:49] well, this one is really a heavyweight conceptual RfC [2011-04-14 01:25:00] it is not about *how* to maintain metadata @@ -567,7 +567,7 @@ Stream Type System [2011-04-14 01:26:36] but well, at the moment I am the only one thinking into more details of this whole topic [2011-04-14 01:26:24] shall i leave it pending just to nag us? [2011-04-14 01:26:50] yes, leave it pending -[2011-04-14 01:27:10] i was thinking too about this .. but not consistently ... +[2011-04-14 01:27:10] i was thinking too about this .. but not consistently ... [2011-04-14 01:27:24] as said, I vote for accept, but I would really ask you to think it over [2011-04-14 01:27:38] i think that needs some time to settle to the right point [tm] [2011-04-14 01:27:43] 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] not only starting and shutdown but also control the direction [2011-04-14 01:32:08] but really this isnt much a difference, if you want an extra thread then let it be so [2011-04-14 01:32:46] 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] there is not much complexity, the main thread waits currently .. +[2011-04-14 01:33:26] there is not much complexity, the main thread waits currently .. [2011-04-14 01:34:02] and it can get woken by signals or condvar (convars return when a signal arrives) [2011-04-14 01:34:29] 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 diff --git a/doc/devel/meeting_summary/2011-05-11.txt b/doc/devel/meeting_summary/2011-05-11.txt index 429d9f82b..a35a4b0d7 100644 --- a/doc/devel/meeting_summary/2011-05-11.txt +++ b/doc/devel/meeting_summary/2011-05-11.txt @@ -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] ichthyo: how do we want to proceed with the engine interface, +[2011-05-11 22:08:54] 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] well I thought rather the latter...its a rough draft [2011-05-11 22:10:52] well generally i agree with your proposal (i'm just reading it) @@ -95,7 +95,7 @@ IRC Transcript [2011-05-11 22:13:20] well your proposal sounded like constants (to be defined) [2011-05-11 22:13:35] yes, its constants, but it seems natural to extend that [2011-05-11 22:13:47] i think about a functor or even a trait-class where you can query things -[2011-05-11 22:14:19] this class can then react more dynamic +[2011-05-11 22:14:19] this class can then react more dynamic [2011-05-11 22:14:22] ok, yes, so that you could e.g. combine several independent degrees of freedom [2011-05-11 22:14:31] yes [2011-05-11 22:16:02] then we can ask precisely "shall we render this frame now?"... @@ -134,7 +134,7 @@ IRC Transcript ---------------------------- [2011-05-11 22:22:49] e.g think about the following scenario: [2011-05-11 22:23:06] we're in the middle of playing, and now we want to switch to double speed playback -[2011-05-11 22:23:39] yes then the player cancels every other frame job and changes its timebase +[2011-05-11 22:23:39] yes then the player cancels every other frame job and changes its timebase [2011-05-11 22:23:56] or instead canceling it could put them on a lower priority [2011-05-11 22:24:01] 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] 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] the 'reschedule' can answer if rescheduling is possible -[2011-05-11 22:37:07] so you just iterate over all frame-job to be rescheduled from shortest to longest time +[2011-05-11 22:37:07] so you just iterate over all frame-job to be rescheduled from shortest to longest time [2011-05-11 22:37:36] the most urgend reschedules may return "hey this job is already running, cant reschedule" [2011-05-11 22:37:49] or even "already done, nothing to do" [2011-05-11 22:38:03] to "sorry, cant do that dave" @@ -227,16 +227,16 @@ IRC Transcript [2011-05-11 22:52:09] nah not only reference data i am really thinking that jobs have absolutely no references into the session [2011-05-11 22:52:18] they have references into the backend data -[2011-05-11 22:52:23] but these are managed there +[2011-05-11 22:52:23] but these are managed there [2011-05-11 22:52:37] while closing a session doesnt require to shutdown the backend [2011-05-11 22:53:01] 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] and it references an output slot -[2011-05-11 22:53:38] really? +[2011-05-11 22:53:38] really? [2011-05-11 22:53:47] how about a functor there [2011-05-11 22:53:50] both are things which are somehow allocated from the session [2011-05-11 22:53:55] jobs references a continutation job -[2011-05-11 22:54:16] which is an abstraction of the exit node +[2011-05-11 22:54:16] which is an abstraction of the exit node [2011-05-11 22:54:36] well anyways .. the callback *is* trivially possible [2011-05-11 22:54:48] but do not expect that i want to do rescheduling for aborting jobs [2011-05-11 22:55:30] 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] 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] yes so there is no much effort doing so .. +[2011-05-11 23:32:23] yes so there is no much effort doing so .. [2011-05-11 23:32:54] that extends even more to the media libs, we're intend to use [2011-05-11 23:32:55] but since the backend always knows what memory is in use it can do a clean shutdown [2011-05-11 23:33:18] without all this callbacks and asyncronous messages @@ -395,7 +395,7 @@ IRC Transcript [2011-05-11 23:44:51] do our jobs have some mechanism to 'yield' or wait or similar? [2011-05-11 23:45:10] i.e. go in a wait state (and make room for other jobs to be scheduled meanwhile)? [2011-05-11 23:45:34] waiting on other jobs -[2011-05-11 23:45:49] i am thinking if i make a generic waiting or only on jobs +[2011-05-11 23:45:49] i am thinking if i make a generic waiting or only on jobs [2011-05-11 23:45:54] so you call into a funciton on the lumiera scheduler [2011-05-11 23:45:55] i think only on jobs is good [2011-05-11 23:46:06] which blocks and reschedules other jobs meanwhile? @@ -403,15 +403,15 @@ IRC Transcript [2011-05-11 23:46:34] just brainstorming [2011-05-11 23:46:45] both is thinkable [2011-05-11 23:46:56] also it would be thinkable that we disallow any waits -[2011-05-11 23:47:03] nope i do not want that, rather split the jobs up into small pieces -[2011-05-11 23:47:13] and just say, then the job function has to terminate and another job has to pick up +[2011-05-11 23:47:03] nope i do not want that, rather split the jobs up into small pieces +[2011-05-11 23:47:13] and just say, then the job function has to terminate and another job has to pick up [2011-05-11 23:47:27] yes thats possible -[2011-05-11 23:48:00] 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] 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] after running a job wont become rescheduled [2011-05-11 23:48:49] if it turns out we need a yield i could implement it .. but not prematurely [2011-05-11 23:49:44] but likely for our purposes we don't even need that [2011-05-11 23:50:16] yes and thats not domain of the scheduler -[2011-05-11 23:50:32] jobs can block anyways +[2011-05-11 23:50:32] jobs can block anyways [2011-05-11 23:50:40] in running state [2011-05-11 23:50:53] no need to put them on a wait queue or whatever [2011-05-11 23:51:31] 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] the engine interface needs something like these calculation streams [2011-05-12 00:03:19] 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] first, asking the backend for a frame -[2011-05-12 00:03:58] i add at least one generic void* to the job where you can put any data along +[2011-05-12 00:02:59] first, asking the backend for a frame +[2011-05-12 00:03:58] i add at least one generic void* to the job where you can put any data along [2011-05-12 00:04:12] type safety on the level above please :P [2011-05-12 00:05:20] I'm fine with that [2011-05-12 00:05:27] (caveat about the lifetime and ownership of this void*) @@ -455,7 +455,7 @@ IRC Transcript (...) [2011-05-12 00:10:44] next would be a interface how to setup a job... possibly in multiple stages -[2011-05-12 00:11:59] job_new(); job_wait_for(another_job); job_data()=some_calculation_stream; +[2011-05-12 00:11:59] job_new(); job_wait_for(another_job); job_data()=some_calculation_stream; [2011-05-12 00:12:06] job_arm() [2011-05-12 00:12:14] something like that [2011-05-12 00:12:38] sounds ok @@ -472,7 +472,7 @@ IRC Transcript [2011-05-12 00:15:04] really? [2011-05-12 00:15:11] i wonder -- makes sense or? [2011-05-12 00:15:38] *could* be done, but somehow goes against that simplicity -[2011-05-12 00:15:53] I mean each of this class shares a lot, how abortion is handled and more +[2011-05-12 00:15:53] I mean each of this class shares a lot, how abortion is handled and more [2011-05-12 00:16:43] 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] 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] this 'timer' possibly wont be singleton too .. you can play unrelated things in parallel [2011-05-12 00:24:51] well... I'd rather expect that to be quite similar to the jobs [2011-05-12 00:25:26] well i wonder if the normal jobs become bit more heavyweight -[2011-05-12 00:25:40] and the high prio queue gets its own interface +[2011-05-12 00:25:40] and the high prio queue gets its own interface [2011-05-12 00:26:00] no full blown jobs, no waiting (inter-jobs) [2011-05-12 00:26:10] what do you think to add to the normal jobs, beyond what we just discussed? [2011-05-12 00:26:15] ah maybe the dependencies [2011-05-12 00:26:23] but besides that? -[2011-05-12 00:29:03] so there will be the full blown jobs -[2011-05-12 00:29:27] which can record dependencies on other jobs, have their state, a jobfunction +[2011-05-12 00:29:03] so there will be the full blown jobs +[2011-05-12 00:29:27] which can record dependencies on other jobs, have their state, a jobfunction (...) -[2011-05-12 00:34:00] the exact setup for scheduling will likely become little more complicated +[2011-05-12 00:34:00] the exact setup for scheduling will likely become little more complicated [2011-05-12 00:34:46] 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] and depend on backend/proc [2011-05-12 00:59:16] 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] yes that costs a lot performance there .. +[2011-05-12 00:59:23] yes that costs a lot performance there .. [2011-05-12 01:00:01] as a *user* I really don't know what to prefer [2011-05-12 01:00:10] btw if frames or thumbnails have higher priority might be a feature of 'perspectives' [2011-05-12 01:00:24] 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] 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] in the (half finished) code in the ProcNode, I used placeholder / facade interfaces [2011-05-12 01:16:21] that is enough to set up the backbone [2011-05-12 01:16:52] that is, for node -> backend (to get a frame) @@ -660,7 +660,7 @@ IRC Transcript [2011-05-12 01:17:50] "node invocation interface" [2011-05-12 01:18:22] well, personally I think I'll first concentrate on the player, to get a rough outline there [2011-05-12 01:18:36] yes that will show us the requirements -[2011-05-12 01:19:15] and if I recall right, you were rather engaged into the framecache / frame database +[2011-05-12 01:19:15] and if I recall right, you were rather engaged into the framecache / frame database [2011-05-12 01:20:10] 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] yes... that was kind of the middle ground we agreed on [2011-05-12 01:31:10] 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] ah +[2011-05-12 01:31:24] ah [2011-05-12 01:34:15] run only the heavy lifting in single jobs [2011-05-12 01:34:38] I allways assume that 1 frame is one job [2011-05-12 01:34:40] at least [2011-05-12 01:34:53] well refine 'rendering one frame is one job' [2011-05-12 01:35:02] the controversy was to what extend a single frame should be split into multiple jobs -[2011-05-12 01:35:10] i dont care if discovery over a sequence is one job for multiple frames +[2011-05-12 01:35:10] i dont care if discovery over a sequence is one job for multiple frames [2011-05-12 01:36:54] 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] yes diff --git a/doc/devel/meeting_summary/2012-01-11.txt b/doc/devel/meeting_summary/2012-01-11.txt index e128bbc0d..7968e2acf 100644 --- a/doc/devel/meeting_summary/2012-01-11.txt +++ b/doc/devel/meeting_summary/2012-01-11.txt @@ -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 -- diff --git a/doc/devel/meeting_summary/2012-10-11.txt b/doc/devel/meeting_summary/2012-10-11.txt index 4e96fdb35..f73522509 100644 --- a/doc/devel/meeting_summary/2012-10-11.txt +++ b/doc/devel/meeting_summary/2012-10-11.txt @@ -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 diff --git a/doc/devel/meeting_summary/2013-09-12.txt b/doc/devel/meeting_summary/2013-09-12.txt index 132da7f31..ae5ab1243 100644 --- a/doc/devel/meeting_summary/2013-09-12.txt +++ b/doc/devel/meeting_summary/2013-09-12.txt @@ -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] what about the dependent jobs? [2013-09-12 23:00:03] thats the most important question I think, since *that* is something special -[2013-09-12 23:00:19] yes dependencies need to be handled by the scheduler +[2013-09-12 23:00:19] yes dependencies need to be handled by the scheduler [2013-09-12 23:00:52] well... at least the scheduler needs to poll them in some way [2013-09-12 23:01:01] poll or notify or re-try or the like [2013-09-12 23:01:03] 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] so we're not going to have a scheduler with simple jobs [2013-09-12 23:01:31] 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] on that level indeed, yes [2013-09-12 23:04:45] any more fancy functionality is encapsulated within that simple job abstraction [2013-09-12 23:06:18] 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] 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] yes [2013-09-12 23:08:58] 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] 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] the scheduler just has the callback waiting, then when all conditions are met it just gets scheduled -[2013-09-12 23:10:21] nope +[2013-09-12 23:10:21] nope [2013-09-12 23:10:54] note: we need a 'polling' state for a job [2013-09-12 23:10:57] so the scheduler polls a variable, signalling that the data is there (or isn't yet) [2013-09-12 23:11:14] yes @@ -256,7 +256,7 @@ IRC Transcript [2013-09-12 23:18:22] 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] 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] 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] the job function might be aware if its scheduled because of in-time or +[2013-09-12 23:40:07] 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] we only schedule background jobs if nothing else is to do [2013-09-12 23:41:18] 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] 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] I abstracted "thread classes" in the worker pool remember @@ -355,7 +355,7 @@ IRC Transcript [2013-09-12 23:43:55] 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] the scheduler should not be aware/responsible for any other resource managemnt [2013-09-12 23:44:38] 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] 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] 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] 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] 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] never give it back [2013-09-13 00:00:52] OK [2013-09-13 00:00:56] it is really point-and-shot @@ -464,8 +464,8 @@ IRC Transcript [2013-09-13 00:08:57] 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] well proc creates the job + have been handed over +[2013-09-13 00:09:41] well proc creates the job [2013-09-13 00:09:47] yes [2013-09-13 00:10:12] but you certainly augment the low level job structure with some higher level data [2013-09-13 00:10:30] yes @@ -475,7 +475,7 @@ IRC Transcript [2013-09-13 00:11:16] I'd like to see that entirely as an implementation detail within the scheduler [2013-09-13 00:11:23] the job descriptor must become very small [2013-09-13 00:11:28] since it highly depends on thread management and the like -[2013-09-13 00:11:50] no need +[2013-09-13 00:11:50] no need [2013-09-13 00:12:15] essentially, Proc will try to keep out of that discussion [2013-09-13 00:12:16] 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] how is the proc going to say 'stop some job' +[2013-09-13 00:12:19] how is the proc going to say 'stop some job' [2013-09-13 00:12:28] yes that's the question. That's what I'm getting at [2013-09-13 00:12:49] 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] 'IT' ? the proc? [2013-09-13 00:14:44] 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] cehteh: since Proc never retains knowledge regarding individual jobs [2013-09-13 00:15:17] uhm -- when you create a job it does [2013-09-13 00:15:24] '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] anyway, then "the manager" is also part of "the scheduler" damn it ;-) [2013-09-13 00:18:26] is it the WALL where the proc thows over the job [2013-09-13 00:18:31] 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] 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] its that mystically 'layer' or manager? [2013-09-13 00:20:29] yes [2013-09-13 00:20:43] and this mystical manager needs internal knowledge how the scheduler works -[2013-09-13 00:20:45] so the logic is all in the job function .. +[2013-09-13 00:20:45] so the logic is all in the job function .. [2013-09-13 00:20:47] as a client you can expect the manager to do this [2013-09-13 00:20:55] but the manager belongs not to the scheduler [2013-09-13 00:21:00] but the client doesn't need internal knowledge how the scheduler works @@ -550,7 +550,7 @@ IRC Transcript [2013-09-13 00:21:26] ok, WHO wants to stop or abort jobs? [2013-09-13 00:21:46] proc :> -[2013-09-13 00:21:48] the player +[2013-09-13 00:21:48] the player [2013-09-13 00:22:11] more precisely: the player doesn't want to stop jobs, but he wants to change the playback mode [2013-09-13 00:22:29] 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] 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] or think at scrubbing where the user drags the "playhead" marker while it move [2013-09-13 00:24:19] I opt for the leader implementation because that needs no complicated scope lookup and can be implemented with the facilities diff --git a/doc/devel/meeting_summary/2023-09-13.txt b/doc/devel/meeting_summary/2023-09-13.txt index b5e8e7eb8..e8bdf4178 100644 --- a/doc/devel/meeting_summary/2023-09-13.txt +++ b/doc/devel/meeting_summary/2023-09-13.txt @@ -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. '''' diff --git a/doc/devel/meeting_summary/2023-10-11.txt b/doc/devel/meeting_summary/2023-10-11.txt index e0c2fd4ec..45e75a2be 100644 --- a/doc/devel/meeting_summary/2023-10-11.txt +++ b/doc/devel/meeting_summary/2023-10-11.txt @@ -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. '''' diff --git a/doc/devel/meeting_summary/2023-11-08.txt b/doc/devel/meeting_summary/2023-11-08.txt index d72c55748..4bbde8449 100644 --- a/doc/devel/meeting_summary/2023-11-08.txt +++ b/doc/devel/meeting_summary/2023-11-08.txt @@ -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. '''' diff --git a/doc/devel/meeting_summary/2024-01-10.txt b/doc/devel/meeting_summary/2024-01-10.txt index 847e911b1..90265a892 100644 --- a/doc/devel/meeting_summary/2024-01-10.txt +++ b/doc/devel/meeting_summary/2024-01-10.txt @@ -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 diff --git a/doc/devel/meeting_summary/index.txt b/doc/devel/meeting_summary/index.txt index 2c693dcbd..52c26ee7f 100644 --- a/doc/devel/meeting_summary/index.txt +++ b/doc/devel/meeting_summary/index.txt @@ -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 ^^^^^^^ diff --git a/doc/devel/rfc/AllPluginInterfacesAreC.txt b/doc/devel/rfc/AllPluginInterfacesAreC.txt index 68c1bf7cb..2ee7b40ca 100644 --- a/doc/devel/rfc/AllPluginInterfacesAreC.txt +++ b/doc/devel/rfc/AllPluginInterfacesAreC.txt @@ -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. ......... diff --git a/doc/devel/rfc/ApplicationInstall.txt b/doc/devel/rfc/ApplicationInstall.txt index 44ed4cdea..9fcbd62f5 100644 --- a/doc/devel/rfc/ApplicationInstall.txt +++ b/doc/devel/rfc/ApplicationInstall.txt @@ -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. diff --git a/doc/devel/rfc/ApplicationStructure.txt b/doc/devel/rfc/ApplicationStructure.txt index 3b18ab92b..f01128eb5 100644 --- a/doc/devel/rfc/ApplicationStructure.txt +++ b/doc/devel/rfc/ApplicationStructure.txt @@ -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 diff --git a/doc/devel/rfc/ArchitectureOverview.txt b/doc/devel/rfc/ArchitectureOverview.txt index db930b6bc..4ece11a7c 100644 --- a/doc/devel/rfc/ArchitectureOverview.txt +++ b/doc/devel/rfc/ArchitectureOverview.txt @@ -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. diff --git a/doc/devel/rfc/ClipCatalogingSystem.txt b/doc/devel/rfc/ClipCatalogingSystem.txt index 8149c23ac..232a17ea5 100644 --- a/doc/devel/rfc/ClipCatalogingSystem.txt +++ b/doc/devel/rfc/ClipCatalogingSystem.txt @@ -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] diff --git a/doc/devel/rfc/ConfigLoader.txt b/doc/devel/rfc/ConfigLoader.txt index 27ef21b42..71c7b799b 100644 --- a/doc/devel/rfc/ConfigLoader.txt +++ b/doc/devel/rfc/ConfigLoader.txt @@ -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.) diff --git a/doc/devel/rfc/DelectusShotEvaluator.txt b/doc/devel/rfc/DelectusShotEvaluator.txt index 0d5b55a88..becb61afd 100644 --- a/doc/devel/rfc/DelectusShotEvaluator.txt +++ b/doc/devel/rfc/DelectusShotEvaluator.txt @@ -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. diff --git a/doc/devel/rfc/DeveloperDocumentationStructure.txt b/doc/devel/rfc/DeveloperDocumentationStructure.txt index be502dba3..78640f20c 100644 --- a/doc/devel/rfc/DeveloperDocumentationStructure.txt +++ b/doc/devel/rfc/DeveloperDocumentationStructure.txt @@ -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 diff --git a/doc/devel/rfc/EngineInterfaceOverview.txt b/doc/devel/rfc/EngineInterfaceOverview.txt index 41226318f..bc4e190fe 100644 --- a/doc/devel/rfc/EngineInterfaceOverview.txt +++ b/doc/devel/rfc/EngineInterfaceOverview.txt @@ -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 diff --git a/doc/devel/rfc/LayerNames.txt b/doc/devel/rfc/LayerNames.txt index 0dbfa0705..8e8698dd1 100644 --- a/doc/devel/rfc/LayerNames.txt +++ b/doc/devel/rfc/LayerNames.txt @@ -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 diff --git a/doc/devel/rfc/LumieraForwardIterator.txt b/doc/devel/rfc/LumieraForwardIterator.txt index c61d71353..c3fdee880 100644 --- a/doc/devel/rfc/LumieraForwardIterator.txt +++ b/doc/devel/rfc/LumieraForwardIterator.txt @@ -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' ~~ +Ichthyostega:: 'Sa 07 Jan 2012 21:49:09 CET' ~~ NOTE: Lumiera Forward Iterators can be made to work together with the 'range for loop', as introduced with C++11. The preferred solution diff --git a/doc/devel/rfc/MasterRepositorySetup.txt b/doc/devel/rfc/MasterRepositorySetup.txt index 31c3b6ceb..366bd56c5 100644 --- a/doc/devel/rfc/MasterRepositorySetup.txt +++ b/doc/devel/rfc/MasterRepositorySetup.txt @@ -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 diff --git a/doc/devel/rfc/RenderOptimizer.txt b/doc/devel/rfc/RenderOptimizer.txt index 74604e77e..d5b28319b 100644 --- a/doc/devel/rfc/RenderOptimizer.txt +++ b/doc/devel/rfc/RenderOptimizer.txt @@ -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 diff --git a/doc/devel/rfc/ThreadsSignalsAndImportantManagementTasks.txt b/doc/devel/rfc/ThreadsSignalsAndImportantManagementTasks.txt index a7f258622..00100303a 100644 --- a/doc/devel/rfc/ThreadsSignalsAndImportantManagementTasks.txt +++ b/doc/devel/rfc/ThreadsSignalsAndImportantManagementTasks.txt @@ -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 diff --git a/doc/devel/rfc/TimelineSequenceOutput.txt b/doc/devel/rfc/TimelineSequenceOutput.txt index ec8b36b57..429c2f0f7 100644 --- a/doc/devel/rfc/TimelineSequenceOutput.txt +++ b/doc/devel/rfc/TimelineSequenceOutput.txt @@ -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 diff --git a/doc/devel/rfc/UseCases.txt b/doc/devel/rfc/UseCases.txt index 7f1b96d5c..d4580413b 100644 --- a/doc/devel/rfc/UseCases.txt +++ b/doc/devel/rfc/UseCases.txt @@ -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 diff --git a/doc/devel/rfc/VersionNumberScheme.txt b/doc/devel/rfc/VersionNumberScheme.txt index 450ff27b6..228462b6b 100644 --- a/doc/devel/rfc/VersionNumberScheme.txt +++ b/doc/devel/rfc/VersionNumberScheme.txt @@ -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. diff --git a/doc/devel/rfc/WebsiteSupportMarkup.txt b/doc/devel/rfc/WebsiteSupportMarkup.txt index b1c5f49fd..04529a788 100644 --- a/doc/devel/rfc/WebsiteSupportMarkup.txt +++ b/doc/devel/rfc/WebsiteSupportMarkup.txt @@ -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 diff --git a/doc/devel/rfc/index.txt b/doc/devel/rfc/index.txt index 7c0ca2c92..de3f991d2 100644 --- a/doc/devel/rfc/index.txt +++ b/doc/devel/rfc/index.txt @@ -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. ++++ -


+


++++ '''' [small]#technically, all the RfC documents are stored within this pool directory; + diff --git a/doc/devel/transcript/2008-06_BufferAllocation.txt b/doc/devel/transcript/2008-06_BufferAllocation.txt index 4a1e62e80..54748b017 100644 --- a/doc/devel/transcript/2008-06_BufferAllocation.txt +++ b/doc/devel/transcript/2008-06_BufferAllocation.txt @@ -16,7 +16,7 @@ __cehteh__ and __ichthyo__ [19:21:57] I have one topic I want to discuss with you, cehteh [19:22:07] but it need not be now, or in the meeting [19:22:07] ok -[19:22:24] it's about allocating processing buffers +[19:22:24] it's about allocating processing buffers [19:23:20] the backend will provide them as temporary files/cyclic buffers [19:23:52] its not there yet but in my mind [19:24:11] haha, same for the builder... it's mostly just in my mind @@ -68,7 +68,7 @@ __cehteh__ and __ichthyo__ [19:39:50] we can't prepare everything, because, some nodes may include a variable ammount of source frames [19:40:11] and this number can depend on automation. Classic example is the "time average" video effect [19:39:53] problem is only when the builder generates one node which takes X and in-place generates Y from it -[19:40:10] and you have a 2nd node which takes X too +[19:40:10] and you have a 2nd node which takes X too [19:40:23] this needs to be serialized somehow [19:41:12] regarding the problem you mention: I want to exclude/avoid this situation already when building [19:41:35] yes thats what i was thinking .. thats easiest addressed there @@ -118,7 +118,7 @@ __cehteh__ and __ichthyo__ [19:52:31] but memory requirements grow quadratic! [19:52:46] the user should NEVER need to set up the processing buffer size, as is necessary in cinelerra [19:52:59] yes agreed -[19:53:15] I don't think we need safe-regions allways, +[19:53:15] I don't think we need safe-regions allways, [19:53:31] but, as e.g. the motion tracking will create automation data in Lumiera [19:53:38] yes only for some effect .. motion tracker doesnt need it [19:53:50] it means the actual buffer size depends on automation data for a given frame @@ -131,7 +131,7 @@ __cehteh__ and __ichthyo__ [19:55:30] (in case of rotations) [19:55:36] yes agreed [19:56:16] well temp buffers will be allcocated for frames of the same 'class' i aleready saied that -[19:56:50] and i will group these classes so that some similar sizes fall in the same class +[19:56:50] and i will group these classes so that some similar sizes fall in the same class [19:57:19] that might waste some memory on disk at the end of each frame .. but that doesnt need to be mapped in [19:57:32] the kernel will do that automatically for us [19:57:37] :) diff --git a/doc/index.txt b/doc/index.txt index a15dd2f25..9bc0f11e6 100644 --- a/doc/index.txt +++ b/doc/index.txt @@ -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 diff --git a/doc/technical/build/BuildDependencies.txt b/doc/technical/build/BuildDependencies.txt index 300f903a0..20ca64f97 100644 --- a/doc/technical/build/BuildDependencies.txt +++ b/doc/technical/build/BuildDependencies.txt @@ -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 diff --git a/doc/technical/build/LumieraDebianPackage.txt b/doc/technical/build/LumieraDebianPackage.txt index db29923e3..88f95a228 100644 --- a/doc/technical/build/LumieraDebianPackage.txt +++ b/doc/technical/build/LumieraDebianPackage.txt @@ -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). diff --git a/doc/technical/build/SCons.txt b/doc/technical/build/SCons.txt index 1ce955f35..150fcdeb8 100644 --- a/doc/technical/build/SCons.txt +++ b/doc/technical/build/SCons.txt @@ -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 diff --git a/doc/technical/code/c++11.txt b/doc/technical/code/c++11.txt index dc2c92918..50755c1ae 100644 --- a/doc/technical/code/c++11.txt +++ b/doc/technical/code/c++11.txt @@ -68,12 +68,12 @@ funny (char c) using Funky = function; // <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 diff --git a/doc/technical/code/codingGuidelines.txt b/doc/technical/code/codingGuidelines.txt index baf5ae791..f63b96361 100644 --- a/doc/technical/code/codingGuidelines.txt +++ b/doc/technical/code/codingGuidelines.txt @@ -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 diff --git a/doc/technical/code/gtk/layout.txt b/doc/technical/code/gtk/layout.txt index 22bb2d4f8..02f1e22ae 100644 --- a/doc/technical/code/gtk/layout.txt +++ b/doc/technical/code/gtk/layout.txt @@ -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. diff --git a/doc/technical/code/index.txt b/doc/technical/code/index.txt index f0f1553f8..9f44e14a0 100644 --- a/doc/technical/code/index.txt +++ b/doc/technical/code/index.txt @@ -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 diff --git a/doc/technical/howto/DebugGdbPretty.txt b/doc/technical/howto/DebugGdbPretty.txt index 06a9e2cb4..f26d09315 100644 --- a/doc/technical/howto/DebugGdbPretty.txt +++ b/doc/technical/howto/DebugGdbPretty.txt @@ -52,15 +52,15 @@ using std::cout; using std::endl; -int +int main (int, char**) { std::string str = "hullo wöld"; std::vector vec (1000); - + for (uint i = 0; i < vec.size(); ++i) vec[i] = i; - + cout << str << "\n.gulp.\n"; return 0; } diff --git a/doc/technical/howto/HashFunctions.txt b/doc/technical/howto/HashFunctions.txt index 1ca92d87d..417a3380e 100644 --- a/doc/technical/howto/HashFunctions.txt +++ b/doc/technical/howto/HashFunctions.txt @@ -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] diff --git a/doc/technical/howto/UsingBoost.txt b/doc/technical/howto/UsingBoost.txt index 3c5e70ec5..6e68963c8 100644 --- a/doc/technical/howto/UsingBoost.txt +++ b/doc/technical/howto/UsingBoost.txt @@ -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. diff --git a/doc/technical/howto/backporting.txt b/doc/technical/howto/backporting.txt index f0c54c020..1613c6332 100644 --- a/doc/technical/howto/backporting.txt +++ b/doc/technical/howto/backporting.txt @@ -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 diff --git a/doc/technical/howto/crackNuts.txt b/doc/technical/howto/crackNuts.txt index 504c73c6b..4015c2091 100644 --- a/doc/technical/howto/crackNuts.txt +++ b/doc/technical/howto/crackNuts.txt @@ -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 diff --git a/doc/technical/infra/MenuGen.txt b/doc/technical/infra/MenuGen.txt index 00866004b..baa6b6f88 100644 --- a/doc/technical/infra/MenuGen.txt +++ b/doc/technical/infra/MenuGen.txt @@ -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 move child to current end of list appendChild(id) [append] child putChildFirst(id) move child to current list start - prependChild(id) prepend [child] + prependChild(id) prepend [child] putChildAfter(id,ref) [attach|put] child after move child after the given ref entry link(url[,id][,label]) [child ] link ::[