Merge documentation improvements form new Lumiera.org website
This commit is contained in:
commit
069ebf9415
78 changed files with 1299 additions and 182 deletions
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,5 @@
|
|||
Design Documents: Backend
|
||||
=========================
|
||||
|
||||
|
||||
[icon="warning.png"]
|
||||
WARNING: Website under construction
|
||||
Eventually, this will have design documentation for the Backend.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,5 @@
|
|||
Design Documents: Renderengine
|
||||
==============================
|
||||
|
||||
|
||||
[icon="warning.png"]
|
||||
WARNING: Website under construction
|
||||
Eventually, this will have design documentation for the Engine.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
579
doc/design/gui/GuiDiscussion/Proposal.Alcarinque.svg
Normal file
579
doc/design/gui/GuiDiscussion/Proposal.Alcarinque.svg
Normal 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 |
171
doc/design/gui/GuiDiscussion/Proposal.Alcarinque.txt
Normal file
171
doc/design/gui/GuiDiscussion/Proposal.Alcarinque.txt
Normal 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.
|
||||
|
||||
|
||||
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,3 @@ Design Documents: Plug-In
|
|||
=========================
|
||||
|
||||
* link:PluginBrainstorm.html[early draft for the plugin interface]
|
||||
|
||||
[icon="warning.png"]
|
||||
WARNING: Website under construction
|
||||
|
||||
|
|
|
|||
|
|
@ -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
1
doc/devel/draw/rendered
Symbolic link
|
|
@ -0,0 +1 @@
|
|||
../../../wiki/draw
|
||||
|
|
@ -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]^
|
||||
|
||||
....
|
||||
|
||||
|
||||
|
||||
....
|
||||
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -109,4 +109,4 @@ Comments
|
|||
|
||||
|
||||
|
||||
Back to link:Lumiera/DesignProcess[]
|
||||
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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
11
doc/devel/rfc/index.txt
Normal 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.
|
||||
|
||||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -77,4 +77,4 @@ Comments
|
|||
--------
|
||||
|
||||
|
||||
Back to link:Lumiera/DesignProcess[]
|
||||
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -78,4 +78,4 @@ link:DelectusShotEvaluator[Delectus]
|
|||
''''
|
||||
|
||||
|
||||
Back to link:Lumiera/DesignProcess[]
|
||||
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
18
doc/devel/rfc_dropped/index.txt
Normal file
18
doc/devel/rfc_dropped/index.txt
Normal 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.
|
||||
|
||||
|
||||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -81,4 +81,4 @@ Comments
|
|||
--------
|
||||
|
||||
|
||||
Back to link:Lumiera/DesignProcess[]
|
||||
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -118,4 +118,4 @@ Comments
|
|||
--------
|
||||
|
||||
|
||||
Back to link:Lumiera/DesignProcess[]
|
||||
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -242,4 +242,4 @@ Conclusion
|
|||
////////////////////
|
||||
|
||||
|
||||
Back to link:Lumiera/DesignProcess[]
|
||||
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -135,4 +135,4 @@ Comments
|
|||
--------
|
||||
|
||||
|
||||
Back to link:Lumiera/DesignProcess[]
|
||||
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -134,4 +134,4 @@ Comments
|
|||
--------
|
||||
|
||||
|
||||
Back to link:Lumiera/DesignProcess[]
|
||||
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -240,4 +240,4 @@ Comments
|
|||
--------
|
||||
|
||||
|
||||
Back to link:Lumiera/DesignProcess[]
|
||||
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
21
doc/devel/rfc_pending/index.txt
Normal file
21
doc/devel/rfc_pending/index.txt
Normal 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]
|
||||
|
||||
|
||||
|
||||
|
|
@ -73,4 +73,7 @@ Comments
|
|||
|
||||
|
||||
//endof_comments:
|
||||
|
||||
''''
|
||||
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
|
||||
EOF
|
||||
|
|
@ -1,8 +1,5 @@
|
|||
== Documentation
|
||||
|
||||
[icon="warning.png"]
|
||||
WARNING: Website under construction
|
||||
|
||||
This documentation section contains documentation for both users and developers.
|
||||
|
||||
=== User
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,5 @@
|
|||
Technical Documentation: GUI
|
||||
============================
|
||||
|
||||
|
||||
[icon="warning.png"]
|
||||
WARNING: Website under construction
|
||||
Eventually, this will have technical documentation for the GUI.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
||||
|
|
|
|||
277
doc/technical/infra/MenuGen.txt
Normal file
277
doc/technical/infra/MenuGen.txt
Normal 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'`
|
||||
|
||||
13
doc/technical/infra/index.txt
Normal file
13
doc/technical/infra/index.txt
Normal 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
|
||||
|
||||
|
||||
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
1
doc/template/DIR_INFO
vendored
1
doc/template/DIR_INFO
vendored
|
|
@ -1 +0,0 @@
|
|||
skeletons for formal documents
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue