Merge documentation improvements form new Lumiera.org website

This commit is contained in:
Fischlurch 2011-02-28 04:43:54 +01:00
commit 069ebf9415
78 changed files with 1299 additions and 182 deletions

View file

@ -358,7 +358,7 @@ create)
-f "./doc/devel/rfc_dropped/${name}.txt" ]]; then
echo "$name.txt exists already"
else
source ./doc/template/rfc.txt >"./doc/devel/rfc_pending/${name}.txt"
source ./doc/devel/template_rfc.sh >"./doc/devel/rfc_pending/${name}.txt"
edit "./doc/devel/rfc_pending/${name}.txt" 2 abstract
git add "./doc/devel/rfc_pending/${name}.txt"
process "./doc/devel/rfc_pending/${name}.txt"

View file

@ -12,6 +12,4 @@ The Lumiera application uses two quite different sources for configuration
-> see also the link:{ldoc}/technical/backend/ConfigLoader.html[Config Loader brainstorming from 2008] (implementation details)
[icon="warning.png"]
WARNING: Website under construction

View file

@ -5,6 +5,4 @@ Design Documents: Application Framework
* link:plugin_loader.html[Plugin Loader]
* link:SubsystemLifecycle.html[Application Subsystems and Lifecycle]
[icon="warning.png"]
WARNING: Website under construction

View file

@ -1,7 +1,5 @@
Lumiera Design: Plugin system
=============================
[icon="warning.png"]
WARNING: Website under construction
Eventually, this will have design documentation for the Plugin system.

View file

@ -1,7 +1,5 @@
Design Documents: Backend
=========================
[icon="warning.png"]
WARNING: Website under construction
Eventually, this will have design documentation for the Backend.

View file

@ -1,7 +1,5 @@
Design Documents: Renderengine
==============================
[icon="warning.png"]
WARNING: Website under construction
Eventually, this will have design documentation for the Engine.

View file

@ -1,7 +1,7 @@
GUI Brainstorming Proposal
==========================
:Author: IL'dar AKHmetgaleev (»AkhIL«)
Date: 2008-30-03
:Date: 2008-30-03
Wiring nodes within the timeline

View file

@ -0,0 +1,579 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
id="svg2"
sodipodi:version="0.32"
inkscape:version="0.46"
width="1052.5"
height="743.75"
xml:space="preserve"
sodipodi:docname="Proposal.Alcarinque.svg"
inkscape:output_extension="org.inkscape.output.svg.inkscape"><metadata
id="metadata7"><rdf:RDF><cc:Work
rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><cc:license
rdf:resource="http://creativecommons.org/licenses/by-sa/3.0/" /><dc:title>Lumiera GUI proposal</dc:title><dc:creator><cc:Agent><dc:title>Francisco G. Rodriguez (»Alcarinque«)</dc:title></cc:Agent></dc:creator><dc:date>07.05.2008</dc:date><dc:description>passed in as part of the Lumiera GUI discussion.
Added to Lumiera Website 2/2011 by Ichthyostega</dc:description></cc:Work><cc:License
rdf:about="http://creativecommons.org/licenses/by-sa/3.0/"><cc:permits
rdf:resource="http://creativecommons.org/ns#Reproduction" /><cc:permits
rdf:resource="http://creativecommons.org/ns#Distribution" /><cc:requires
rdf:resource="http://creativecommons.org/ns#Notice" /><cc:requires
rdf:resource="http://creativecommons.org/ns#Attribution" /><cc:permits
rdf:resource="http://creativecommons.org/ns#DerivativeWorks" /><cc:requires
rdf:resource="http://creativecommons.org/ns#ShareAlike" /></cc:License></rdf:RDF></metadata><defs
id="defs5"><inkscape:perspective
sodipodi:type="inkscape:persp3d"
inkscape:vp_x="0 : 526.18109 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_z="744.09448 : 526.18109 : 1"
inkscape:persp3d-origin="372.04724 : 350.78739 : 1"
id="perspective9" /><clipPath
clipPathUnits="userSpaceOnUse"
id="clipPath17"><path
d="M 0,-0.3 L 842,-0.3 L 842,595 L 0,595 L 0,-0.3 z"
clip-rule="evenodd"
id="path19" /></clipPath></defs><sodipodi:namedview
inkscape:window-height="960"
inkscape:window-width="1428"
inkscape:pageshadow="2"
inkscape:pageopacity="0.0"
guidetolerance="10.0"
gridtolerance="10.0"
objecttolerance="10.0"
borderopacity="1.0"
bordercolor="#666666"
pagecolor="#ffffff"
id="base"
showgrid="false"
inkscape:zoom="1.1021378"
inkscape:cx="536.31226"
inkscape:cy="422.53753"
inkscape:window-x="0"
inkscape:window-y="0"
inkscape:current-layer="g11" /><g
id="g11"
inkscape:groupmode="layer"
inkscape:label="ui_architecture"
transform="matrix(1.25,0,0,-1.25,0,743.75)"><g
id="g183"><path
d="M 99.2,382.4 L 113.4,382.4"
style="fill:none;stroke:none"
id="path185" /></g><g
id="g187"><path
d="M 155.9,382.4 L 170.1,382.4"
style="fill:none;stroke:none"
id="path189" /></g><g
id="g191"><path
d="M 212.6,382.4 L 226.8,382.4"
style="fill:none;stroke:none"
id="path193" /></g><g
id="g3939"
transform="matrix(0.5627991,0,0,0.5627991,0,260.13454)"><path
id="path21"
style="fill:#f5e7c3;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 0,595 L 841.9,595 L 841.9,150.05345 L 0,150.05345 L 0,595 z" /><path
id="path23"
style="fill:#c0c0c0;fill-opacity:1;fill-rule:evenodd;stroke:#439ee0;stroke-width:1.77683294;stroke-opacity:1"
d="M 269.3,240.7 L 28.3,240.7 L 28.3,439.1 L 510.2,439.1 L 510.2,240.7 L 269.3,240.7 z" /><g
id="g25"><path
id="path27"
style="fill:none;stroke:none"
d="M 269.3,240.7 L 28.3,240.7 L 28.3,439.1 L 510.2,439.1 L 510.2,240.7 L 269.3,240.7 z" /></g><g
id="g29"><text
id="text31"
transform="matrix(1,0,0,-1,325.4,253)"><tspan
id="tspan33"
sodipodi:role="line"
y="0"
x="0 12.996 23.004 32.903999 42.911999 47.897999 60.894001 70.902 85.896004 95.795998 105.804 114.804 118.71 123.786 133.686"
style="font-size:18px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Node Compositor</tspan></text>
</g><path
id="path35"
style="fill:#ccffff;fill-opacity:1;fill-rule:evenodd;stroke:#5216df;stroke-width:1.77683294;stroke-opacity:1"
d="M 240.9,481.6 L 42.5,481.6 L 42.5,566.7 L 439.4,566.7 L 439.4,481.6 L 240.9,481.6 z" /><g
id="g37"><path
id="path39"
style="fill:none;stroke:none"
d="M 240.9,481.6 L 42.5,481.6 L 42.5,566.7 L 439.4,566.7 L 439.4,481.6 L 240.9,481.6 z" /></g><g
id="g41"><text
id="text43"
transform="matrix(1,0,0,-1,351.3,487.7)"><tspan
id="tspan45"
sodipodi:role="line"
y="0"
x="0 10.494 14.4 29.393999 39.402 43.307999 47.304001 57.312"
style="font-size:18px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Timeline</tspan></text>
</g><path
id="path47"
style="fill:#ffff99;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 170.1,254.8 L 42.5,254.8 L 42.5,424.9 L 297.6,424.9 L 297.6,254.8 L 170.1,254.8 z" /><g
id="g49"><path
id="path51"
style="fill:none;stroke:none"
d="M 170.1,254.8 L 42.5,254.8 L 42.5,424.9 L 297.6,424.9 L 297.6,254.8 L 170.1,254.8 z" /></g><g
id="g53"><text
id="text55"
transform="matrix(1,0,0,-1,117.3,273.2)"><tspan
id="tspan57"
sodipodi:role="line"
y="0"
x="0 12.906 22.914 32.922001 42.821999 47.807999 51.804001 61.812 70.505997 80.514 90.522003 95.508003 100.494"
style="font-size:18px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Node layout I</tspan></text>
</g><path
id="path59"
style="fill:#ff9966;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 148.8,524.1 L 85,524.1 L 85,538.3 L 212.6,538.3 L 212.6,524.1 L 148.8,524.1 z" /><g
id="g61"><path
id="path63"
style="fill:none;stroke:none"
d="M 148.8,524.1 L 85,524.1 L 85,538.3 L 212.6,538.3 L 212.6,524.1 L 148.8,524.1 z" /></g><g
id="g65"><text
id="text67"
transform="matrix(1,0,0,-1,130.4,526.3)"><tspan
id="tspan69"
sodipodi:role="line"
y="0"
x="0 9.2959995 13.286 17.976 21.07 28.854 32.844002"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Strip I</tspan></text>
</g><path
id="path71"
style="fill:#ff9966;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 255.1,495.8 L 198.4,495.8 L 198.4,510 L 311.8,510 L 311.8,495.8 L 255.1,495.8 z" /><g
id="g73"><path
id="path75"
style="fill:none;stroke:none"
d="M 255.1,495.8 L 198.4,495.8 L 198.4,510 L 311.8,510 L 311.8,495.8 L 255.1,495.8 z" /></g><g
id="g77"><text
id="text79"
transform="matrix(1,0,0,-1,234.7,498)"><tspan
id="tspan81"
sodipodi:role="line"
y="0"
x="0 9.3800001 13.272 17.962 21.056 28.84 32.830002 36.82"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Strip II</tspan></text>
</g><path
id="path83"
style="fill:#ff9966;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 347.2,538.3 L 297.6,538.3 L 297.6,552.5 L 396.9,552.5 L 396.9,538.3 L 347.2,538.3 z" /><g
id="g85"><path
id="path87"
style="fill:none;stroke:none"
d="M 347.2,538.3 L 297.6,538.3 L 297.6,552.5 L 396.9,552.5 L 396.9,538.3 L 347.2,538.3 z" /></g><g
id="g89"><text
id="text91"
transform="matrix(1,0,0,-1,324.9,540.5)"><tspan
id="tspan93"
sodipodi:role="line"
y="0"
x="0 9.2959995 13.286 17.976 21.07 28.854 32.745998 36.736 40.627998"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Strip III</tspan></text>
</g><path
id="path95"
style="fill:#99ccff;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 78,354.1 L 56.7,354.1 L 56.7,410.7 L 99.2,410.7 L 99.2,354.1 L 78,354.1 z" /><g
id="g97"><path
id="path99"
style="fill:none;stroke:none"
d="M 78,354.1 L 56.7,354.1 L 56.7,410.7 L 99.2,410.7 L 99.2,354.1 L 78,354.1 z" /></g><g
id="g101"><text
id="text103"
transform="matrix(1,0,0,-1,72.1,385.4)"><tspan
id="tspan105"
sodipodi:role="line"
y="0"
x="0 3.892"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">In</tspan></text>
</g><g
id="g107"><text
id="text109"
transform="matrix(1,0,0,-1,61.9,369.7)"><tspan
id="tspan111"
sodipodi:role="line"
y="0"
x="0 10.192 13.286 16.379999 24.164 28.153999"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Clip I</tspan></text>
</g><path
id="path113"
style="fill:#99ccff;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 78,283.2 L 56.7,283.2 L 56.7,339.9 L 99.2,339.9 L 99.2,283.2 L 78,283.2 z" /><g
id="g115"><path
id="path117"
style="fill:none;stroke:none"
d="M 78,283.2 L 56.7,283.2 L 56.7,339.9 L 99.2,339.9 L 99.2,283.2 L 78,283.2 z" /></g><g
id="g119"><text
id="text121"
transform="matrix(1,0,0,-1,72.1,314.5)"><tspan
id="tspan123"
sodipodi:role="line"
y="0"
x="0 3.892"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">In</tspan></text>
</g><g
id="g125"><text
id="text127"
transform="matrix(1,0,0,-1,63.2,298.8)"><tspan
id="tspan129"
sodipodi:role="line"
y="0"
x="0 10.192 17.598 21.49 25.48"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">NL II</tspan></text>
</g><path
id="path131"
style="fill:#99ccff;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 134.6,354.1 L 113.4,354.1 L 113.4,410.7 L 155.9,410.7 L 155.9,354.1 L 134.6,354.1 z" /><g
id="g133"><path
id="path135"
style="fill:none;stroke:none"
d="M 134.6,354.1 L 113.4,354.1 L 113.4,410.7 L 155.9,410.7 L 155.9,354.1 L 134.6,354.1 z" /></g><g
id="g137"><text
id="text139"
transform="matrix(1,0,0,-1,116.7,385.4)"><tspan
id="tspan141"
sodipodi:role="line"
y="0"
x="0 9.3800001 13.076 16.968 24.752001 31.836"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Effect</tspan></text>
</g><g
id="g143"><text
id="text145"
transform="matrix(1,0,0,-1,132.7,369.7)"><tspan
id="tspan147"
y="0"
x="0"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">I</tspan></text>
</g><path
id="path149"
style="fill:#99ccff;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 191.3,354.1 L 170.1,354.1 L 170.1,410.7 L 212.6,410.7 L 212.6,354.1 L 191.3,354.1 z" /><g
id="g151"><path
id="path153"
style="fill:none;stroke:none"
d="M 191.3,354.1 L 170.1,354.1 L 170.1,410.7 L 212.6,410.7 L 212.6,354.1 L 191.3,354.1 z" /></g><g
id="g155"><text
id="text157"
transform="matrix(1,0,0,-1,173.4,385.4)"><tspan
id="tspan159"
sodipodi:role="line"
y="0"
x="0 9.2959995 13.09 16.982 24.766001 31.85"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Effect</tspan></text>
</g><g
id="g161"><text
id="text163"
transform="matrix(1,0,0,-1,187.4,369.7)"><tspan
id="tspan165"
sodipodi:role="line"
y="0"
x="0 3.99"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">II</tspan></text>
</g><path
id="path167"
style="fill:#99ccff;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 248,354.1 L 226.8,354.1 L 226.8,410.7 L 269.3,410.7 L 269.3,354.1 L 248,354.1 z" /><g
id="g169"><path
id="path171"
style="fill:none;stroke:none"
d="M 248,354.1 L 226.8,354.1 L 226.8,410.7 L 269.3,410.7 L 269.3,354.1 L 248,354.1 z" /></g><g
id="g173"><text
id="text175"
transform="matrix(1,0,0,-1,236.7,377.5)"><tspan
id="tspan177"
sodipodi:role="line"
y="0"
x="0 10.892 18.676001"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Out</tspan></text>
</g><g
id="g179"><path
id="path181"
style="fill:none;stroke:none"
d="M 99.2,311.5 L 191.3,311.5 L 191.3,354.1" /></g><g
id="g195"><path
id="path197"
style="fill:none;stroke:none"
d="M 248,410.7 L 248,467.2 L 148.8,467.2 L 148.8,524.1" /></g><path
id="path199"
style="fill:#ffff99;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 396.9,396.6 L 311.8,396.6 L 311.8,424.9 L 481.9,424.9 L 481.9,396.6 L 396.9,396.6 z" /><g
id="g201"><path
id="path203"
style="fill:none;stroke:none"
d="M 396.9,396.6 L 311.8,396.6 L 311.8,424.9 L 481.9,424.9 L 481.9,396.6 L 396.9,396.6 z" /></g><g
id="g205"><text
id="text207"
transform="matrix(1,0,0,-1,341.5,404.5)"><tspan
id="tspan209"
sodipodi:role="line"
y="0"
x="0 12.996 23.004 32.903999 42.804001 47.880001 51.875999 61.776001 70.578003 80.585999 90.486 95.472 100.548 105.534"
style="font-size:18px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Node layout II</tspan></text>
</g><g
id="g211"><path
id="path213"
style="fill:none;stroke:none"
d="M 396.9,424.9 L 396.9,460.1 L 255.1,460.1 L 255.1,495.8" /></g><path
id="path215"
style="fill:#ffff99;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 411,354.1 L 326,354.1 L 326,382.4 L 496.1,382.4 L 496.1,354.1 L 411,354.1 z" /><g
id="g217"><path
id="path219"
style="fill:none;stroke:none"
d="M 411,354.1 L 326,354.1 L 326,382.4 L 496.1,382.4 L 496.1,354.1 L 411,354.1 z" /></g><g
id="g221"><text
id="text223"
transform="matrix(1,0,0,-1,353.2,362)"><tspan
id="tspan225"
sodipodi:role="line"
y="0"
x="0 12.906 22.914 32.922001 42.821999 47.807999 51.804001 61.812 70.505997 80.514 90.522003 95.508003 100.494 105.57 110.556"
style="font-size:18px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Node layout III</tspan></text>
</g><g
id="g227"><path
id="path229"
style="fill:none;stroke:none"
d="M 411,382.4 L 411,467.6 L 347.2,467.6 L 347.2,538.3" /></g><path
id="path231"
style="fill:#ffcc99;fill-opacity:1;fill-rule:evenodd;stroke:#c81941;stroke-width:1.77683294;stroke-opacity:1"
d="M 666.1,254.8 L 538.6,254.8 L 538.6,424.9 L 793.7,424.9 L 793.7,254.8 L 666.1,254.8 z" /><g
id="g233"><path
id="path235"
style="fill:none;stroke:none"
d="M 666.1,254.8 L 538.6,254.8 L 538.6,424.9 L 793.7,424.9 L 793.7,254.8 L 666.1,254.8 z" /></g><g
id="g237"><text
y="-263.10001"
x="678.19312"
id="text239"
transform="scale(1,-1)"><tspan
id="tspan241"
sodipodi:role="line"
y="-263.10001"
x="678.19312 692.98907 702.8891 712.89709 716.89313 726.79309 731.86908 741.7691 745.76508 755.77313 761.67712 771.68512 777.67908"
style="font-size:18px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Media Library</tspan></text>
</g><path
id="path243"
style="fill:#94bd5e;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 630.7,354.1 L 609.4,354.1 L 609.4,410.7 L 652,410.7 L 652,354.1 L 630.7,354.1 z" /><g
id="g245"><path
id="path247"
style="fill:none;stroke:none"
d="M 630.7,354.1 L 609.4,354.1 L 609.4,410.7 L 652,410.7 L 652,354.1 L 630.7,354.1 z" /></g><g
id="g249"><text
id="text251"
transform="matrix(1,0,0,-1,612.7,377.5)"><tspan
id="tspan253"
sodipodi:role="line"
y="0"
x="0 10.192 13.286 16.379999 24.164 28.153999 32.046001"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Clip II</tspan></text>
</g><path
id="path255"
style="fill:#94bd5e;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 574,354.1 L 552.8,354.1 L 552.8,410.7 L 595.3,410.7 L 595.3,354.1 L 574,354.1 z" /><g
id="g257"><path
id="path259"
style="fill:none;stroke:none"
d="M 574,354.1 L 552.8,354.1 L 552.8,410.7 L 595.3,410.7 L 595.3,354.1 L 574,354.1 z" /></g><g
id="g261"><text
id="text263"
transform="matrix(1,0,0,-1,557.9,377.5)"><tspan
id="tspan265"
sodipodi:role="line"
y="0"
x="0 10.192 13.286 16.478001 24.261999 28.153999"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Clip I</tspan></text>
</g><path
id="path267"
style="fill:#94bd5e;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 687.4,354.1 L 666.1,354.1 L 666.1,410.7 L 708.7,410.7 L 708.7,354.1 L 687.4,354.1 z" /><g
id="g269"><path
id="path271"
style="fill:none;stroke:none"
d="M 687.4,354.1 L 666.1,354.1 L 666.1,410.7 L 708.7,410.7 L 708.7,354.1 L 687.4,354.1 z" /></g><g
id="g273"><text
id="text275"
transform="matrix(1,0,0,-1,667.4,377.5)"><tspan
id="tspan277"
sodipodi:role="line"
y="0"
x="0 10.192 13.286 16.379999 24.164 28.153999 32.046001 36.035999"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Clip III</tspan></text>
</g><path
id="path279"
style="fill:#ffff99;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 581.1,283.2 L 552.8,283.2 L 552.8,339.9 L 609.4,339.9 L 609.4,283.2 L 581.1,283.2 z" /><g
id="g281"><path
id="path283"
style="fill:none;stroke:none"
d="M 581.1,283.2 L 552.8,283.2 L 552.8,339.9 L 609.4,339.9 L 609.4,283.2 L 581.1,283.2 z" /></g><g
id="g285"><text
id="text287"
transform="matrix(1,0,0,-1,562.3,314.5)"><tspan
id="tspan289"
sodipodi:role="line"
y="0"
x="0 10.192 17.976 25.76 33.543999"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Node </tspan></text>
</g><g
id="g291"><text
id="text293"
transform="matrix(1,0,0,-1,558.5,298.8)"><tspan
id="tspan295"
sodipodi:role="line"
y="0"
x="0 3.0940001 10.878 17.780001 25.563999 33.264 37.254002 41.243999"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">layout I</tspan></text>
</g><path
id="path297"
style="fill:#ffff99;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 652,283.2 L 623.6,283.2 L 623.6,339.9 L 680.3,339.9 L 680.3,283.2 L 652,283.2 z" /><g
id="g299"><path
id="path301"
style="fill:none;stroke:none"
d="M 652,283.2 L 623.6,283.2 L 623.6,339.9 L 680.3,339.9 L 680.3,283.2 L 652,283.2 z" /></g><g
id="g303"><text
id="text305"
transform="matrix(1,0,0,-1,633.2,314.5)"><tspan
id="tspan307"
sodipodi:role="line"
y="0"
x="0 10.192 17.976 25.76 33.543999"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Node </tspan></text>
</g><g
id="g309"><text
id="text311"
transform="matrix(1,0,0,-1,627.4,298.8)"><tspan
id="tspan313"
sodipodi:role="line"
y="0"
x="0 3.0940001 10.878 17.681999 25.466 33.25 37.240002 41.132 45.122002"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">layout II</tspan></text>
</g><path
id="path315"
style="fill:#ffff99;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 722.8,283.2 L 694.5,283.2 L 694.5,339.9 L 751.2,339.9 L 751.2,283.2 L 722.8,283.2 z" /><g
id="g317"><path
id="path319"
style="fill:none;stroke:none"
d="M 722.8,283.2 L 694.5,283.2 L 694.5,339.9 L 751.2,339.9 L 751.2,283.2 L 722.8,283.2 z" /></g><g
id="g321"><text
id="text323"
transform="matrix(1,0,0,-1,704,314.5)"><tspan
id="tspan325"
sodipodi:role="line"
y="0"
x="0 10.192 17.976 25.76 33.543999"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Node </tspan></text>
</g><g
id="g327"><text
id="text329"
transform="matrix(1,0,0,-1,696.2,298.8)"><tspan
id="tspan331"
sodipodi:role="line"
y="0"
x="0 3.1919999 10.976 17.780001 25.563999 33.348 37.338001 41.23 45.220001 49.209999"
style="font-size:14px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">layout III</tspan></text>
</g><g
id="g333"><path
id="path335"
style="fill:none;stroke:none"
d="M 78,283.2 L 78,269 L 652,269 L 652,283.2" /></g><g
id="g337"><path
id="path339"
style="fill:none;stroke:none"
d="M 574,354.1 L 574,347.5 L 78,347.5 L 78,354.1" /></g><path
id="path341"
style="fill:#ff3333;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 215.4,481.6 L 212.6,481.6 L 212.6,566.7 L 218.3,566.7 L 218.3,481.6 L 215.4,481.6 z" /><g
id="g343"><path
id="path345"
style="fill:none;stroke:none"
d="M 215.4,481.6 L 212.6,481.6 L 212.6,566.7 L 218.3,566.7 L 218.3,481.6 L 215.4,481.6 z" /></g><path
id="path347"
style="fill:#9999cc;fill-opacity:1;fill-rule:evenodd;stroke:#592e85;stroke-width:1.77683294;stroke-opacity:1"
d="M 659.1,439.1 L 538.6,439.1 L 538.6,566.7 L 779.5,566.7 L 779.5,439.1 L 659.1,439.1 z" /><g
id="g349"><path
id="path351"
style="fill:none;stroke:none"
d="M 659.1,439.1 L 538.6,439.1 L 538.6,566.7 L 779.5,566.7 L 779.5,439.1 L 659.1,439.1 z" /></g><g
id="g353"><text
id="text355"
transform="matrix(1,0,0,-1,624.5,547)"><tspan
id="tspan357"
sodipodi:role="line"
y="0"
x="0 11.7 15.606 25.614 38.214001 48.113998 58.122002 64.115997"
style="font-size:18px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Viewport</tspan></text>
</g><path
id="path359"
style="fill:#99ccff;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 722.8,467.4 L 680.3,467.4 L 680.3,538.3 L 765.4,538.3 L 765.4,467.4 L 722.8,467.4 z" /><g
id="g361"><path
id="path363"
style="fill:none;stroke:none"
d="M 722.8,467.4 L 680.3,467.4 L 680.3,538.3 L 765.4,538.3 L 765.4,467.4 L 722.8,467.4 z" /></g><g
id="g365"><text
id="text367"
transform="matrix(1,0,0,-1,693.6,496.6)"><tspan
id="tspan369"
sodipodi:role="line"
y="0"
x="0 12.906 16.902 25.902 35.801998 39.798 49.806"
style="font-size:18px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Display</tspan></text>
</g><path
id="path371"
style="fill:#99ccff;fill-opacity:1;fill-rule:evenodd;stroke:none"
d="M 609.4,467.4 L 566.9,467.4 L 566.9,538.3 L 652,538.3 L 652,467.4 L 609.4,467.4 z" /><g
id="g373"><path
id="path375"
style="fill:none;stroke:none"
d="M 609.4,467.4 L 566.9,467.4 L 566.9,538.3 L 652,538.3 L 652,467.4 L 609.4,467.4 z" /></g><g
id="g377"><text
id="text379"
transform="matrix(1,0,0,-1,574.7,522.7)"><tspan
id="tspan381"
sodipodi:role="line"
y="0"
x="0 4.1849999 12.57 16.754999 25.139999 30.135 38.52 46.110001 50.294998 53.685001 60.990002"
style="font-size:15px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Interactive</tspan></text>
</g><g
id="g383"><text
id="text385"
transform="matrix(1,0,0,-1,577.9,506)"><tspan
id="tspan387"
sodipodi:role="line"
y="0"
x="0 4.1849999 12.57 16.754999 25.139999 30.225 34.41 42.794998 50.294998 58.68"
style="font-size:15px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Interface </tspan></text>
</g><g
id="g389"><text
id="text391"
transform="matrix(1,0,0,-1,594.7,489.3)"><tspan
id="tspan393"
sodipodi:role="line"
y="0"
x="0 8.3850002 16.77 25.155001"
style="font-size:15px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">and </tspan></text>
</g><g
id="g395"><text
id="text397"
transform="matrix(1,0,0,-1,581.4,472.7)"><tspan
id="tspan399"
sodipodi:role="line"
y="0"
x="0 10.8 19.094999 27.584999 31.77 36.764999 45.150002 48.540001"
style="font-size:15px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#555555;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:ArialMT;-inkscape-font-specification:ArialMT">Controls</tspan></text>
</g><g
id="g401"><path
id="path403"
style="fill:none;stroke:#ff3333;stroke-width:5.02843714;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1"
d="M 218.3,524.1 L 449.3,524.1 L 449.3,453.2 L 722.8,453.2 L 722.8,467.4" /></g><g
id="g405"><path
id="path407"
style="fill:none;stroke:#000000;stroke-width:5.02843714;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:none;stroke-opacity:1"
d="M 510.2,339.9 L 524.4,339.9 L 524.4,502.9 L 566.9,502.9" /></g></g></g></svg>

After

Width:  |  Height:  |  Size: 31 KiB

View file

@ -0,0 +1,171 @@
GUI Brainstorming Proposal
==========================
:Author: Francisco G. Rodriguez
:Date: 07.05.2008
This are some of my ideas for the interface of Lumiera. Some of this ideas are
just things I saw in the GUI brainstorm and my intent is to bring them together.
I will be adding images and more ideas, but I need some feedback because maybe
this gui is only good at the work I'm used to. If you find this is no good for
you, please write me telling me why so I can think a better way to do it.
General
-------
* The GUI must be configurable. A lot of different tasks can be done using a
NLE, and we cannot make all of them accesible at the same time. This means allow
changing keybindings, windows/tiles positions, and colors. Just like ct wrote,
saving them in the project file, etc.
* If we use a custom api for the gui, we should allow themes(or changing colors
from a preferences dialog), and if we use gtk or qt, each user could use the
program with his custom theme. (Done)
* We could provide presets for keybindings/UI copying the behaviour of others
programs. For example make it behave like cinelerra 2.0.
* If we use tiles and multiple windows, we should allow these to be created
while using the program, like blender. Each tile should have a little icon to
allow changing the module the tile is showing, and clicking on a border would
allow to divide/merge.
* All icon shortcuts, and toolbars can be hidden alowing a workflow using keybindings.
The Gui has to be divided into indepent parts or modules that will communicate
each other. Each module can be developed separately, making easy correct bugs,
and add new functions. Of course this modules I am talking about, are not the
modules described in the architecture overview. This is the gui, which is an
abstraction of the real program.
image::{imgg}/Alcarinque.proposal.png[Alcarinque's GUI proposal]
Here I made a sample of the architecture of the UI. Please don't take this too
seriously, it is just a draft so you can understand the workflow. I haven't
thought how this will communicate with the proc layer or backend.
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.
* Node Compositor
- This is a new feature that I think is very important because it allows a lot
of new special effects.
- Also it will bring a lot user contribution with the sharing of _node presets_.
. 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
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
to the Lumiera's site and share it so everyone can use it, improve it.
- Lumiera would just provide basic but poweful nodes, which would be useful
to construct very complex effects.
- There are audio and video nodes some of them can interact. See below.
- Nodes could be gruped and used as another node. A group of nodes is a
_Node layout_. When created, it appears in a tab in the media library.
Each node layout has one or more _In_ and _Out_ nodes, that let it
communicate with the others objects.
. The In node brings an input from a file and converts it into an audio/video stream.
. The Out node transforms a stream into an image drawable into the ``canvas''.
It has options like transform(position, scale, rotation) and opacity. Also
it saves a In/Out positions, relative to the internal node layout time. This
is to be able to have multiple instances of the same node layout but showing
different parts of the stream.
- Transform trayectory is shown in the interactive interface of the visor. Of course if the strip/node layout is selected.
- Opacity keys and level is shown above the strip(like cinelerra).
- If it is an audio out node, the variables are volumes for each channel.
- Each node has some parameters, these are keyable. When selecting a node,
curves for each parameter are shown in the node options module.
- Nodes should be easily programmed, and adding them should not require
recompilation of the whole program. Maybe there will be an exception to
this for the In/out nodes, etc.
- Nodes can also generate, for example a FractalExplorer node, a waveform
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:
- It can be tabbed or grupped to make organization easier.
- When selecting files, the images sequences like `image0000.jpg`,
`image0001.jpg`, `image0002.jpg`, etc should show like +image[0-3000].jpg+.
- It should display the properties of the media, like resolution, fps,
bitrate, etc. Maybe in each clip or in a container.
- Be able to select for a list or a thumbnail or waveform preview.
- In each clip there is a preview button.
- Maybe add an option to “make a new clip from this clip” to change things
like fps, size, codec, etc. Just a wrapper for ffmpeg or something.
- You can drop the clip in the node compositor as _In_ node, or in the
timeline as a stripe. Doing the latter, will create a node group with the name
of the clip, that will have an “In” node(pointing to the file) connected to an
_Out_ so that the file is seen by the timeline.
- When we import a clip it should create a proxy. We don't use the original
clip anymore until render.
* Timeline
- Should provide a palette with tools like knife, in/out points, etc that can
be hidden. This could be achieved using a ``no header'' option like... again...
blender. I'm open to new ideas about this
- Scaling the clips vertically could be a good idea, especcially when working
with too many tracks. Using an amplifier tool could do the magic.
- Should allow tabbing, to have more than a timeline at in a project. We can
create a +{scene-1, scene-2, scene-3}+ timelines and then mix them in a
fourth timeline called ``film'' as if they were simple strips...
* Viewport
- The viewport should be interactive. Maybe a key toggle to allow panning and
zooming. Clicking on it should make the clicked clip to transform. Being able
to keys in the current keyframe to things like rotation, translation, and
scale. Maybe opacity with the mouse wheel.
- Clicking on the clip the first time, will add a transform node before its
out node. This transform node, has as input a time curve node, which will
be keyframmed.
- Should allow seeing the result of the current timeline, or a custom media
library element.
- Should allow setting In/out points to allow inserting in the timeline.
- Transform trayectory is shown in the interactive interface of the visor.
Of course if the strip/node layout is selected.
* Palette
- For custom common tasks, like Maya's toolbar.
* Effects and Transitions
- A section where we can drag and drop nodes and transitions to the node
compositor/timeline
- Transitions can be added in both, timeline and node editor. I'm open to
new ideas about this
- Droping a node on a stripe would add it before its out node, Using the
nodes, default connections. This way the program can be used as a normal
NLE or a compositor in a seamless way.
* Options
- Shows the options for the current node layout the one selected in current
timeline. What happens when we have two timelines modules showing different
timelines? Each options modules has a bar to select what timeline is using.
I don't understand why someone would want two timelines modules running
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.
Just like Blender's IPO curves.

View file

@ -1,6 +1,7 @@
Timeline: Discussion
====================
:author: Joel Holdsworth
:Author: Joel Holdsworth
:Date: Fall 2008
This is Joel Holdsworth's attempt to amalgamate all the ideas from all the brainstorming to one consistent idea that makes sense, can be implemented, and seems like it would be nice to use. Comments are welcome.
@ -410,3 +411,10 @@ apply to "all applicable" is not actually a problem. Again, in the rare cases
where more is needed, the user is free to split off a channel as a separate
clip.
.historical Note by Ichthyo (2/2011)
This page sumarises the state of the GUI Discussion in early 2009 +
Since end of 2009, Gui development is mostly stalled (Joel left the project
due to other obligations). Meanwhile we had a bit of discussion here and there,
and personally I got a somewhat clearer understanding of what the Model in
Proc-Layer can / will provide. But basically that's along the lines of what
I wrote in my last comment at the bottom of this page

View file

@ -4,15 +4,14 @@ GUI Design and Feature Discussion
In the early stages of the project, there was a lot of debate regarding
GUI concepts and -features and proposals.
- link:GuiBrainstormingReviewed.html[GUI Brainstorming page] 'TODO: explain whats this all about'
- link:GuiBrainstormingReviewed.html[GUI Brainstorming page] '[red]#TODO#: explain whats this all about'
- several Proposals
* link:Proposal.AkhiL.html[AkhIL]
* link:Proposal.Alcarinque.html[Alcarinque]
* link:Proposal.RichardSpindler.html[Richard Spindler]
* link:Workspaces.html[about Workspace organsiation]
* link:scrolling.html[about scrolling..]
* link:MenuAndShortcuts.html[Ideas for menus and shortcuts]
- link:TimelineDiscussion.html[Conclusions by Joel Holdsworth]
[icon="warning.png"]
WARNING: Website under construction

View file

@ -16,8 +16,3 @@ integral, so its rather treated separately of individual GUI features.
.*TODO* more contributions please... ;-)
We had several additional discussions and contributions on the mailinglist,
several people did even concept drawings. Collect these and add them here
[icon="warning.png"]
WARNING: Website under construction

View file

@ -1,51 +1,67 @@
== Lumiera Design Documents
Lumiera Design Documents
========================
The goal of Lumiera is to provide a professionnal tool for video editing on GNU/Linux systems.
The vision of the development team defines a modern design for the core of a Non-Linear Editing software.
One of the key aspect of Lumiera is the strong separation between the user interface and the processing core.
Lumiera as a software will come along with a GTK GUI but that does not make this exclusive, any other GUI could be written as well as scripts to drive the core.
This is made possible by the above-mentioned quality of Lumiera being considered as two strictly separate parts.
Lumiera as a processing core will be able to do anything possibly conceivable, therefore it may be used to do any task on video (and audio?), even unrelated to video editing.
The goal of Lumiera is to provide a professional tool for video editing on
GNU/Linux systems. The vision of the development team defines a modern design
for the core of a Non-Linear Editing software. One of the key aspect of Lumiera
is the strong separation between the user interface and the processing core.
Lumiera as a software will come along with a GTK GUI but that does not make this
exclusive, any other GUI could be written as well as scripts to drive the core.
This is made possible by the above-mentioned quality of Lumiera being considered
as two strictly separate parts. Lumiera as a processing core will be able to do
anything possibly conceivable, therefore it may be used to do any task on video
(and audio?), even unrelated to video editing.
.Workflow
****
The word Workflow is used to name the way tasks can be achieved in an application. Any operation in Lumiera must be possible in the most suitable and stringent fashion. The Workflow is closely related to how flexible the GUI is but also the concern of deeper and more technical parts of the application.
****
=== Overview
The internal structure of Lumiera is divided in numerous subsystems.
This overview will try to go through the elements from the highest to the lowest piece of the structure.
They can be categorized into three main categories plus extra components :
Overview
--------
==== link:gui/index.html[Graphical User Interface]
The internal structure of Lumiera is divided in numerous subsystems. This
overview will try to go through the elements from the highest to the lowest
piece of the structure. They can be categorized into three main categories plus
extra components :
User interfaces are basically handled like plugins, consequently it is possible to interface with Lumiera through scripts. It is also possible to create specialized GUIs.
The interface is the closest component to the user, it is purely visual. There the user manipulates, organizes, loads, configures all sorts of datas, especially MObjects (media objects) and Assets. These elements are contained within a structure called the Session.
link:gui/index.html[Graphical User Interface]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
==== The Processing Layer
User interfaces are basically handled like plugins, consequently it is possible
to interface with Lumiera through scripts. It is also possible to create
specialized GUIs. The interface is the closest component to the user, it is
purely visual. There the user manipulates, organizes, loads, configures all
sorts of datas, especially MObjects (media objects) and Assets. These elements
are contained within a structure called the Session.
The Processing layer (or proc) is where the elements from the Session are assembled to form a network of nodes, to be sent to the Backend. The lowest data structure is called the Low-level model. +
The Processing Layer
~~~~~~~~~~~~~~~~~~~~
The Processing layer (or proc) is where the elements from the Session are
assembled to form a network of nodes, to be sent to the backend. The lowest data
structure is called the Low-level model. +
* link:model/index.html[Model] +
* link:engine/index.html[Engine]
==== link:backend/index.html[The Backend]
link:backend/index.html[The Backend]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The backend uses the Low-level model. It allows the rendering and makes a heavy use of the Input/Output System to the screen or to external monitors.
The backend uses the Low-level model. It allows the rendering and makes a heavy
use of the Input/Output System to the screen or to external monitors.
Extra components
----------------
link:application/index.html[The Application]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The application controls the initialization and shutdown procedures as well as loading external elements like plugins that are widely used.
The application controls the initialization and shutdown procedures as well as
loading external elements like plugins that are widely used.
link:plugins/index.html[Plugins]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
They are key elements in Lumiera since the application relies heavily on this concept of modules. For example, the GUI of Lumiera is a plugin.
Plugins are key elements in Lumiera since the application relies heavily on this
concept of modules. For example, the GUI of Lumiera is a plugin.

View file

@ -3,7 +3,3 @@ Design Documents: Model
* two models: high-level and low-level
* RfC: link:{rfc}/../rfc_pending/ProcHighLevelModel.html[high-level model basics]
[icon="warning.png"]
WARNING: Website under construction

View file

@ -2,7 +2,3 @@ Design Documents: Plug-In
=========================
* link:PluginBrainstorm.html[early draft for the plugin interface]
[icon="warning.png"]
WARNING: Website under construction

View file

@ -9,8 +9,3 @@ integral, so it's rather treated separately of individual GUI features.
-> see also link:../gui/index.html[general GUI discussion...]
* link:LumieraWorkflowOutline.html[Workflow outline by BJMR]
[icon="warning.png"]
WARNING: Website under construction

1
doc/devel/draw/rendered Symbolic link
View file

@ -0,0 +1 @@
../../../wiki/draw

View file

@ -1,6 +1,7 @@
Statistics and Reports
======================
//Menu: label Statisticts
++++++++++++++++++++++++++++++++++++++
@ -17,19 +18,29 @@ Statistics and Reports
++++++++++++++++++++++++++++++++++++++
''''
^Statistics generated automatically by *Ohloh* based on Git master^
^Statistics generated automatically by *Ohloh* based on Git master.^
Tickets
-------
* link:http://issues.lumiera.org/query?group=status&milestone=0integration[report: Milestone Integration]
* link:http://issues.lumiera.org/report/14[recently changed tickets]
* link:http://issues.lumiera.org/report/8[core tickets in work]
* link:http://issues.lumiera.org/report/13[blocked tickets]
* link:http://issues.lumiera.org/report/5[stalled tickets]
* link:http://issues.lumiera.org/report/15[non-codin small tasks]
See the link:http://issues.lumiera.org/report[Trac overview for more ticket reports]
See the link:http://issues.lumiera.org/report[Trac overview] for more ticket reports.
[icon="warning.png"]
WARNING: Website under construction
Mailing List
------------
image:http://gmane.org/plot-rate.php?group=gmane.comp.video.lumiera.general[Lumiera Mailinglist activity] +
^activity stats by link:http://dir.gmane.org/gmane.comp.video.lumiera.general[Gmane.org]^
....
....

View file

@ -1,28 +1,42 @@
Design Process
==============
//Menu: include rfc
//Menu: include rfc_pending
//Menu: include rfc_dropped
//Menu: put child 'rfc_dropped' after 'rfc'
How it Works
------------
Design Process entries (RfC) can be created by anyone.
Each entry goes through several stages until it's accepted (or rejected).
All our RfC entries are filed here, either in the link:rfc/index.html[RfC accepted] section,
or as link:rfc_pending/index.html[pending RfC] or as link:rfc_dropped/index.html[RfC dropped].
* Every proposal starts out as _*Idea*_, allowing other people to review and comment on it, while still working out details.
* When the _Idea_ is in a proper shape and worked out in most details it becomes a _*Draft*_. This _Draft_ need to be carefully reviewed, commented, perhaps corrected and rated by the other Developers.
* When the _Idea_ is in a proper shape and worked out in most details it becomes a _*Draft*_.
This _Draft_ need to be carefully reviewed, commented, perhaps corrected and rated by the other Developers.
* We decide on some proposals to talk about that another time, these get a _*Parked*_ state.
* At some point we may decide that a _Draft_ becomes a _*Final*_. Usually, this happens in our link:MonthlyMeetings[]. _Final_ Documents will be imported into the git repository (currently to the tiddlywiki).
* Sometimes proposals will become dropped for some reason, this is indicated by changing their state to _*Dropped*_, they still stay in the system for further reference.
* At some point we may decide that a _*Draft*_ becomes a _*Final*_.
Usually, this happens in our link:/devs-vault/meeting/index.html[monthly developers meetings].
* Sometimes proposals will become dropped for some reason, this is indicated by changing their state to _*Dropped*_,
they still stay in the system for further reference.
Generally you should refrain from editing someone others proposals (except for typo and gramatic fixes) when this is not acknowleded with the original author. Rather only add comments to the pages and end them with `@SIG@` to make it easier to find out who is the contact person for some note.
Generally you should refrain from editing someone others proposals (except for typo and grammar fixes)
when this is not acknowledged with the original author. Rather only add comments to the pages and please
care to sign your comments in order to make it easier to find out who is the contact person for some note.
.Add a new Proposal:
. Check if there is no similar proprosal below! If yes, contact it's author and contribute to that one.
. Think of a good/descriptive *WikiName* for the Proposal. It will be used to create a RfC subpage.
. Read the instructions and add your proposed text.
What qualifies as an RfC proposal
---------------------------------
CAUTION: to be written
Handling of RfC entries in practice
-----------------------------------
.Adding a new Proposal:
. Check if there is no similar proposal below! If yes, contact it's author and contribute to that one.
. Think of a good/descriptive _Name-ID_ for the Proposal. It will be used to create a RfC sub-page, so no embedded spaces please.
. [red,yellow]#!TODO!# _please describe how to use the +rfc.sh+ here_.
* link:rfc[RfC accepted]
* link:rfc_pending[RfC pending]
* link:rfc_dropped[RfC dropped]
[icon="warning.png"]
WARNING: Website under construction

View file

@ -170,5 +170,6 @@ after a talk on irc, we decided to do it this way, further work will be
documented in the repository (tiddlywiki/source)
-- link:ct[] [[DateTime(2007-07-11T13:10:07Z)]]
''''
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -12,9 +12,10 @@ Architecure Overview
--------------------
This proposal intends to capture envisioned Architecture of the Application.
See the SVG drawing
http://www.lumiera.org/gitweb?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Archi
ecture-1.svg;hb=HEAD[Overview of Lumiera Architecture)] maintained in GIT
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]^
Description
@ -38,10 +39,11 @@ Description
Comments
--------
* Alcarinque made http://telniratha.atspace.com/ui_architecture.jpg[some
drafts] for the ui. Here is the
http://telniratha.atspace.com/ui_architecture.odg[oodraw document]. This is
not a technical draft at all, it is just an idea.
* Alcarinque made link:/documentation/design/gui/GuiDiscussion/Proposal.Alcarinque.html[some
design drafts] for the UI. Here is the
link:/documentation/design/gui/GuiDiscussion/Proposal.Alcarinque.svg[SVG source] (converted
from OODraw by Ichthyo 2011). This is not a technical draft at all, it is just
an idea.
* Wouldn't the Config Rules (embedded Prolog) also interact with the High
Level Model? Or would that be expanding its scope too much? I imagine
@ -75,4 +77,4 @@ maintained in future.
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -212,4 +212,4 @@ point", i.e. every point in the sytem, that can be extended by plugins.
-- 217.110.94.1 [[DateTime(2007-07-10T17:23:33Z)]]
''''
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -97,4 +97,4 @@ most any style. The only thing I really dislike is using tabs (with the
exeption of database DDLs and CSound files, where tab are actually helpful) :)
''''
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -72,4 +72,4 @@ Developement takes place in the repo now
-- link:ct[] [[DateTime(2007-06-27T16:14:56Z)]]
''''
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -128,4 +128,4 @@ We have now a \'compatibility wiki\', finalized this proposal
-- link:ct[] [[DateTime(2008-03-26T13:43:26Z)]]
''''
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -62,4 +62,4 @@ much discussion
-- link:ct[] [[DateTime(2007-06-27T16:07:13Z)]]
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -163,4 +163,4 @@ This Design Entry concerns whether to include such a feature and discusses the
general questions when doing so. As we for sure include meta-clip, and so so
exactly in the way described here, this proposal is 'final' now.
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -185,4 +185,4 @@ on such an init, but i would add one if really needed.
basically agreed on it iirc.
-- link:ct[] [[DateTime(2008-07-26T09:08:11Z)]]
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -53,4 +53,4 @@ Comments
* Accepted, deployed, done ... Final
-- link:ct[] [[DateTime(2007-06-27T16:13:25Z)]]
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -139,4 +139,4 @@ make no guarantee about backwards compatibility. When we spot someone using
this interfaces we ''will break'' his plugin ''intentionally''!
-- link:ct[] [[DateTime(2008-10-24T03:43:43Z)]]
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -81,4 +81,4 @@ wiki (or maybe bouml).
Comments
--------
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -109,4 +109,4 @@ Comments
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -53,4 +53,4 @@ repos to push relevant things, be careful not to push cruft or tags (which tags
shall be present here is not yet resolved -> no tags for now)
-- link:ct[] [[DateTime(2008-04-08T21:48:51Z)]]
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -94,4 +94,4 @@ Comments
we have more devs than now :P)
-- link:ct[] [[DateTime(2007-06-17T17:20:37Z)]]
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -51,4 +51,4 @@ cehteh will care for further integration
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -74,4 +74,4 @@ This proposal reflects a distinct approach taken right from start.
Marked 'final' at October.2008 developer meeting
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -118,4 +118,4 @@ Comments
in the git repository (and we already started to define things there) see
./admin/treeinfo.sh -- link:ct[] [[DateTime(2007-06-27T16:01:52Z)]]
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -142,4 +142,4 @@ Conclusion
Lua is '''accepted''' as the required scripting language by October.2008 dev
meeting.
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -138,4 +138,4 @@ Conclusion
added on demand. When doing so, we need to add thorough test coverage for
time calculations too.
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

11
doc/devel/rfc/index.txt Normal file
View file

@ -0,0 +1,11 @@
Accepted Design Proposals
=========================
//Menu: label accepted
//Menu: sort children
-> read link:../rfc.html[more about Lumiera RfC] and the Design Process
The RfC entries listed here where discussed, maybe modified and finally agreed upon
during some developers meeting in the past. So they represent design decisions taken.

View file

@ -183,10 +183,9 @@ don't think we get much program options, maybe something to set a GUI skin.
Moreover, I've written last year a thin wrapper around the commandline and
integrated it with the boost options parser such that user code can receive the
remaining options as a vector of std::strings. Please have a look at
http://git.lumiera.org/gitweb?p=LUMIERA;a=blob;f=tests/common/mainsuite.cpp;h=45
bfd98effd0b7dbe6597f712a1bdfa35232308;hb=HEAD[the test class runner main] for
an usage example. I really want our Lumiera main to be clean and expressive in
the way showed there. Probably the most important part of the startup is
link:http://git.lumiera.org/gitweb?p=LUMIERA;a=blob;f=tests/common/mainsuite.cpp;h=455bfd98effd0b7dbe6597f712a1bdfa35232308;hb=80e1e382f42512ebf2e10a802f77e50327b8fb73[the test class runner main]
for an usage example. I really want our Lumiera main to be clean and expressive
in the way showed there. Probably the most important part of the startup is
pulling up the session core; because of that I think most of the startup
process falls into the realm of the Proc-Layer. Within Proc, I don't want any
significant string manipulations done with C-strings and I don't want raw
@ -198,4 +197,4 @@ to document this here :P
-- link:ct[] [[DateTime(2009-02-03T17:28:28Z)]]
''''
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -84,4 +84,4 @@ We concluded that that submodules are not yet needed with exception for the
./doc folder. Parked for now.
-- ct 2008-07-26 09:09:57
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -424,4 +424,4 @@ is inherently dangerous. We think the basic algorithms involved are
sufficiently well-known and understandable to implement them in a sound manner.
''''
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -158,4 +158,4 @@ Comments
[[DateTime(2008-08-04T18:33:58Z)]]
''''
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -77,4 +77,4 @@ Comments
--------
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -78,4 +78,4 @@ link:DelectusShotEvaluator[Delectus]
''''
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -46,4 +46,4 @@ Comments
We decided to use a Tiddlywiki for now until this is further worked out
-- link:ct[] [[DateTime(2008-03-08T03:38:50Z)]]
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -0,0 +1,18 @@
Design Proposals not accepted
=============================
//Menu: label dropped
//Menu: sort children
-> read link:../rfc.html[more about Lumiera RfC] and the Design Process
The RfC entries listed here where discussed, but then concluded not to be applicable
for some reason. Either the discussion turned up a completely different solution, or
maybe they got just superseded by changing circumstances.
Besides that, sometimes we find an entry impossible to care for and discuss in detail
currently, because we know to be occupied with other stuff. In that case, we put that
entry ``on hold'' (state _*Parked*_). Currently (as of 2/2011) these entries show
up in this category here too.

View file

@ -117,4 +117,4 @@ without even having to "drive" the development..
--link:Tree[][[DateTime(2008-08-27T20:38:00NZ)]].
''''
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -385,4 +385,4 @@ very expensive. I'm a sound guy, so I feel your pain...
- link:NicholasSA[] 2009-01-04
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -81,4 +81,4 @@ Comments
--------
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -118,4 +118,4 @@ Comments
--------
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -242,4 +242,4 @@ Conclusion
////////////////////
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -186,4 +186,4 @@ link:Plugin/Interface[] system self-describing this will also be used to
bootstrap a session on itself (by the serializer which is tightly integrated)
-- link:ct[] [[DateTime(2008-09-04T09:28:37Z)]] 2008-09-04 09:28:37
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -135,4 +135,4 @@ Comments
--------
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -134,4 +134,4 @@ Comments
--------
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -101,4 +101,4 @@ framerate" and a fixed resolution in pixels. But we certainly can do better.
-- Ichthyostega 18:09:50
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -240,4 +240,4 @@ Comments
--------
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -228,4 +228,4 @@ benchmark in more ways than one, for some time.
. --link:Tree[][[DateTime(2008-08-23T12:54:00NZ)]].
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -86,4 +86,4 @@ The good news is, that:
the matrix can be transformed from e.g. RGB to YUV, so these filters can
always work in both colorspaces directly
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -203,4 +203,4 @@ with other media related projects), than this shouldn't be a barrier.
-- link:Ichthyostega[] 2009-02-01
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -231,4 +231,4 @@ frameinfo* get_frame(unsigned num)+ where +struct frameinfo+ (not yet defined)
is something like +{ void* data; size_t size; struct metadata* meta; ...}+
-- link:ct[] 2008-10-06
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -267,4 +267,4 @@ GUI handling could make use of expanded view features like ;
Tree 2008-12-19 22:58:30
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -291,4 +291,4 @@ credit roll for each episode. Add in stopmotion, and 3D model animations with
vocal commentaries. Gather together separate items from "outworkers". Tree
(@)SIG(@)
Back to link:Lumiera/DesignProcess[]
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]

View file

@ -0,0 +1,21 @@
Design Proposals in discussion
==============================
//Menu: label pending
//Menu: sort children
-> read link:../rfc.html[more about Lumiera RfC] and the Design Process
The RfC entries listed here where proposed but not finally decided or agreed on --
* entries in the _*Idea*_ stage are yet to be worked out in detail. Usually they
just sit there and only receive occasional discussions, until the original author
considers them mature and puts them on agenda on some developers meeting.
* entries in the _*Draft*_ stage are basically ready for discussion or decision;
but sometimes they are kept _on hold_ -- maybe there is something controversial
or some details need to be investigated further.
* sometimes we just decide to postpone the discussion -> see
link:../rfc_dropped/index.html[dropped and parked entries]

View file

@ -73,4 +73,7 @@ Comments
//endof_comments:
''''
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
EOF

View file

@ -1,8 +1,5 @@
== Documentation
[icon="warning.png"]
WARNING: Website under construction
This documentation section contains documentation for both users and developers.
=== User

View file

@ -1,9 +1,8 @@
Technical Documentation: Backend
================================
Eventually, this will have technical documentation for the Backend.
For now, we have:
* link:ConfigLoader.html[Config Loader brainstorming from 2008]
[icon="warning.png"]
WARNING: Website under construction

View file

@ -1,5 +1,7 @@
Lumiera Buildsystem
===================
Lumiera build system
====================
As work progresses, we will add more information on the Lumiera build system.
build -- continuous integration -- packaging
@ -7,9 +9,7 @@ build -- continuous integration -- packaging
* Autotools
* Dependencies
* link:BuildDroneDraft.html[»Builddrone« concept from 2008]
* packaging: Debian RPM
* Packaging: Debian RPM
* Lumiera debian depot
[icon="warning.png"]
WARNING: Website under construction

View file

@ -1,7 +1,5 @@
Technical Documentation: GUI
============================
[icon="warning.png"]
WARNING: Website under construction
Eventually, this will have technical documentation for the GUI.

View file

@ -1,6 +1,8 @@
Developer HOWTOs
================
//MENU: title Dev HOWTOs
This section contains a loose collection of instructions, recipes, tutorials and
similar usefull pieces of information targeted at Lumiera developers. See also
@ -10,9 +12,3 @@ similar usefull pieces of information targeted at Lumiera developers. See also
== Notepad
- link:DebugGdbPretty.html[Python pretty printers for GDB]
[icon="warning.png"]
WARNING: Website under construction

View file

@ -2,13 +2,16 @@ Technical Documentation
=======================
This documentation section contains technical documentation about Lumiera.
To get an overview of all the internals and components, you might want to read
This documentation section contains technical documentation about Lumiera. To
get an overview of all the internals and components, you might want to read
link:innerCore/the_inner_core.html[Lumiera the Inner Core]
== Three Layers
The technical documentation is split in three parts, one for each of the three main layers of Lumiera.
You may want to read the link:../design/index.html[Design Documents] first to get an overview of all the components.
The technical documentation is split in three parts, one for each of the three
main layers of Lumiera. You may want to read the
link:../design/index.html[Design Documents] first to get an overview of all the
components.
* link:gui/index.html[*Graphical User Interface*] : Documents related to the GTK based Lumiera GUI
@ -28,9 +31,3 @@ You may want to read the link:../design/index.html[Design Documents] first to ge
.HOWTO
* link:howto/index.html[*Developer HOWTOs*] : Collection of instructions, recipes, hints and similar
materials intended for developers
[icon="warning.png"]
WARNING: Website under construction

View file

@ -0,0 +1,277 @@
Website Navigation Generator
============================
:Author: Hermann Voßeler
:Date: 2/2011
This page contains documentation and notes regarding the +menugen.py+ --
written 2/2011 during our attempt to get the new Lumiera website online finally.
The link::http://git.lumiera.org/gitweb?p=website-staging;a=blob;f=menugen.lua;h=aad2129d7f4ed3f3b35b2fc3ac2a63a9f1bfb62d;hb=menugen[initial draft version] was written by _cehteh_ in Lua
**************************************************************************
The purpose of the +*menugen*+ script is to maintain the navigation menu
on the Lumiera website semi-automatically. In the usual setup, this script
is triggered from a _Git push_ -- it walks the web subdirectories and
discovers menu entries. The generated HTML page contains both visible
elements and JavaScript snippets to display and highlight the menu
on the client side appropriately
**************************************************************************
Overview: how it works
----------------------
The menu generation and display is comprised of several parts working together
. the +build_website.sh+ is triggered as a Git post-receive hook, whenever new
commits are transfered to the website Git repository. After discovering new
Asciidoc source files and generating the corresponding HTML files, the
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
. after building a complete menu tree (actually a DAG), this data structure
is walked to generate output HTML into a `menu.html` file in website root.
. the page template (`page.conf`) for generated Asciidoc pages contains an
+<IFrame>+ to display this `menu.html`
. when loading `menu.html`, some JavaScript elements generated into the body
alongside with the visible content will execute, causing a lookup table
in the client side memory being populated with the menu entries and parent
dependencies. Each individual menu entry has an attached unique ID, originally
generated by the server side +menugen+ script. The clientside JavaScript always
addresses elements directly through these IDs, mostly ignoring the actual DOM
structure
. whenever a new webpage is loaded, the `onload` handler on the +<IFrame>+ (or
a similar mechanism) invokes the +markPageInMenu()+ JavaScript function, which
addresses the IFrame by its ID `inavi`, and calls into the JavaScript located
there. This script in turn finds the menu entry corresponding to the current
page with the help of the lookup table mentioned above; this allows to highlight
the current page and fold any other branches of the menu to keep the visible
part reasonably small to fit on a single page
. folding and highlighting changes are done by manipulating the style of these
elements; the actual presentation is mostly controlled by a `menu.css`
. any further JavaScript functions used to operate the menu are located in
the statically served `menu.js` -- the generated menu contains only the
``moving parts''
Configuring menu generation
---------------------------
While, generally speaking, the script was written to remove the need to care
for the menu most of the time, there are numerous extension points and configuration
options to deal with special cases. Adjustments can be done on several levels:
* the +menugen+ python script contains in embedded set of _predefined menu entries,_
forming the backbone of the generated menu. The use of this feature is optional
and can be enabled with the `-p` or `--predefined` switch. These predefined
configuration steps are done in a function +addPredefined()+ right at the top;
the configuration is written in the style of an _internal DSL_ and should be
fairly self explanatory.
* when discovering Asciidoc page sources, special `//MENU:` directives are
processed (`//` marks an Asciidoc comment). The remainder of such a line
is always parsed as a single directive; in case of a parsing error a warning
is printed and the line will be ignored. The individual directives mostly
correspond to similar functions usable in the aforementioned internal DSL;
actually both kinds of configuration have the same effect: they attach
some modification command to the menu element in question. Note especially
that such directives can modify the discovery of further pages -- pages
can be attached, excluded, ordered; and the discovery can be redirected
to another subdirectory.
* the actual code generation is mostly based on python template code contained
in a separate script +menuformat.py+ -- located alongside the main menu generator
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+ --
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
code). The current version of this CSS stylesheet makes heavy use of _contextual
selectors_ and the general cascading mechanism to build up the final style; e.g.
the indentation according to the menu level is done by attaching a style based
on the number of nested HTML elements.
Summary of menu placement directives
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
With the term _placement directives_ we denote all the adjustments and configuration
possible either through the internal DSL for the predefined menu structure, or through
the `//Menu:` lines in the individual pages.
addressing menu nodes
^^^^^^^^^^^^^^^^^^^^^
Each menu entry corresponds to a menu node in the internal data structure. In the most
general case, this structure is a _Directed Acyclic Graph_, because a node might be
hooked up below several different parent nodes. In this case, such a node will also
be visited multiple times for code generation -- one time for each parent it is
attached below. Amongst these parent nodes, the first parent node attached is called
the _primary parent_, because this first attachment of a node defines the _logical
path_ uniquely describing this node. Note, this logical path can be different to
the actual web paths / URLs generated, and also be different to the file system
path where the source file resides. It is just defined by the chain of parent
nodes leading to the root of the menu data structure.
The leaf element of this logical menu path is called the _ID_ of the node. Typically
this ID corresponds to the filename without the extension. But for the code generation
and the client sides JavaScripts, the full menu path is used as an HTML id element,
because -- generally speaking -- only the full menu path denotes an element unambiguously.
When working with nodes, and especially when writing placement directives in the individual
source files, in most cases it is not necessary to specify the full menu path of a node.
Actually, nodes can be addressed by any path suffix, and even just by the bare node ID.
But when there is an ambiguity, just the first node found is picked. Because nodes have
an unique identity, this can sometimes yield rather wired results. To minimise the
danger of ambiguities, the _discovery_ of source pages always addresses the menu node
to be populated with the full menu path.
configuration example
^^^^^^^^^^^^^^^^^^^^^
[source,python]
--------------------------------------------------------------------------
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('http://issues.lumiera.org/roadmap', label="Roadmap (Trac)") <5>
Node('rfc').sortChildren()
--------------------------------------------------------------------------
<1> the _root node_ by convention uses a special ID token. Additional
fields of the node object can be given as named parameters. Here
we define the visual menu label to be ``Lumiera''
<2> a child node `root/project` is attached. Note: this node will
later be picked up, when the actual page discovery delves down
into the 'project' subdirectory and encounters a 'index.txt'
there. Index files are always searced _within_ the directory;
they may be called `index.txt` or use the same name as the
enclosing directory.
<3> this placement directive defines that a node `screenshots`
shall be prepended at the start of the list. Because such a node
doesn't yet exist, a new node `root/project/screenshots` is
created as a side-effect.
<4> this directive places an entry after another entry, which is
assumed to exist when this directive gets applied finally.
All placement directives get applied in order of definition,
just before the output for a given node is generated.
Note also the constructor syntax +Node(\'screenshots')+: here
the constructor just acts as a general factory function; either
it creates a new node, or it fetches an existing node with matching
node path from the internal +NodeIndex+
<5> here we create a submenu entry in the project menu, featuring
an external link. The ID of that menu node will be derived from
the name in the url (here `roadmap`) -- it can be defined explicitly
if necessary (+id=...+)
supported placement directives
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[options="header", width="70%",cols="^m,<m,s<",frame="topbot",grid="all"]
`------------------------`------------------------------------`---------------------------------------------------
internal DSL Asciidoc source
Node(<id>) -- discover `id.txt` -- create new node or retrieve existing node
linkChild(id) basic function for attaching child node
linkParent(id) basic function to attach below parent
putChildLast(id) [attach] child <id> move child to current end of list
appendChild(id) [append] child <id>
putChildFirst(id) move child to current list start
prependChild(id) prepend [child] <id>
putChildAfter(id,ref) [attach|put] child <id> after <ref> move child after the given ref entry
link(url[,id][,label]) [child <id>] link ::<url>[<label>] attach an entry, holding an external link
Node(<id>,label=<lbl>) label|title <lbl> define the visible text in the menu entry
sortChildren() sort [children] sort all children currently in list
enable(False) off|disable|deactivate make node passive; any children/parents added later are ignored
enable([True]) on|active|activate make node active again (this is the default)
detach() detach cut away any parents and children, disable the node
discover(srcdirs=...) include dir <token>[,<token>] instead of current dir, retrieve children from other dirs (relative)
discover(includes=...) include <token>[,<token>] explicitly use the listed elements as children
discover(excludes=...) exclude <token>[,<token>] after discovering, filter names matching the <token> (without extension)
--------------------------------------------------------------------------------------------------------------------
commandline options
^^^^^^^^^^^^^^^^^^^
The behaviour of the +menugen+ script can be influenced by some options:
predefined:: using the built-in predefined nodes
scan:: discover nodes
debug:: dump data structure after discovery
text:: generate plaintext version of the menu
webpage:: actually generate HTML / JavaScript
a positional parameter denotes the start directory for discovery (default is current).
This directory is assumed also to be the web root; any URLs are generated relative
Design and Implementation notes
-------------------------------
The initial observation was that actually we're parsing and processing some kind of
_Domain Specific Language_ here. Thus the general advice for such undertakings does
apply: we should try to handle the actual language just as a thin layer on top of
some kind of _semantic model_. In our case, this model is the menu tree to be generated,
while the actual ``syntax tree'' is the real filesytem, holding Asciidoc files with
embedded comments. Thus, the semantic model was developed first, and separate of the
syntax of the specifications; it was tested to generate suitable HTML and CSS.
The syntactic elements where then added as a collection of parser or matcher objects,
each with the ability to recognise and implement one kind of placement specification.
Each such +Placement+ subclass exposes an +acceptVerb()+ function for handling invocations
of the internal DSL functions, and an +acceptDSL()+ function to parse and accept a
`//Menu:` line from some Asciidoc source file. This approach makes adding further
configuration options simple.
Another interesting question is to what extent the actual path handling and file discovery
logic should be configurable. My reasoning is, that any attempts towards larger flexibility
are mostly moot, because we can't overcome the fact that this *is* logic to be cast into
program code. Extension points or strategy objects will just have the effect to tear apart
the actual code thus will make the code harder to read. Thus I confined myself just to
configure the index file name and file extensions.
Known issues
~~~~~~~~~~~~
* for sake of simplicity, there is _one_ generated container HTML element
per menu entry. In case this entry is a submenu, the `<ul>`-element is
used, _not_ the preceding headline `<li>` -- this is due to the fact
that this submenu entry is going to be collapsed eventually, but has
the side-effect of highlighting _only_ that submenu block, _not_ the
preceding headline.
* the acceptable DSL syntax needs to be documented manually; there is
no way to generate this information. Doing so would require to add
specific information methods into Placement subclasses, and it would
result in duplicated information between the regular expressions
and the informations returned by such information methods.
This was deemed dangerous.
* the +\_\_repr\_\_+ of the Placement subclasses is not an _representation_
but rather a +\_\_str\_\_+ -- but unfortunately the debugger in PyDev
invokes +\_\_repr\_\_+
* the startdir for automatic discovery is an global variable
* when through the use of redirection, the same file is encountered
multiple times during discovery, it is treated repeatedly, each times
associated with another node, because, on discovery, the node-ID is
generated as +parentPath/fileID+, to avoid mixing up similarly named
files in different directories. (The NodeIndex allows to retrieve
a node just by its bare ID, without path anyway)
* no escaping: currently any variable text is written to the generated
HTML without any sanitising or escaping. This might be a security issue,
especially because Git pushes immediately trigger menu generation.
* the method Node.matches() is implemented sloppily: it uses just a mutual
postfix match, while actually it should line up full path components and
check equality on components, starting from the path end. This cheesy
implementation can yield surprising side-effects: e.g. an not-yet attached
node `\'end'` could match a new menu page `\'documentation/backend'`

View file

@ -0,0 +1,13 @@
Infrastructure
==============
Various details, documentation and other pieces of information regarding
the infrastructure of the Lumiera project. This includes the infrastructure
used for building and maintaining documentation and website.
* see link::../build/index.html[separate page for the Buildsystem]
* generating the link::MenuGen.html[navigation menu] for the website

View file

@ -1,7 +1,28 @@
Technical Documentation: Proc-Layer
===================================
Eventually, this section will hold technical documentation for the Proc-Layer.
Proc-Layer TiddlyWiki
---------------------
Hermann Voßeler, core developer of the Proc-Layer uses an separate embedded wiki
for his day-to-day design sketches, notes and also for the more persistent planning.
This *TiddlyWiki* is a nifty JavaScript wiki embedded in a single HTML page; as such
it lives right within the source tree, where it can be worked on alongside with the
code. Besides the actual planning and descriptions, this wiki also links to the
UML diagrams created with *BOUML* during the ongoing planning and design.
This setup started as a temporary solution -- but as uWiki is not expected to come
to life soon, the current website can't serve as replacement for a real wiki, an
we'll stick to that situation for the time being. As the content in the TiddlyWiki
becomes more mature and stable, it will be moved over into this section here.
While additions to the TiddlyWiki generally propagate to Lumiera/Master through
the normal merges, we've put up a rsynced version of the TiddlyWiki online for
direct access (of course read-only).
-> access the Proy-Layer link:http://lumiera.org/wiki/renderengine.html[TiddlyWiki online here]
[icon="warning.png"]
WARNING: Website under construction

View file

@ -1 +0,0 @@
skeletons for formal documents

View file

@ -1,13 +1,8 @@
User Documentation
==================
'to be written...'
* link:manual.html[We need to write a user manual....]
* link:manual.html[User Manual] _(planned)_
* The following document might become an introductory overview: +
link:outerSpace/lumiera_from_outer_space.html[Lumiera (as seen) from Outer Space]
* link:outerSpace/Glossary.html[Glossary of common terms]
[icon="warning.png"]
WARNING: Website under construction

View file

@ -1,9 +1,8 @@
Lumiera User Manual
===================
'to be written...'
The plan is to create the users manual later in a colaborative
fashion, similar to what turned out so effective for Cinelerra.
[icon="warning.png"]
WARNING: Website under construction
This work is postponed until the software is actually working.