Lumiera TiddlyWiki is loading ...
Requires Javascript.
Welcome to TiddlyWiki created by Jeremy Ruston, Copyright © 2007 UnaMesa Association

    Background: #fff
    Foreground: #000
    PrimaryPale: #8cf
    PrimaryLight: #18f
    PrimaryMid: #04b
    PrimaryDark: #014
    SecondaryPale: #ffc
    SecondaryLight: #fe8
    SecondaryMid: #db4
    SecondaryDark: #841
    TertiaryPale: #eee
    TertiaryLight: #ccc
    TertiaryMid: #999
    TertiaryDark: #666
    Error: #f88

    /*{{{*/
    body {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}

    a {color:[[ColorPalette::PrimaryMid]];}
    a:hover {background-color:[[ColorPalette::PrimaryMid]]; color:[[ColorPalette::Background]];}
    a img {border:0;}

    h1,h2,h3,h4,h5,h6 {color:[[ColorPalette::SecondaryDark]]; background:transparent;}
    h1 {border-bottom:2px solid [[ColorPalette::TertiaryLight]];}
    h2,h3 {border-bottom:1px solid [[ColorPalette::TertiaryLight]];}

    .button {color:[[ColorPalette::PrimaryDark]]; border:1px solid [[ColorPalette::Background]];}
    .button:hover {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::SecondaryLight]]; border-color:[[ColorPalette::SecondaryMid]];}
    .button:active {color:[[ColorPalette::Background]]; background:[[ColorPalette::SecondaryMid]]; border:1px solid [[ColorPalette::SecondaryDark]];}

    .header {background:[[ColorPalette::PrimaryMid]];}
    .headerShadow {color:[[ColorPalette::Foreground]];}
    .headerShadow a {font-weight:normal; color:[[ColorPalette::Foreground]];}
    .headerForeground {color:[[ColorPalette::Background]];}
    .headerForeground a {font-weight:normal; color:[[ColorPalette::PrimaryPale]];}

    .tabSelected{color:[[ColorPalette::PrimaryDark]];
    	background:[[ColorPalette::TertiaryPale]];
    	border-left:1px solid [[ColorPalette::TertiaryLight]];
    	border-top:1px solid [[ColorPalette::TertiaryLight]];
    	border-right:1px solid [[ColorPalette::TertiaryLight]];
    }
    .tabUnselected {color:[[ColorPalette::Background]]; background:[[ColorPalette::TertiaryMid]];}
    .tabContents {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::TertiaryPale]]; border:1px solid [[ColorPalette::TertiaryLight]];}
    .tabContents .button {border:0;}

    #sidebar {}
    #sidebarOptions input {border:1px solid [[ColorPalette::PrimaryMid]];}
    #sidebarOptions .sliderPanel {background:[[ColorPalette::PrimaryPale]];}
    #sidebarOptions .sliderPanel a {border:none;color:[[ColorPalette::PrimaryMid]];}
    #sidebarOptions .sliderPanel a:hover {color:[[ColorPalette::Background]]; background:[[ColorPalette::PrimaryMid]];}
    #sidebarOptions .sliderPanel a:active {color:[[ColorPalette::PrimaryMid]]; background:[[ColorPalette::Background]];}

    .wizard {background:[[ColorPalette::PrimaryPale]]; border:1px solid [[ColorPalette::PrimaryMid]];}
    .wizard h1 {color:[[ColorPalette::PrimaryDark]]; border:none;}
    .wizard h2 {color:[[ColorPalette::Foreground]]; border:none;}
    .wizardStep {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];
    	border:1px solid [[ColorPalette::PrimaryMid]];}
    .wizardStep.wizardStepDone {background::[[ColorPalette::TertiaryLight]];}
    .wizardFooter {background:[[ColorPalette::PrimaryPale]];}
    .wizardFooter .status {background:[[ColorPalette::PrimaryDark]]; color:[[ColorPalette::Background]];}
    .wizard .button {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::SecondaryLight]]; border: 1px solid;
    	border-color:[[ColorPalette::SecondaryPale]] [[ColorPalette::SecondaryDark]] [[ColorPalette::SecondaryDark]] [[ColorPalette::SecondaryPale]];}
    .wizard .button:hover {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::Background]];}
    .wizard .button:active {color:[[ColorPalette::Background]]; background:[[ColorPalette::Foreground]]; border: 1px solid;
    	border-color:[[ColorPalette::PrimaryDark]] [[ColorPalette::PrimaryPale]] [[ColorPalette::PrimaryPale]] [[ColorPalette::PrimaryDark]];}

    #messageArea {border:1px solid [[ColorPalette::SecondaryMid]]; background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]];}
    #messageArea .button {color:[[ColorPalette::PrimaryMid]]; background:[[ColorPalette::SecondaryPale]]; border:none;}

    .popupTiddler {background:[[ColorPalette::TertiaryPale]]; border:2px solid [[ColorPalette::TertiaryMid]];}

    .popup {background:[[ColorPalette::TertiaryPale]]; color:[[ColorPalette::TertiaryDark]]; border-left:1px solid [[ColorPalette::TertiaryMid]]; border-top:1px solid [[ColorPalette::TertiaryMid]]; border-right:2px solid [[ColorPalette::TertiaryDark]]; border-bottom:2px solid [[ColorPalette::TertiaryDark]];}
    .popup hr {color:[[ColorPalette::PrimaryDark]]; background:[[ColorPalette::PrimaryDark]]; border-bottom:1px;}
    .popup li.disabled {color:[[ColorPalette::TertiaryMid]];}
    .popup li a, .popup li a:visited {color:[[ColorPalette::Foreground]]; border: none;}
    .popup li a:hover {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; border: none;}
    .popup li a:active {background:[[ColorPalette::SecondaryPale]]; color:[[ColorPalette::Foreground]]; border: none;}
    .popupHighlight {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}
    .listBreak div {border-bottom:1px solid [[ColorPalette::TertiaryDark]];}

    .tiddler .defaultCommand {font-weight:bold;}

    .shadow .title {color:[[ColorPalette::TertiaryDark]];}

    .title {color:[[ColorPalette::SecondaryDark]];}
    .subtitle {color:[[ColorPalette::TertiaryDark]];}

    .toolbar {color:[[ColorPalette::PrimaryMid]];}
    .toolbar a {color:[[ColorPalette::TertiaryLight]];}
    .selected .toolbar a {color:[[ColorPalette::TertiaryMid]];}
    .selected .toolbar a:hover {color:[[ColorPalette::Foreground]];}

    .tagging, .tagged {border:1px solid [[ColorPalette::TertiaryPale]]; background-color:[[ColorPalette::TertiaryPale]];}
    .selected .tagging, .selected .tagged {background-color:[[ColorPalette::TertiaryLight]]; border:1px solid [[ColorPalette::TertiaryMid]];}
    .tagging .listTitle, .tagged .listTitle {color:[[ColorPalette::PrimaryDark]];}
    .tagging .button, .tagged .button {border:none;}

    .footer {color:[[ColorPalette::TertiaryLight]];}
    .selected .footer {color:[[ColorPalette::TertiaryMid]];}

    .sparkline {background:[[ColorPalette::PrimaryPale]]; border:0;}
    .sparktick {background:[[ColorPalette::PrimaryDark]];}

    .error, .errorButton {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::Error]];}
    .warning {color:[[ColorPalette::Foreground]]; background:[[ColorPalette::SecondaryPale]];}
    .lowlight {background:[[ColorPalette::TertiaryLight]];}

    .zoomer {background:none; color:[[ColorPalette::TertiaryMid]]; border:3px solid [[ColorPalette::TertiaryMid]];}

    .imageLink, #displayArea .imageLink {background:transparent;}

    .annotation {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; border:2px solid [[ColorPalette::SecondaryMid]];}

    .viewer .listTitle {list-style-type:none; margin-left:-2em;}
    .viewer .button {border:1px solid [[ColorPalette::SecondaryMid]];}
    .viewer blockquote {border-left:3px solid [[ColorPalette::TertiaryDark]];}

    .viewer table, table.twtable {border:2px solid [[ColorPalette::TertiaryDark]];}
    .viewer th, .viewer thead td, .twtable th, .twtable thead td {background:[[ColorPalette::SecondaryMid]]; border:1px solid [[ColorPalette::TertiaryDark]]; color:[[ColorPalette::Background]];}
    .viewer td, .viewer tr, .twtable td, .twtable tr {border:1px solid [[ColorPalette::TertiaryDark]];}

    .viewer pre {border:1px solid [[ColorPalette::SecondaryLight]]; background:[[ColorPalette::SecondaryPale]];}
    .viewer code {color:[[ColorPalette::SecondaryDark]];}
    .viewer hr {border:0; border-top:dashed 1px [[ColorPalette::TertiaryDark]]; color:[[ColorPalette::TertiaryDark]];}

    .highlight, .marked {background:[[ColorPalette::SecondaryLight]];}

    .editor input {border:1px solid [[ColorPalette::PrimaryMid]];}
    .editor textarea {border:1px solid [[ColorPalette::PrimaryMid]]; width:100%;}
    .editorFooter {color:[[ColorPalette::TertiaryMid]];}

    #backstageArea {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::TertiaryMid]];}
    #backstageArea a {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::Background]]; border:none;}
    #backstageArea a:hover {background:[[ColorPalette::SecondaryLight]]; color:[[ColorPalette::Foreground]]; }
    #backstageArea a.backstageSelTab {background:[[ColorPalette::Background]]; color:[[ColorPalette::Foreground]];}
    #backstageButton a {background:none; color:[[ColorPalette::Background]]; border:none;}
    #backstageButton a:hover {background:[[ColorPalette::Foreground]]; color:[[ColorPalette::Background]]; border:none;}
    #backstagePanel {background:[[ColorPalette::Background]]; border-color: [[ColorPalette::Background]] [[ColorPalette::TertiaryDark]] [[ColorPalette::TertiaryDark]] [[ColorPalette::TertiaryDark]];}
    .backstagePanelFooter .button {border:none; color:[[ColorPalette::Background]];}
    .backstagePanelFooter .button:hover {color:[[ColorPalette::Foreground]];}
    #backstageCloak {background:[[ColorPalette::Foreground]]; opacity:0.6; filter:'alpha(opacity:60)';}
    /*}}}*/

    /*{{{*/
    * html .tiddler {height:1%;}

    body {font-size:.75em; font-family:arial,helvetica; margin:0; padding:0;}

    h1,h2,h3,h4,h5,h6 {font-weight:bold; text-decoration:none;}
    h1,h2,h3 {padding-bottom:1px; margin-top:1.2em;margin-bottom:0.3em;}
    h4,h5,h6 {margin-top:1em;}
    h1 {font-size:1.35em;}
    h2 {font-size:1.25em;}
    h3 {font-size:1.1em;}
    h4 {font-size:1em;}
    h5 {font-size:.9em;}

    hr {height:1px;}

    a {text-decoration:none;}

    dt {font-weight:bold;}

    ol {list-style-type:decimal;}
    ol ol {list-style-type:lower-alpha;}
    ol ol ol {list-style-type:lower-roman;}
    ol ol ol ol {list-style-type:decimal;}
    ol ol ol ol ol {list-style-type:lower-alpha;}
    ol ol ol ol ol ol {list-style-type:lower-roman;}
    ol ol ol ol ol ol ol {list-style-type:decimal;}

    .txtOptionInput {width:11em;}

    #contentWrapper .chkOptionInput {border:0;}

    .externalLink {text-decoration:underline;}

    .indent {margin-left:3em;}
    .outdent {margin-left:3em; text-indent:-3em;}
    code.escaped {white-space:nowrap;}

    .tiddlyLinkExisting {font-weight:bold;}
    .tiddlyLinkNonExisting {font-style:italic;}

    /* the 'a' is required for IE, otherwise it renders the whole tiddler in bold */
    a.tiddlyLinkNonExisting.shadow {font-weight:bold;}

    #mainMenu .tiddlyLinkExisting,
    	#mainMenu .tiddlyLinkNonExisting,
    	#sidebarTabs .tiddlyLinkNonExisting {font-weight:normal; font-style:normal;}
    #sidebarTabs .tiddlyLinkExisting {font-weight:bold; font-style:normal;}

    .header {position:relative;}
    .header a:hover {background:transparent;}
    .headerShadow {position:relative; padding:4.5em 0em 1em 1em; left:-1px; top:-1px;}
    .headerForeground {position:absolute; padding:4.5em 0em 1em 1em; left:0px; top:0px;}

    .siteTitle {font-size:3em;}
    .siteSubtitle {font-size:1.2em;}

    #mainMenu {position:absolute; left:0; width:10em; text-align:right; line-height:1.6em; padding:1.5em 0.5em 0.5em 0.5em; font-size:1.1em;}

    #sidebar {position:absolute; right:3px; width:16em; font-size:.9em;}
    #sidebarOptions {padding-top:0.3em;}
    #sidebarOptions a {margin:0em 0.2em; padding:0.2em 0.3em; display:block;}
    #sidebarOptions input {margin:0.4em 0.5em;}
    #sidebarOptions .sliderPanel {margin-left:1em; padding:0.5em; font-size:.85em;}
    #sidebarOptions .sliderPanel a {font-weight:bold; display:inline; padding:0;}
    #sidebarOptions .sliderPanel input {margin:0 0 .3em 0;}
    #sidebarTabs .tabContents {width:15em; overflow:hidden;}

    .wizard {padding:0.1em 1em 0em 2em;}
    .wizard h1 {font-size:2em; font-weight:bold; background:none; padding:0em 0em 0em 0em; margin:0.4em 0em 0.2em 0em;}
    .wizard h2 {font-size:1.2em; font-weight:bold; background:none; padding:0em 0em 0em 0em; margin:0.4em 0em 0.2em 0em;}
    .wizardStep {padding:1em 1em 1em 1em;}
    .wizard .button {margin:0.5em 0em 0em 0em; font-size:1.2em;}
    .wizardFooter {padding:0.8em 0.4em 0.8em 0em;}
    .wizardFooter .status {padding:0em 0.4em 0em 0.4em; margin-left:1em;}
    .wizard .button {padding:0.1em 0.2em 0.1em 0.2em;}

    #messageArea {position:fixed; top:2em; right:0em; margin:0.5em; padding:0.5em; z-index:2000; _position:absolute;}
    .messageToolbar {display:block; text-align:right; padding:0.2em 0.2em 0.2em 0.2em;}
    #messageArea a {text-decoration:underline;}

    .tiddlerPopupButton {padding:0.2em 0.2em 0.2em 0.2em;}
    .popupTiddler {position: absolute; z-index:300; padding:1em 1em 1em 1em; margin:0;}

    .popup {position:absolute; z-index:300; font-size:.9em; padding:0; list-style:none; margin:0;}
    .popup .popupMessage {padding:0.4em;}
    .popup hr {display:block; height:1px; width:auto; padding:0; margin:0.2em 0em;}
    .popup li.disabled {padding:0.4em;}
    .popup li a {display:block; padding:0.4em; font-weight:normal; cursor:pointer;}
    .listBreak {font-size:1px; line-height:1px;}
    .listBreak div {margin:2px 0;}

    .tabset {padding:1em 0em 0em 0.5em;}
    .tab {margin:0em 0em 0em 0.25em; padding:2px;}
    .tabContents {padding:0.5em;}
    .tabContents ul, .tabContents ol {margin:0; padding:0;}
    .txtMainTab .tabContents li {list-style:none;}
    .tabContents li.listLink { margin-left:.75em;}

    #contentWrapper {display:block;}
    #splashScreen {display:none;}

    #displayArea {margin:1em 17em 0em 14em;}

    .toolbar {text-align:right; font-size:.9em;}

    .tiddler {padding:1em 1em 0em 1em;}

    .missing .viewer,.missing .title {font-style:italic;}

    .title {font-size:1.6em; font-weight:bold;}

    .missing .subtitle {display:none;}
    .subtitle {font-size:1.1em;}

    .tiddler .button {padding:0.2em 0.4em;}

    .tagging {margin:0.5em 0.5em 0.5em 0; float:left; display:none;}
    .isTag .tagging {display:block;}
    .tagged {margin:0.5em; float:right;}
    .tagging, .tagged {font-size:0.9em; padding:0.25em;}
    .tagging ul, .tagged ul {list-style:none; margin:0.25em; padding:0;}
    .tagClear {clear:both;}

    .footer {font-size:.9em;}
    .footer li {display:inline;}

    .annotation {padding:0.5em; margin:0.5em;}

    * html .viewer pre {width:99%; padding:0 0 1em 0;}
    .viewer {line-height:1.4em; padding-top:0.5em;}
    .viewer .button {margin:0em 0.25em; padding:0em 0.25em;}
    .viewer blockquote {line-height:1.5em; padding-left:0.8em;margin-left:2.5em;}
    .viewer ul, .viewer ol {margin-left:0.5em; padding-left:1.5em;}

    .viewer table, table.twtable {border-collapse:collapse; margin:0.8em 1.0em;}
    .viewer th, .viewer td, .viewer tr,.viewer caption,.twtable th, .twtable td, .twtable tr,.twtable caption {padding:3px;}
    table.listView {font-size:0.85em; margin:0.8em 1.0em;}
    table.listView th, table.listView td, table.listView tr {padding:0px 3px 0px 3px;}

    .viewer pre {padding:0.5em; margin-left:0.5em; font-size:1.2em; line-height:1.4em; overflow:auto;}
    .viewer code {font-size:1.2em; line-height:1.4em;}

    .editor {font-size:1.1em;}
    .editor input, .editor textarea {display:block; width:100%; font:inherit;}
    .editorFooter {padding:0.25em 0em; font-size:.9em;}
    .editorFooter .button {padding-top:0px; padding-bottom:0px;}

    .fieldsetFix {border:0; padding:0; margin:1px 0px 1px 0px;}

    .sparkline {line-height:1em;}
    .sparktick {outline:0;}

    .zoomer {font-size:1.1em; position:absolute; overflow:hidden;}
    .zoomer div {padding:1em;}

    * html #backstage {width:99%;}
    * html #backstageArea {width:99%;}
    #backstageArea {display:none; position:relative; overflow: hidden; z-index:150; padding:0.3em 0.5em 0.3em 0.5em;}
    #backstageToolbar {position:relative;}
    #backstageArea a {font-weight:bold; margin-left:0.5em; padding:0.3em 0.5em 0.3em 0.5em;}
    #backstageButton {display:none; position:absolute; z-index:175; top:0em; right:0em;}
    #backstageButton a {padding:0.1em 0.4em 0.1em 0.4em; margin:0.1em 0.1em 0.1em 0.1em;}
    #backstage {position:relative; width:100%; z-index:50;}
    #backstagePanel {display:none; z-index:100; position:absolute; margin:0em 3em 0em 3em; padding:1em 1em 1em 1em;}
    .backstagePanelFooter {padding-top:0.2em; float:right;}
    .backstagePanelFooter a {padding:0.2em 0.4em 0.2em 0.4em;}
    #backstageCloak {display:none; z-index:20; position:absolute; width:100%; height:100px;}

    .whenBackstage {display:none;}
    .backstageVisible .whenBackstage {display:block;}
    /*}}}*/

    /***
    StyleSheet for use when a translation requires any css style changes.
    This StyleSheet can be used directly by languages such as Chinese, Japanese and Korean which use a logographic writing system and need larger font sizes.
    ***/

    /*{{{*/
    body {font-size:0.8em;}

    #sidebarOptions {font-size:1.05em;}
    #sidebarOptions a {font-style:normal;}
    #sidebarOptions .sliderPanel {font-size:0.95em;}

    .subtitle {font-size:0.8em;}

    .viewer table.listView {font-size:0.95em;}

    .htmlarea .toolbarHA table {border:1px solid ButtonFace; margin:0em 0em;}
    /*}}}*/

    /*{{{*/
    @media print {
    #mainMenu, #sidebar, #messageArea, .toolbar, #backstageButton {display: none ! important;}
    #displayArea {margin: 1em 1em 0em 1em;}
    /* Fixes a feature in Firefox 1.5.0.2 where print preview displays the noscript content */
    noscript {display:none;}
    }
    /*}}}*/

    <!--{{{-->
    <div class='header' macro='gradient vert [[ColorPalette::PrimaryLight]] [[ColorPalette::PrimaryMid]]'>
    <div class='headerShadow'>
    <span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>&nbsp;
    <span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
    </div>
    <div class='headerForeground'>
    <span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>&nbsp;
    <span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
    </div>
    </div>
    <div id='mainMenu' refresh='content' tiddler='MainMenu'></div>
    <div id='sidebar'>
    <div id='sidebarOptions' refresh='content' tiddler='SideBarOptions'></div>
    <div id='sidebarTabs' refresh='content' force='true' tiddler='SideBarTabs'></div>
    </div>
    <div id='displayArea'>
    <div id='messageArea'></div>
    <div id='tiddlerDisplay'></div>
    </div>
    <!--}}}-->

    <!--{{{-->
    <div class='toolbar' macro='toolbar closeTiddler closeOthers +editTiddler > fields syncing permalink references jump'></div>
    <div class='title' macro='view title'></div>
    <div class='subtitle'><span macro='view modifier link'></span>, <span macro='view modified date'></span> (<span macro='message views.wikified.createdPrompt'></span> <span macro='view created date'></span>)</div>
    <div class='tagging' macro='tagging'></div>
    <div class='tagged' macro='tags'></div>
    <div class='viewer' macro='view text wikified'></div>
    <div class='tagClear'></div>
    <!--}}}-->

    <!--{{{-->
    <div class='toolbar' macro='toolbar +saveTiddler -cancelTiddler deleteTiddler'></div>
    <div class='title' macro='view title'></div>
    <div class='editor' macro='edit title'></div>
    <div macro='annotations'></div>
    <div class='editor' macro='edit text'></div>
    <div class='editor' macro='edit tags'></div><div class='editorFooter'><span macro='message views.editor.tagPrompt'></span><span macro='tagChooser'></span></div>
    <!--}}}-->

    To get started with this blank TiddlyWiki, you'll need to modify the following tiddlers:
    * SiteTitle & SiteSubtitle: The title and subtitle of the site, as shown above (after saving, they will also appear in the browser title bar)
    * MainMenu: The menu (usually on the left)
    * DefaultTiddlers: Contains the names of the tiddlers that you want to appear when the TiddlyWiki is opened
    You'll also need to enter your username for signing your edits: <<option txtUserName>>

    These InterfaceOptions for customising TiddlyWiki are saved in your browser

    Your username for signing your edits. Write it as a WikiWord (eg JoeBloggs)

    <<option txtUserName>>
    <<option chkSaveBackups>> SaveBackups
    <<option chkAutoSave>> AutoSave
    <<option chkRegExpSearch>> RegExpSearch
    <<option chkCaseSensitiveSearch>> CaseSensitiveSearch
    <<option chkAnimate>> EnableAnimations

    ----
    Also see AdvancedOptions

    A task has a description, an estimate of how long it will take, and a record of how much time you have spent on it so far.  Here's an example, which shows a task estimated at 3 hours, with 1 hour spent on it, and ''2'' hours remaining:
    <<<
    <<task 3 3 1>> Add a double-click handler to the description cell that opens the editor and selects the text
    <<<
    If you hover the mouse over any part of the task -- the bullet, the description, or any of the numeric cells -- a tip will appear explaining it.

    Try modifying the time spent.  Suppose you've just spent one more hour and want to record it.  Just click on the second yellow cell, and enter "+1" (sans the quote marks, of course) in the popup window.  Watch the time remaining go down to 1 hour.

    In reality, I originally estimated this task at a half-hour, but it ended up taking 3.5 hours.  The macro also tracks your original estimate, if it is different from the current estimate, in a fourth cell like this:
    <<<
    <<task 0.5 2 1>> Add a double-click handler to the description cell that opens the editor and selects the text
    <<<
    You can adjust the current estimate in the same way as you adjusted the time spent.  Click on the current estimate cell (the first yellow cell), and change it to 2.5 hours by typing "2.5" or "+.5".

    You can also adjust the time remaining, which will modify either the estimate (if the time remaining increases) or the time spent (if it decreases).  Click on the time remaining and add an hour by typing "+1".

    When the time remaining goes to zero, the task is considered complete:
    <<<
    <<task 0.5 3.5 3.5>> Add a double-click handler to the description cell that opens the editor and selects the text
    <<<
    If you haven't already done so, try double-clicking the description.  Yes, it really does open up the editor and select just the text of the description.

    ----
    To continue, click the down-arrow and choose another section: <<tag TaskMacroTutorial>>

    A task's description is a single wikified line, so it can contain any formatting that can be specified on one line:
    <<<
    <<task 1>> Beef up the time click handlers to allow entry of ''two'' values each: cur&spent, spent&rem. Add click handler to done tasks' spent cells too, to reopen them (like with +0, 1).
    <<task 0.5>> Put tasksum on the ViewTemplate.
    <<<
    You can specify just the description of a task, and leave it unestimated.  Click the question mark to enter the estimate:
    <<<
    <<task>> Beef up the time click handlers to allow entry of ''two'' values each: cur&spent, spent&rem. Add click handler to done tasks' spent cells too, to reopen them (like with +0, 1).
    <<<
    As this task implies, you can enter two values in the popup when you click on any of the time cells.  Separate them with spaces and/or a comma.  Experiment:
    <<<
    <<task 1>> Beef up the time click handlers to allow entry of ''two'' values each: cur&spent, spent&rem. Add click handler to done tasks' spent cells too, to reopen them (like with +0, 1).
    <<<
    Finally, if you haven't already figured this out, you can double-click on a task's bullet to mark it complete, with the current estimate entered as the time spent.

    ----
    To continue, click the down-arrow and choose another section: <<tag TaskMacroTutorial>>

    If you've been paying attention, you've noticed that I haven't discussed the actual adding of calls to the task macro within your tiddlers -- it's all been about modifying tasks that were already there.  That's because adding tasks via the taskadder macro is much easier and more intuitive than adding them by hand.

    And setting up a taskadder is simplicity itself.  Just add {{{<<taskadder>>}}} to your tiddler.  You will see this:
    <<<
    <<taskadder>>
    <<<
    Just type a task description into the first field, and your initial estimate for how long it will take into the second field.  Click the "add task" button, or just hit Enter in either of the fields, to add the new task into the tiddler.  Notice that you can just start typing a new task as soon as you're done entering the first one.

    You can have as many taskadders as you like in any tiddler.  The last one you used will capture the keyboard focus when it is redisplayed, meaning you can type a series of tasks without using the mouse.  Try adding some tasks here and in the above adder:
    <<<
    <<taskadder>>
    <<<
    Notice that the one you just used takes focus when this tiddler is redisplayed.

    A taskadder by default adds tasks above itself.  You can make it add them below by adding a {{{below}}} argument to the macro call:
    <<<
    <<taskadder below>>
    <<<

    ----
    To continue, click the down-arrow and choose another section: <<tag TaskMacroTutorial>>

    In this tutorial, we've been looking mostly at individual tasks.  In real life, though, you'll typically have a series of them, or even several series of them in the same tiddler.  In these cases you want a summary that tells you -- at a minimum -- how much time you still expect to spend on these tasks.

    To get such a summary, just add {{{<<tasksum start>>}}} before the tasks and {{{<<tasksum end>>}}} after them.  Here's an example:
    <<<
    <<tasksum start>>
    <<task 0.25 0.25 0.25>> Add tooltips to the various cells
    <<task 1 0.75 0.75>> Figure out how to add auto-updating click handlers to the time cells
    <<task 2 2 0>> Add simple click handlers to cur, spent, rem: just allow direct setting of values
    <<task 1 3.5 2.5>> Add a double-click handler to the desc cell that opens the editor and selects the text
    <<task 1 1 0>> Beef up the time click handlers to allow entry of two values each: cur&spent, spent&rem. Add click handler to done tasks' spent cells too, to reopen them (like with +0, 1).
    <<task 1 1 0>> Beef up the time click handlers to handle leading + or -
    <<task 1 1 0>> Add a double-click handler to the status cell that functions like typing 0 into the rem cell
    <<tasksum end>>
    <<<
    If you'd rather have the summary at the top, just add {{{here}}} to the start call, ie {{{<<tasksum start here>>}}}.
    <<<
    <<tasksum start here>>
    <<task 0.25 0.25 0.25>> Add tooltips to the various cells
    <<task 1 0.75 0.75>> Figure out how to add auto-updating click handlers to the time cells
    <<task 2 2 0>> Add simple click handlers to cur, spent, rem: just allow direct setting of values
    <<tasksum end>>
    <<<
    You can nest these things if you like, just be sure to match starts and ends:
    <<<
    <<tasksum start here>>
    * Time cell manipulation:<<tasksum start>>
    <<task 1 0.75 0.75>> Figure out how to add auto-updating click handlers to the time cells
    <<task 2 2 0>> Add simple click handlers to cur, spent, rem: just allow direct setting of values
    <<task 1 1 0>> Beef up the time click handlers to allow entry of two values each: cur&spent, spent&rem. Add click handler to done tasks' spent cells too, to reopen them (like with +0, 1).
    <<task 1 1 0>> Beef up the time click handlers to handle leading + or -
    <<tasksum end "Cell manipulation:">>
    <<br>>
    * Double-click handling:<<tasksum start>>
    <<task 1 3.5 2.5>> Add a double-click handler to the desc cell that opens the editor and selects the text
    <<task 1 1 0>> Add a double-click handler to the status cell that functions like typing 0 into the rem cell
    <<tasksum end "Double-clicks:">>

    <<tasksum end>>
    <<<
    Finally, the simplest way to use tasksum is to add it to your view template.  See TaskSummaryViewTemplate for an example template.  Note that if no tasks are present between the start and end, nothing is displayed.

    ----
    To continue, click the down-arrow and choose another section: <<tag TaskMacroTutorial>>

    The TaskMacroPlugin can be installed like any other TiddlyWiki plugin, and used without further effort.  However, there are two issues that may affect you.  (To get started with a brand new wiki that does not have these issues, consider downloading the [[empty LabWiki|empty_labwiki.html]].)
    # The task macros don't play nicely with the default TiddlyWiki display of tags.  In the default view template, a tiddler's list of tags is shown in a little box that floats in the upper right corner of the tiddler.  However, this little box may interfere with the tables used by the task macros.  In Firefox, the tables are drawn right over the top of the tag box, rendering both of them illegible.  In Internet Explorer, the tag box forces the tables to be pushed down below the box, which can waste a lot of space.<<br>><<br>>Thus, I recommend changing your view template to eliminate the little box.  If you use Simon Baird's [[TagglyTagging|http://simonbaird.com/mptw/#TagglyTagging]] (as LabWiki does), then my TaskSummaryViewTemplate might be a good alternative.  Simply import it into your wiki and rename it to ViewTemplate.  This template also demonstrates how to incorporate the tasksum macro into every tiddler so any tiddler with tasks has a summary at the top.<<br>><<br>>
    # Most view templates also add a minus sign ("-") before the "close" command.  TiddlyWiki interprets this to mean that you want the close command to be executed if you hit the Escape key from within the tiddler.<<br>><<br>>However, most tiddlers never have focus, and so never give you the opportunity to try it out.  But if you have a taskadder in your tiddler, then you suddenly enable this feature -- and you probably don't want it.  It means that if you type a nice long task description and then hit Escape, that description will be lost and the tiddler will be closed.  So I recommend that you remove the minus sign from the view template's menu altogether, as I have done in LabWiki's own ViewTemplate.

    ----
    This ends the tutorial.  To go back to any previous section, click the down-arrow and choose it: <<tag TaskMacroTutorial>>

    PageTemplate
    |>|SiteTitle - SiteSubtitle|
    |>|MainMenu|
    |DefaultTiddlers<<br>><<br>><<br>>ViewTemplate<<br>><<br>>EditTemplate|SideBarOptions|
    |~|OptionsPanel|
    |~|SideBarTabs|
    |~|AdvancedOptions|
    |~|<<tiddler Configuration.SideBarTabs>>|

    ''StyleSheet:'' StyleSheetColors - StyleSheetLayout - StyleSheetPrint

    ColorPalette

    SiteUrl

    This page intends to capture the lage picture regarding Lumiera's Architecture. This may be a moving target...

    [img[Overview of Lumiera Architecture|draw/Lumi.Architecture-1.png][http://www.lumiera.org/gitweb?p=LUMIERA;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD]]

    //this drawing is maintained as SVG in GIT//
    ~~(click on the above image...)~~

    !Description
    * the Application has three Layers: [[Backend|backend.html]], [[Proc-Layer|renderengine.html]] and GUI
    * the Application shall be completely functional without GUI ("headless", script-driven)
    * all IO, media data fetching, processing and bookkeeping falls within the realm of the Backend
    * all media object manipulation, deciding and configuration is the Proc Layer's job
    * extensible by plugins on all levels, highly configurable, but not totally componentized (micro kernel) architecture
    * strong separation between high-level and low-level areas of the Application
    * the user/GUI manipulates a [[high-level model|renderengine.html#HighLevelModel]] whereas rendering is based on a corresponding [[low-level model|renderengine.html#OverviewRenderEngine]]
    * stored Session (state) is comprised of high-level model, a collection of [[Assets|renderengine.html#Asset]] and accompaning configuration
    * (possibly) several storage backends, abstracted out by a common interface

    * autotools 1.10 (as of 5/2008) &dash; Question: other versions usable too?
    * the usual procedure, in short
    {{{
    autoreconf -i
    automake
    ./configure --enable-alpha
    make
    make check
    }}}

    /***
    |Name|BetterTimelineMacro|
    |Created by|SaqImtiaz|
    |Location|http://tw.lewcid.org/#BetterTimelineMacro|
    |Version|0.5 beta|
    |Requires|~TW2.x|
    !!!Description:
    A replacement for the core timeline macro that offers more features:
    *list tiddlers with only specfic tag
    *exclude tiddlers with a particular tag
    *limit entries to any number of days, for example one week
    *specify a start date for the timeline, only tiddlers after that date will be listed.

    !!!Installation:
    Copy the contents of this tiddler to your TW, tag with systemConfig, save and reload your TW.
    Edit the ViewTemplate to add the fullscreen command to the toolbar.

    !!!Syntax:
    {{{<<timeline better:true>>}}}
    ''the param better:true enables the advanced features, without it you will get the old timeline behaviour.''

    additonal params:
    (use only the ones you want)
    {{{<<timeline better:true  onlyTag:Tag1 excludeTag:Tag2 sortBy:modified/created firstDay:YYYYMMDD maxDays:7 maxEntries:30>>}}}

    ''explanation of syntax:''
    onlyTag: only tiddlers with this tag will be listed. Default is to list all tiddlers.
    excludeTag: tiddlers with this tag will not be listed.
    sortBy: sort tiddlers by date modified or date created. Possible values are modified or created.
    firstDay: useful for starting timeline from a specific date. Example: 20060701 for 1st of July, 2006
    maxDays: limits timeline to include only tiddlers from the specified number of days. If you use a value of 7 for example, only tiddlers from the last 7 days will be listed.
    maxEntries: limit the total number of entries in the timeline.

    !!!History:
    *28-07-06: ver 0.5 beta, first release

    !!!Code
    ***/
    //{{{
    // Return the tiddlers as a sorted array
    TiddlyWiki.prototype.getTiddlers = function(field,excludeTag,includeTag)
    {
              var results = [];
              this.forEachTiddler(function(title,tiddler)
              {
              if(excludeTag == undefined || tiddler.tags.find(excludeTag) == null)
                            if(includeTag == undefined || tiddler.tags.find(includeTag)!=null)
                                          results.push(tiddler);
              });
              if(field)
                       results.sort(function (a,b) {if(a[field] == b[field]) return(0); else return (a[field] < b[field]) ? -1 : +1; });
              return results;
    }

    //this function by Udo
    function getParam(params, name, defaultValue)
    {
              if (!params)
              return defaultValue;
              var p = params[0][name];
              return p ? p[0] : defaultValue;
    }

    window.old_timeline_handler= config.macros.timeline.handler;
    config.macros.timeline.handler = function(place,macroName,params,wikifier,paramString,tiddler)
    {
              var args = paramString.parseParams("list",null,true);
              var betterMode = getParam(args, "better", "false");
              if (betterMode == 'true')
              {
              var sortBy = getParam(args,"sortBy","modified");
              var excludeTag = getParam(args,"excludeTag",undefined);
              var includeTag = getParam(args,"onlyTag",undefined);
              var tiddlers = store.getTiddlers(sortBy,excludeTag,includeTag);
              var firstDayParam = getParam(args,"firstDay",undefined);
              var firstDay = (firstDayParam!=undefined)? firstDayParam: "00010101";
              var lastDay = "";
              var field= sortBy;
              var maxDaysParam = getParam(args,"maxDays",undefined);
              var maxDays = (maxDaysParam!=undefined)? maxDaysParam*24*60*60*1000: (new Date()).getTime() ;
              var maxEntries = getParam(args,"maxEntries",undefined);
              var last = (maxEntries!=undefined) ? tiddlers.length-Math.min(tiddlers.length,parseInt(maxEntries)) : 0;
              for(var t=tiddlers.length-1; t>=last; t--)
                      {
                      var tiddler = tiddlers[t];
                      var theDay = tiddler[field].convertToLocalYYYYMMDDHHMM().substr(0,8);
                      if ((theDay>=firstDay)&& (tiddler[field].getTime()> (new Date()).getTime() - maxDays))
                         {
                         if(theDay != lastDay)
                                   {
                                   var theDateList = document.createElement("ul");
                                   place.appendChild(theDateList);
                                   createTiddlyElement(theDateList,"li",null,"listTitle",tiddler[field].formatString(this.dateFormat));
                                   lastDay = theDay;
                                   }
                      var theDateListItem = createTiddlyElement(theDateList,"li",null,"listLink",null);
                      theDateListItem.appendChild(createTiddlyLink(place,tiddler.title,true));
                      }
                      }
              }

              else
                  {
                  window.old_timeline_handler.apply(this,arguments);
                  }
    }
    //}}}

    for __Building__
    * gcc (4.1), glibc6 (2.3), libstdc++6 (4.1)
    * [[build system|BuildSystem]] dependencies: SCons (0.96.90), Python (2.4), pkg-config
    * [[GAVL|http://gmerlin.sourceforge.net/gavl.html]] (1.0.0)
    * NoBug for Logging, Tracing, Asserting (can be obtained from [[Pipapo.org|http://www.pipapo.org/pipawiki/NoBug]])
    * ~NoBug needs [[valgrind|Valgrind]] (3.2), execinfo.h and libpthread (&rarr; glibc)
    * std::tr1 &mdash; esp. for the former BOOST::shared_ptr (which is now proposed standard)
    * BOOST ~~(listed below are the DEBIAN package names)~~
    ** libboost-dev (>=1.34.1-2)
    ** libboost-program-options-dev (>=1.34.1-2)
    ** libboost-program-options1.34.1 (>=1.34.1-2) ''NOTE: binary dependency''
    ** libboost-regex-dev (>=1.34.1-2)
    ** libboost-regex1.34.1 (>=1.34.1-2) ''binary..''
    * for the GUI: gtkmm-2.4 gdl-1.0 libglibmm-2.4 cairomm-1.0 xv
    ** libgtkmm-2.4-dev (>=2.8)
    ** libcairomm-1.0-dev (>=0.6.0)
    ** libgdl-1-dev (>=0.6.1)
    *** libbonoboui2-dev (>=2.14.0)
    ** libglibmm-2.4-dev (>=2.16), requiring glib2.0 (>=2.16)
    ** libxv-dev (>=1.0.2)
    //usually, newer versions are OK//

    boost 1.35 works too.

    for __Running__

    July 2007 we agreed to try out several Build Systems in real world usage, to get a better feel on the maintenance costs of each.
    * SCons
    * AutoTools

    !Used Functionality
    * (re)building with reliable dependency checks
    * environment checks ("configure")
    * executing self-test suite
    * provide central interface for setting switches and configuration options
    * installing of some or all created artifacts

    LumieraWiki
    ShortCuts

    * There is a [[Manifest]] explaining the vision of the Lumiera project
    * The foundation how we work together is defined in LumieraDesignProcess
    * There is a description how the git repository is set up in RepositorySetup
    * we decided to write code in GNU style, with no tabs (use spaces)

    /***
    |Name|FullScreenPlugin|
    |Created by|SaqImtiaz|
    |Location|http://tw.lewcid.org/#FullScreenPlugin|
    |Version|1.1|
    |Requires|~TW2.x|
    !Description:
    Toggle between viewing tiddlers fullscreen and normally. Very handy for when you need more viewing space.

    !Demo:
    Click the ↕ button in the toolbar for this tiddler. Click it again to turn off fullscreen.

    !Installation:
    Copy the contents of this tiddler to your TW, tag with systemConfig, save and reload your TW.
    Edit the ViewTemplate to add the fullscreen command to the toolbar.

    !History:
    *25-07-06: ver 1.1
    *20-07-06: ver 1.0

    !Code
    ***/
    //{{{
    var lewcidFullScreen = false;

    config.commands.fullscreen =
    {
                text:" ↕ ",
                tooltip:"Fullscreen mode"
    };

    config.commands.fullscreen.handler = function (event,src,title)
    {
                if (lewcidFullScreen == false)
                   {
                    lewcidFullScreen = true;
                    setStylesheet('#sidebar, .header, #mainMenu{display:none;} #displayArea{margin:0em 0 0 0 !important;}',"lewcidFullScreenStyle");
                   }
                else
                   {
                    lewcidFullScreen = false;
                    setStylesheet(' ',"lewcidFullScreenStyle");
                   }
    }

    config.macros.fullscreen={};
    config.macros.fullscreen.handler =  function(place,macroName,params,wikifier,paramString,tiddler)
    {
            var label = params[0]||" ↕ ";
            var tooltip = params[1]||"Fullscreen mode";
            createTiddlyButton(place,label,tooltip,config.commands.fullscreen.handler);
    }

    var lewcid_fullscreen_closeTiddler = Story.prototype.closeTiddler;
    Story.prototype.closeTiddler =function(title,animate,slowly)
    {
               lewcid_fullscreen_closeTiddler.apply(this,arguments);
               if (story.isEmpty() && lewcidFullScreen == true)
                  config.commands.fullscreen.handler();
    }

    Slider.prototype.lewcidStop = Slider.prototype.stop;
    Slider.prototype.stop = function()
    {
               this.lewcidStop();
               if (story.isEmpty() && lewcidFullScreen == true)
                  config.commands.fullscreen.handler();
    }
    //}}}

    to make the admin/git_hooks/post-commit working add following to your .gitconfig:
    {{{
    [alias]
            sign = tag -s -f -m 'automatic generated on last commit'
            publish = push --all public
    }}}

    these two commands are used by 'admin/git-hooks/post-commit'

    'git sign' creates a gpg-signed tag after each commit, named '$~BRANCH_signature' overriding an older tag of the same name. Thus the head revision is always gpg signed (it is not perfect, in some cases like some merges and other things the signature can become unsynced and needs to be fixed manually).

    'git publish' just sends the commit to some repository which has to be registered with 'git remote add public ...', in case you are working offline this will stuck and timeout, you may break it with ctrl-c, someone may fix it.

    some ''interesting Branches''

    |![[pipapo.org|PipapoOrg]]                |!''mirrored''              |!|!description                          |
    | ct#master                               | ichthyo#master            | |Lumiera main development line         |
    | ichthyo#scons                           |                           | |[[SCons]]-based build system, improvements|

    I use some GitAliases to make signing and publishing easier.

    the '.git' dir itself is not versioned/distributed since it usually contains site-specific things. Despite this we might want to distribute some maintenance scripts and hooks so I put the default hooks into admin/git_hooks/ and users can symlink from .git/hooks them when needed.

    For now I hope this approach suffices, maybe we need admin/git_hooks/$HOOKNAME.$USER at some point when it turns out that people want personal hooks.

    &rarr; see [[Interesting Branches|GitBranches]]

    This part should explain what you have to do in order to download the sources of Lumiera from pipapo.org. It treats as well how to deliver improvements to cin3 using git. Git is a tool similar to cvs or svn.

    The cin3 sources are stored in a git repository. Maybe you have never heard of git before, but i can allay your fears: using git isn't that complicated. To download cin3 the very first time you simply have to clone a git-repo from pipapo.org. To do so just type the following in a shell:
    !!!Code
    //{{{
    git clone git://git.pipapo.org/lumiera/ct YOURCOPY'sNAME
    //}}}

    This will create a directory named YOURCOPY'sNAME which contains the whole data of the lumiera/ct branch of Lumiera. After having downloaded a cin3-git-repository you can update it by simply typing:
    !!!Code
    //{{{
    cd /your/path/YOURCOPY'sNAME
    git pull
    //}}}

    If everything went well your copy is now up to date. Pulling is faster than cloning it again and causes less traffic at the server.

    !!!Tips:
    * NEVER delete a git repository without a permission of a pro.
    * Check the url.
    * Install git before calling git

    Now you could compile the source code or improve Lumiera or the documentation. After having done so (let's say you have written a patch) you can deliver your changes by:
    * at first setting your name and email
    * committing your changes
    * pushing your local git-repo to a public server

    !!!Code
    //{{{
    git config --global user.name "YOUR REALNAME"
    git config --global user.email ~YOUR-E@MAIL.ADRESS
    git commit -m 'YOUR DESCRIPTION' -- FILE/TO/COMMIT
    git push git://git.pipapo.org/lumiera/mob
    //}}}

    lumiera/mob is an anonymous account at pipapo.org where everyone can commit changes.

    We keep a protocol or short summary of each important discussion. The summaries of the monthly developer meetings are posted to the Mailinglist and can be found on pipapo.org too

    * [[10-08 developer meeting 10.Oct.2008|IRC_2008-10-10]]
    * [[07-08 developer meeting 6.Jul.2008|IRC_2008-07-06]]
    * [[06-08 developer meeting 5.Jun.2008|IRC_2008-06-05]]
    * [[05-08 developer meeting 8.May.2008|IRC_2008-05-08]]
    * [[04-08 developer meeting 3.Apr.2008|IRC_2008-04-03]]
    * [[03-08 developer meeting 6.Mar.2008|IRC_2008-03-06]]
    * [[1.official developer meeting 1.Feb.2008|IRC_2008-02-01]]
    * [[informal developer meeting 10.Aug.2007|IRC_2007-08-10]]

    !talks about specific topics
    * [[buffer allocation for render nodes (6/08)|IRC_log_BufferAllocation_2008-06]]

    !10/11 aug 2007
    * maybe let the render graph builder generate a meta language which then is ''jit compiled'' for each configuration
    * using smart pointers and factories for objects ''and avoid unprotected use of {{{new}}} and {{{delete}}}'', if this wont work because of cycles, we might investigate specialized garbage collectors for specific cases.
    * format for frames would be likely ffmpeg or such first, finally we see what suits best. We have to provide coverter nodes to convert frame formats for accessing different libraries anyway (ffmpeg, v4l, gstreamer, ...)
    * we need a pool of worker threads and associated ~APIs
    * accessing frames has a time (get until..), ''unique frame identifier'' (see below), policies (what to do when out of time, quality required,..) and hints (recursive dependency, must cache, playback speed and direction, ...)
    * for each sequence (configuration) each node has a number (monotonic incrementing), a generation counter (increment on each parameter change), a propagation sum (from parent nodes)
    * frames are identified by their time(frame number) and node number plus generation number and propagation sum. This allows easily to find out when a frame has to be rerendered
    * no difference between compositor and viewer
    ** viewer is just a decoder where a display window attaches
    ** one can have multiple of such display windows
    ** tracks, effects, (things which are nodes in the render graph) can add gui components to the viewer, like masking tools, panning, overlay and other compositor things.
    ** in the render graph we have ''attachment points'' i.e. ~ExitNode-instances. Display and other output can only be pulled from such ~ExitNodes. Changing just the display or attaching it to another ~ExitNode doesn't count as change of the render graph, while reordering or reconfiguring the ~ExitNodes themselves of course //is// a reconfiguration.
    * tracks are just containers for other nodes
    ** they serve a GUI representation (timeline, patchbay, viewer)
    ** they do the mixing of contained things
    ** can be recursive, the GUI represents basically a tree
    ** we need some 'wiring' abstraction for the GUI to make it a real graph
    * rendering frames, context between frames
    ** the proc layer ''only queries frames'' (by identifier and timeout) the backend tries to serve the best it can do (from cache or let them render)
    ** each render job carries some ''quality limit'' (as S/N ratio) when previewing or scratching through the project this is used to generate reasonable quality previews
    ** individual processing nodes can use additional state for their calculations...
    *** the node objects themselves should stay stateless, i.e. they shouldn't store state internally.
    *** they can use special ''context frames'', which are provided and managed by the backend (as opaque data blocks).
    *** they can depend on previous state, i.e request from the backend a previous context frame, the same way as they can request previous media frames from the bakend, but there is no guarantee that the backend will satisfy this request.
    * on the question who decides what to do after a cache miss, we tend to put the decision into the render node (because this seems to be the simpler approach), but still have to work out the details.

    ! 1. feb.2008 on #openvideo
    21:00 -23:30 GMT. __Participants__:
    * hermanr
    * cehteh
    * ichthyo
    * Dasypus
    * gmerlin
    * ~SimAV
    * pippin
    * Plough
    * Plouj
    * Velmont

    !! Discuss the open points in http://www.pipapo.org/pipawiki/Lumiera/DesignProcess &mdash; do we need this formalism?
    At start of the project last summer, Cehteh made a [[design process proposal|http://www.pipapo.org/pipawiki/Lumiera/DesignProcess]]. We will keeping this up, not for every implementation detail, but for major plans, wishes and design decisions. One point in the agenda of future meetings will be to work through proposals in the queue
    * proposals in the "idea" state are not complete, can be just brainstorming or need further discussion. Comments please to the proposal page.
    * proposals in the "draft" state are ready for conclusive discussion and will be treated in one of the next meetings
    * "final" proposals are either "accepted" or "dropped". We don't differentiate the latter, but should write a short note why it was dropped.
    * if there is need for more or finer grained categories, we'll extend the page and the template as needed or provide different views

    !! The development model
    We employ a distributed model based on GIT. We want this repository to be as complete as possible, including documentation in embedded ~TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a "Mob GIT", i.e. anonymously pushable git (which is untrusted of course). Cehteh is currently working on a git web frontend which makes the codebase in the mob-repo web-editable like a wiki.
    Will we need a stable version or an official branch?  not yet &mdash; as long as the team is small it will work more painless without. At some point, when the project is more mature, we will define an official branch. Later on we will have automated builds and regression test runs. As we do test-driven development anyways, it's just a question of someone setting up all the infrastructure, then we'll do it.
    Ichthyo proposes a new requirement: All devs should ensure the "master" branch of their respective repositories always passes the compiler and the test suite. ~Work-In-Progress should be done on branches. Rationale: it is sufficient to pull from the master branches, and you can be sure the version you pulled worked for the originator.
    A note on dependencies: it will be hard to target minimal dependencies for such a project, but we shall try not to bloat it unnecessarily. Sometimes it can be sensible to rather re-invent a feature &mdash; esp. when it fits into the core focus of the project &mdash; instead of depending on difficult to build and not sufficiently maintained external projects. But we should avoid reinventing things like GUI toolkits.
    And, pretty much obvious, we try to stick to modern programming standards. Read: modules have interfaces, interfaces need some (minimal) documentation, and it is not allowed to bypass the interfaces and tangle everything in a wild fashion.
    Currently, the project can be separated into three layers, which could evolve into sub-projects: Backend, ~Proc-Layer, GUI. For each part, the dev most deeply involved and most knowledgeable will take on the sometimes necessary leadership and have the last word in case of quarrels. Currently, Cehteh cares for the Backend and Ichthyo headed for the ~Proc-Layer. We have postponed any work on the GUI for now and don't participate in GUI toolkit discussions. If there is a dev willing to care for the GUI, collect proposals, care for usability and the users needs and finally code it up, then he will the one to decide what toolkit to use.
    We plan to make the discussion about GPL v3 a point on the agenda of the next meeting.

    !! Monthly meetings
    * make it thursday, not friday
    * time for now 21:00 GMT &mdash; if some (potential) participants have problems with this time, please speak up (maybe alternating times?)
    * write a short status report for each mayor part //prior// to the meeting (saves us time). Maybe add an TODO list there
    * go through the open issues for the design process drafts
    * publish a protocol of each meeting on the (~Cinelerra-CV, ~LibOpenvideo) Mailinglists, in the TiddlyWiki and on pipapo.org
    * News, Protocols and the agenda of the next meeting can be found at the [[pipawiki-page|http://www.pipapo.org/pipawiki/Lumiera/MonthlyMeetings]]
    * next meeting on first Thursday in March (6.3.2008)

    !! Who works on what, what are the short term goals, what tasks are open?
    ''Ichthyo'' works on the processing layer. Current goal is to get the core of the builder fleshed out. Next goal is to create a clip object (dummy), add it to the EDL, hand the EDL over to the builder and let the builder make the first (preliminary) render nodes. (note: left many details for later).
    Ichthyo started coding his design draft and things seem to work out as intended. Some Keywords: Have a high-level model and a low level model. The former is comprised of the objects in the Session edited by the user, the latter is a network of completely configured render nodes, employing the same pull model as in Cinelerra-2. In between sits the Builder, translating high-level into low-level. This translation is done on demand (not for every frame).
    Current state in this part is: basic asset manager is done, asset objects (forming a hierarchy) can be created and will be registered automatically, it is possible to create a clip-"~MediaObject" from a media asset (without caring for any details regarding multichannel clips). Some support lib components are written, Session and data holders start up on demand and shutdown cleanly. The test suite is the only interesting executable, and this will remain so for quite some time. Currently writing the first parts of the Builder.
    Further plans/ideas: Ichthyo is rather determined to embed a Prolog interpreter (YAP Prolog) to handle all sorts of configuration queries in a rule-driven fashion. Things Ichthyo can't do in the near future: caring for session loading/saving serialisation plus storage backends, caring for a DB based implementation of the asset manager and integration with production support software, target the scheduler which will receive any edit operations initiated from the GUI.

    ''Cehteh'' is currently working on webgit, which is somewhat related inasmuch it will make small contributions to the mob repository much simpler. Previously he started with some foundation and support facilities. He plans to come back to the Backend implementation in about two weeks. The Backend is intended to handle all media (and even meta-)data as generalized frames. The render nodes network created by the ~Proc-Layer is completely stateless and all data is served from below. While it will be possible to address and access individual data within a frame (e.g. audio samples), frames are the smallest unit for memory and cache management. No plans to use a tiled memory model or to support frames larger than aprox. 20-40% of the available RAM.
    Cehteh's design plan includes a scheduler to organize the access to the raw data, monitor the timings and prefetch data as needed. This scheduler will be configurable via quality preferences ("need realtime", "need perfect quality"). Further, there will be an elaborate caching scheme trying hard to avoid re-rendering any frames already calculated previously. Temporary data will be backed by files and thus swapped out &mdash; this swapout and size of temporary data is to be monitored and adjusted according to the current load &mdash; and all temporary data is kept as most-recent-used cache discipline. Incoming and outgoing footage shall mostly be handled by using mmaped buffers. The rationale is to avoid unnecessary copy from kernel to user space and wasting memory for an additional in-kernel buffer. Writing via a mmapped buffer is little more tricky; there will be a in-place writing which is used for indices and other precalculated data which needs updates, and the processing layer can query write buffers which are actually a small cache/ring and then comited to the file. Basically, mmapping is a clean solution if you can design for it, and it's portable (posix)
    Things to do: object serialisation backend is sometime on Cehteh's schedule, but that's ahead and if someone else helps or takes over it would be OK. Even more true for a DB based backend for the asset manager.

    ''Gmerlin'' plans to implement grayscale support for GAVL, so the upper layers can store arbitrary data in it.

    __about multithreading__: since the render nodes are stateless they can be driven in multiple threads (but inter frame dependencies need to be resolved/serialized). Mostly the backend manages threads and does that quite conservatively (compared to Cinelerra-2 which massively creates separate threads for small tasks). Any edit operations initiated from GUI go to a scheduler in the middle layer, which enqueues and effectively serializes operations done to the "media objects" in the high-level model. The editing operations themselves are //not threadsafe // by design, they rely on being scheduled correctly. The builder is triggered from this ~Proc-Layer scheduler and starts in one separate thread, and when done, we swap whole parts of the render nodes network and then the backend can re(start) rendering as needed.

    !!The naming discussion
    The discussion looks healthy so far... People can add new proposals on the [[pipawiki|http://www.pipapo.org/pipawiki/Lumiera/Names]]. intersting names are still coming in, so we should just let the name-choosing game go on for a while. And, btw, we //can// depart from beeing similar to "Cinelerra" ;-)
    Let's say, we need a person volonteering to guide/moderate the selection, going over the list and scratching inammprobiate ones. Criteria for good names being:
    * should not be an existing project
    * should be "googleable"
    * should not be offensive
    * should have one of the free top level domains (.net, .org)
    * should be compatible with educational institutions (sorry, no pr0nedit :)
    * should not obviously collide with trade marks

    ! 6. mar.2008 on #openvideo
    21:00 - 23:30 GMT, __Participants__:
    * hermanr
    * cehteh
    * ichthyo
    * Plouj
    * SimAV
    * akirad
    * _MMA_
    * rgareus
    * ddennedy
    * edrz
    * anewcomb
    * gmerlin
    * oracle2025
    * gisle

    ! Boilerplate
    !! Organization of this meeting
    * cehteh writes the protocol
    * hermanr does chairman

    !! Leftovers from last meeting
    We concluded there are no leftovers

    ! Go through Ideas and Drafts in design process

    !! Idea: time_handling
    http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/time_handling

    Point 1 is superseded by using gavl.

    Points 2 and 3 are still valid.

    ''Ichthyo'' asked gmerlin if there are any problems according gavl for the points 2 (position of frames) and 3 (position for keyframes and automation). Gmerlin acknowledges that he doesnt see any problems.

    ''Oracle2025'' brings interlacing on topic "are you aware that automations and keyframes could/should also apply to fields?". We agree that this must be handled "in interlacing, a frame is a pair of 2 subsequent fields".

    __Conclusion__:
     Refactor the proposal according to the discussion and work it out, make it draft then. Discuss about it on the next meeting

    !! Idea: Unit tests in Python
    http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/UnitTests_Python

    We have a testsuite based on cehtehs 'test.sh' which superseedes this proposal.

    __Conclusion__:
     Drop it.

    !! Idea: Todo Lists
    http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/TodoLists

    This Idea is in a very early state an not yet mature.<br/>
    ''Cehteh'' explains: "I want something which doesn't need much human care and i want one big 'milestones' thing and a small 'mini-task' thing". Ichthyo refines this as "Roadmap" and "Near time task list". We agree that this shall not be too strict. There are some ideas floating, like adding this things to the testsuite or use the wiki. Ichthyo shows how he uses the tiddlywiki's task macro ([[renderengine.html#PlanningNodeCreatorTool]]). He likes it but doubts its usefulness when it is used without guessing the hours/days of work.

    __Conclusion__:
     We use the Tiddlywiki task macro thing for now.

    !! Draft: CCodingStyleGuide
    http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/CCodingStyleGuide

    Ichthyo tells that the discussion on the wiki page made this clear now. Cehteh explains that he uses this style with success for diffrent projects. We make clear that this is meant for C, in C++ we use namespaces. Overall we agree that code shall be self-documenting.

    __Conclusion__:
     Make it final.

    !! Draft: DevelopmentFramework
    http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DevelopmentFramework

    Cehteh explains that he will transfer this propoal to a tiddlywiki covering compatibility guides and dependencies. We conclude that this wiki must reflect the actual practice (NoBug, Doxygen, test.sh) despite the proposal is not concrete yet.

    A short discussion about build systems came up, we still use autotools and scons in parallel, delaying the decision later. oracle2025 mentioned that scons could be used for development and autotools for release. No decision about that everyone has different opinions. But we agree that it works as is.

    __Conclusion__:
     Cehteh will make the proposed wiki which shall be maintained to reflect the state and this topic will be finalized by that.

    !! Draft: Skills Collection
    http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/SkillsCollection

    This might be only useful if there are more developers working on the project.

    __Conclusion__:
     Leave in draft state for now.

    !! Draft: Architecture Overview
    http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview

    Ichthyo drawn a diagram showing the planned architecture. Cehteh raises concerns about codecs/plugins/effects in backend. After that there was some discussion about details. Cehteh suggests to place plugins in a extra box, gmerlin suggests that 'plugins' don't fit into the diagram, there should be "filters", "sources",..; Followed by some more discussion, showing that we basically agree and understand the design but the drawing needs some refinements.

    __Conclusion__:
     Good idea, needs some refinements, work in progress.

    ! Call for Design

    Ichthyo explains that he wants the overall design a bit more formalized. He put this topic on the agenda to remind that we have to work it out in DesignProcess and already started to make some design proposals.

    __Conclusion__:
     Things need to be worked out in DesignProcess, take a look and review it.

    ! Naming

    Raffa, Velmont, goibhniu and others collected and managed proposed names past weeks which finally ended in a community voting. Results are at http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_9fad0d1d10c23d38
    ''Lumiera'' won, Lumiera.org is free and no one of in this meeting has objections against this name. Velmont offers to register and pay for the lumiera.org domain which will be hosted on our own server (see topic below). Hermanr raises concerns if it is ok when the name is registered on another site and by another person than the server, cehteh explains that he like this distribution where doable and no one other objects. Ichthyo asks about a short name for Lumiera which will be used for C++ namespaces and such kinds. After a short discussion we agree that we use the full name and no abbreviation. We now have to rename the source and the wiki. Anyone renames the sourcecode where he is responsible for. Cehteh will go over the pipapo.org wiki and rename things.

    Finally we express our great thanks to the people who put the efforts into the name selection, thanks raffa, Velmont, goibhniu & co.

    __Conclusion__:
     ''Projectname is Lumiera'', we have a lot things to rename.

    ! Project Server, setup, organization, administration
    Some people gathered together and rented a server at 'hetzner.de' which will host some free project pages and personal sites. Cehteh is the one who signed for the server and officially respobsible for it.

    The server is split into isolated 'vservers' which are created as needed. Idea is to work cooperatively to get the best out of its resources.

    For our projects (cinelerra.org and lumiera.org) we now need volunteers who help setting it up and administrating things. Velmont offered to help with lumiera.org, hermanr takes care of cinelerra.org, raffa will help with maintaining the webpages. oracle2025 will care for developer chroots, build and test environments. cehteh will make a page on pipapo.org which reflects the current server setup http://www.pipapo.org/pipawiki/RootServerSetup . There are still a lot jobs to do!

    Cehteh asked about how to manage emergency root access on the host/root server when he is unreachable. There where several suggestions between one root key for all who pay for the server to shared key schemes. We finally agreed that anyone who payed for the server can send a ssh key to ssh to be registered for emergency access.

    The concrete server setup will be worked out next days. Ideas are one frontend proxy and a shared nameserver. A shared nameserver, A developer vserver shared between all developers. Maybe a shared mail server.

    Hermanr asked about how to handle distribution of large media files. There was some discussion about bittorrent vs http. We concluded to work that out as needed.

    In the forthcoming discussion about cehteh stresses that "it is a public server, if you place confidential information unencrypted on it, its you fault". Ssh keys shall be kept secret by the users but we can't enforce policies on those.

    Ichthyo asks about how to setup lumiera.org (wiki?), oracle2025 suggests webgit, cehteh explains that webgit isn't ready yet but should be useable in a few days (pipapo.org will use that too). Velmont suggest a 'real' website for the time when non-developers want to use it. Git will be set up on lumiera.org the same way as it is currently set up on pipapo.org.

    Hermanr asked Velmont about some help moving the bugs.cinelerra.org over, this might be little challenging since it needs an MTA and other things.

    Ichthyo asks about keeping the Lumiera project pages on pipapo.org until the server is ready, this is ok.

    __Conclusions__:
     We have our own server which now needs volunteers for maintenance. The projects will slowly move there, until ready Lumiera stays on pipapo.org.

    ! GPL3 pros cons, license rationale

    Ichthyo and cehteh would like to investigate a license change to GPLv3, neither of us has experience with problems this
    might raise. Questions are if we lock us out from potential libraries which are GPLv2 only or lock out possible contributors because of unforeseen patent clauses. The others here thinking that "GPLv2 or later" would be most-compatible. Gmerlin tells that he uses some "GPLv2 only" mplayer code in gavl which is itself "GPLv2 or later". Cehteh explains that "GPLv2 only" code is a problem, where "GPLv2 or later" is not. Ichthyo raises concerns that the Support library may need to be LGPL, cehteh mentions that it would likely be enough if we only apply that to the plugin-loader. After all it turns out that there is a lot of confusion, misunderstanding and interpretation used with licenses and no one of us knows for sure. Finally we conclude that the interpretation and license enforcement is ruled by the copyright owner.

    __Conclusion__:
     Learn more about GPLv3, use GPLv2 or later and propose to switch to GPLv3 when we are ready to do public beta releases when possible.

    ! Next meeting

    The next meeting will be at thuesday 3rd april 21:00GMT (if not rescheduled see below).

    Ichthyo tells that Martin Ellison wrote he couldn't attend because of the time. So again we made a short discussion about changing/alternating timings to allow people in downunder/japan to attend. They have to speak up an make time suggestions.

    Conclusion:
     Next meeting 3rd april 21:00GMT. But Aussies, please speak up if you want the time changed!

    ! 3. apr.2008 on #lumiera
    21:00 - 23:30 GMT. __Participants__:
     * cehteh
     * gmerlin
     * hermanr
     * ichthyo
     * joelholdsworth
     * johncoswell
     * rgareus
     * sakalli

    ! Boilerplate
    !! Organization of this meeting
     * sakalli writes the protocol, ichthyo will help reviewing it

    !! Recurring Topics
    We concluded there are no leftovers and currently no Drafts from the design process to discuss

    ! Call for volunteers
    (which tasks are to do, how can we interest people...?)

    There was a sense that there are people willing to help but they might need direction or cannot do actual coding. But there is also a lot of tasks that could be done by beginners and non-programmers. These tasks are important and if someone who is not a programmer is willing to take them on that leaves more time for the programmers. Examples of such tasks:
    * Protocol writing
    * maintaining to do lists and isolating tasks
    * constant code and documentation review
    * unit/functional testing
    * header file "task force" - some fundamentals discussed by the developers on libopenvideo should find their way into basic .h files
    * installing and maintaining project tracking and automated builds/tests on the server

    See http://www.lumiera.org/wiki/todo.html#Tasks

    It was also noted that at current phase some basic development is still needed before we can accommodate a large number of coders doing small tasks and for now we need some subsystem owners. For GUI for example.

    To make it easier for "beginners" to get aquainted with the program it was decided that one ''official Lumiera GIT repository'' should be established.

    ! Project announcements/registration
    (freshmeat, gnu, etc...) any takers?

    The discussion was about advertising the project on various sites. There were some concerns raised that it is too early to do too much publicity at the moment. That the right time should be shortly before the first public release. But there is also some value in registering to the project in planning/alpha stage to interest people such as prospective coders. It was noted that the [http://www.linux.com/feature/126441 article on linux.com] resulted in a lot of people contacting ichthyo and cehteh. [http://plot.bek.no/pipermail/piksel/2008-January/003328.html "I believe in Cinelerra"] by Leo Germani also generated a lot of traffic by developers. Some level of presence on mailing lists would be good although not too much just enough to indicate the project is going on.

    __Conclusion__: volunteer needed to coordinate publicity (not overly urgent, but helpful)

    ! Informal talk about the GUI

    Firstly, as SimAV was not able to be present during the meeting a proposal by him was relayed by Ichthyo: GUI and backend should be completely separated and communicate via pipes. It was agreed that the GUI should be detached but some higher level message protocol rather than bare pipes should be used. Some comments:
    * cehteh standalone gui is a nice to have, but implementation details have to be worked out
    * gmerlin Video playback can be separated in a separate X connection
    * cehteh suggests to start with an conventional, attached gui and just keep it in mind to make it detachable later
    * rgareus IMHO you want to share memory for the video-frame buffer beween the player and backend - with pipes you'll go the video-jack way.

    ''joelholdsworth'' is a new developer in the group and had showed interest in developing the GUI. he stated that he is interested in seeing a GUI that uses popular toolkits and that plays by the standards to create a consistent UI with the rest of the free desktop. For this reason he was advocating using  GTKmm. There was no direct objections to GTKmm. Generally, there seems some preference for GTK. (Note this doesn't mean GNOME). Cehteh advocates the idea to use Lua-gtk, i.e. writing the GUI in a clean and lightweight scripting language.

    Cario was suggested to be used for implementing the canvas in the timeline view.

    The gui should provide a skeleton. Timeline and canvas should be controllable and extensible by plugins. Tracks can be nested. Use tiling windows and dockeable views and tools palettes. For example some configuration within session/renderpipeline may cause some pluggable elements to be added to the gui. A fader or a toggle/icon and so forth. Some plugins might render additional output (e.g. in previews). A video track renders thumbnails, automation curves on top.

    Workflow is another important aspect to take into account in the design. A lot of information needs to come from editors and users in the design process. Different thoughts about the workflow:
    * Should not make a predefined workflow. Just produce a tool that can be adapted to different workflows. It can be predefined, but should not be fixed.
    * We dont have the resources to develop a "workflow" in the formal manner, we will go the "propose and comment" route.
    * We should take the best ideas from popular competing products such as Final Cut Pro, AVID, Premiere plus After Effects.

    Customisation is deemed important. Some points brought up in the discussion:
    * sakalli: would be great if we could provide a fcp configuration and a avid configuration besides the default configuration as well. That could lure a lot of users quickly. On the other side, too much flexibility can be be a problem as well.
    * cehteh: yes .. but such things are prolly costly to setup .. we need volunteers for anything optional
    * Customization should be possible without recompile, but not too cheap.
    * There should be a working skeleton or some fixed anchor but gui operations should be bound to a scripting language to achieve customization.
    * The whole gui in a script with some performance critical widgets coded in C/C++
    * Some parts should just be customizable, other parts should be kept fixed.
    * cehteh suggested to start out by making a 'high level' description with no language/toolkit in mind .. what widgets do we need etc and after that to work on the skeleton mockup.
    * cehteh / hermanr: Lumiera should allow to choose theme independently from desktop .. because what you have as your desktop-theme doesn't suit for video editing in many cases ... see ardour

    ichthyo brings up the role of customization for the middle layer and gives an overview of his plans for the new participants. :
    He had good experiences with a rule based aproach in various projects. He wants to embed a Prolog interpreter that can answer to "configuration queries".  There is a "builder" component in the middle layer to derive the render nodes graph based on a "high level model", which is visible to the user (in the GUI) and based on these configuration queries.

    Rationale for using prolog is: The rules are very readable because they rather represent facts and relations, not the way "how dings are done" but the way "how things are related". Example: how to configure some effects when the footage is interlaced. Additionally, we want to have some global swithces, which could control these rules, like "I want maximum quality", or "I want as much as possible set up automatically". The prolog rules are stored in the session and can be editd by advanced users. Of course, there is a set of basic rules. This aspect of customisation isn't exactly a GUI issue but it would have consequences for the GUI.

    some discussion:
    * joelholdsworth: so we just need a way of exposing properties. This is reasonably straightforward when all you want is value, colour, string etc.
    * rules within the middle layer/session could bind to some properties exposed in the GUI
    * gmerlin joelholdsworth: Agree, but point out that this can become difficult
    * cehteh joelholdsworth: skeleton and plugins who attach into some gui areas, so you can add custom widgets
    * ichthyo: also the ability to attach "tags" to various objects, so the rules can bind on those tags
    * cehteh: maybe a standard set of widgets, not really completely custom ones (gmerlin agrees)
    * joelholdsworth: probably you need to be able to do both well
    * joelholdsworth in many apps the value/colour/string set works perfectly well, but in luminierra the controls will likely need to be much richer

    Some brainstorming points about usability:
    * We need a realy good bezier widget for all sorts of curves.
    * Faders that can be grabbed everywhere are nice like  like ardours and Blender faders. Or others which have no big knob
    * The controls in blender's node view would be a good modal to copy (not advocating GL UI, just using widgets and concepts).

    One extra point:
    * we have agreed to make all of the big interfaces between the layers as plain C interfaces, because this is the most widely supported common denominator.

    !!!! GUI CONCLUSION
    * ''joelholdsworth'' is now the official GUI maintainer for Lumiera!
    * sakalli, hermanr, ichthyo announced interest in contributing to discussions about GUI, workflows and usability. gmerlin noted that he knows some gtk secrets and is willing to help out here too.

    ! Froscon application
    [http://www.froscon.org/ Froscon] is a small nice german open source exhibition that is very very technical oriented. Cehteh will be there as well as Ichthyo. Question is wether we should have a booth, perhaps together with some other interested media projects. Could ask Richard and the ffmpeg/mplayer people. End of call for papers is in june.

    We made no decision about official presence but most likely there will be a developer meeting if nothing else.

    ! Timecode metadata discussion
    This Discussion started out on the libopenvideo list: The question was wether we agree on one uniform format solution from decoder up to app level regarding timecode. And what this format would be: arithmetic or struct type. Regarding metadata (including type of timecode) the question is if we should work out a rather fixed data format, or go the route towards rather open description records.

    __Conclusion__: Gmerlin does it the way it fits best for within the decoder, and Lumiera uses a more uniform time format for representing timecode in the higher app layers. Conversion functions will be concentrated in a library. Regarding metadata we will investigate further.

    //A (shortended) digest of the timecode and metadata discussion is attached below//

    ! Next meeting

    The next meeting will be at thursday 8th may 21:00GMT

    -----------------------------

    !!!! Timecode discussion
    {{{
    12:51 cehteh gmerlin: did you read my last mail about generalization of metadata?
    12:51 cehteh key/value pairs
    12:51 gmerlin not sure about that
    12:51 cehteh i am pretty sure that i want that in lumiera
    12:52 cehteh if gavl does that for us it would be even better
    12:52 gmerlin first of all 2 different things:
    12:52 gmerlin 1. arithmetic <-> struct
    12:53 gmerlin 2. Generic <-> format specific
    12:53 cehteh arithmetic for sure
    12:53 gmerlin On the decoder API side, I want to export ideally only one type
    12:54 gmerlin No no SMPTEXXX and ISO999908098
    12:54 cehteh will that be attached to the frames in a intrusive way?
    12:54 cehteh i rather leave the attaching up to the application
    12:54 gmerlin intrusive?
    12:55 cehteh struct frame { uint64_t timecode; }   vs...
    12:55 cehteh struct frame { struct metadata* something; }
    12:55 cehteh or even vs something done at a api level
    12:56 gmerlin struct lumiera_video_frame { gavl_video_frame_t * f; uint64_t timecode};
    12:56 gmerlin Or add timecodes to gavl_video_frame_t
    12:57 cehteh struct lumiera_video_frame { gavl_video_frame_t * f; struct metadata* timecode_n_stuff; }
    12:57 ichthyo so I support a  struct metadata*
    12:58 cehteh ichthyo: timecodes might not be regular .. they should be optional, but anyways they dont cost when using an arithmetic type
    12:58 cehteh i mean thats the purpose of timecodes .. to tag every frame and dont make assumptions that your footage is perfect
    12:58 ichthyo but a struct metadata* would rather mean to keep it out of basic GAVL and have a libmetadata -- which may be integrated with GAVL -- right?
    12:59 cehteh someome may have stolen a frame :P
    12:59 cehteh thats gmerlins decision ...
    12:59 gmerlin I'm against gavl integration of metadata
    12:59 gmerlin gavl has a clear scope: Number crunching
    01:00 cehteh gmerlin: you somehow have to pass it from the decoder to the application
    01:01 cehteh i would prefer to introduce some sidechannel
    01:01 gmerlin Yes, gmerlin_avdecoder will provide a separate function for getting the next timecode
    01:01 gmerlin bgav_get_next_timecode()
    01:01 cehteh gavl_get_frame (gavl_frame* place the frame here, metadata* place metadata there)
    01:01 gmerlin or: bgav_timecode_from_pts()
    01:03 gmerlin Some higher MXF profiles allow changing timecode parameneters in one stream
    01:06 gmerlin It's sometimes impossible to separate demuxers and codecs
    01:06 gmerlin better have them together in one lib
    01:06 cehteh actually i would like to cache gavls internal states into the backend
    01:08 gmerlin Ok, so timecodes are YYYYMMDDHHMMSSFF as int64_t
    01:08 cehteh the indexing is something i prolly have some words about
    01:09 cehteh timecodes are uint64_t as microseconds
    01:09 cehteh well for lumiera :-P
    01:10 cehteh YYYYMMDDHHMMSSFF as int64_t   isnt that much better than a struct :P
    01:11 ichthyo now, IMHO its mostly up to gmerlin to decide how it fits into GAVL
    01:11 cehteh ack
    01:11 gmerlin Not gavl
    01:11 ichthyo gmerlin?
    01:11 gmerlin gmerlin avdecoder yes.
    01:11 cehteh in lumiera we will use usecs
    01:11 ichthyo yes
    01:12 ichthyo we will have a conversion function somewhere
    01:12 gmerlin And will it include a calendar date?
    01:12 cehteh doing it only once (avdecoder->usec) makes some sense
    01:12 gmerlin usecs since when?
    01:12 ichthyo either, we get directly usecs from avdecoder, if this fits in for gmerlin,
    01:12 ichthyo or we'll get the format which works best for him and we do the conversion ourselves
    01:12 cehteh defined elsewhere
    01:12 cehteh reel-start or absolute time or whatever
    01:13 ichthyo also, what sort of timecode this was based on (drop frame or not)
    01:13 cehteh gmerlin: thats a important point .. just uint64_t does not suffice
    01:13 cehteh it needs a tag describing what kind of timecode was used
    01:14 cehteh no matter how you encode it
    01:14 cehteh and iirc there are quite some timecodes
    01:14 ichthyo because in this respect richard was right: we need to be able to reprocuce any value 1:1
    01:14 cehteh yep
    01:15 cehteh further i want to be able to convert between any kind of timecode in a fingersnip
    01:15 gmerlin ichthyo: and that's impossible with usecs
    01:15 cehteh gmerlin: its not
    01:15 ichthyo with usecs alone: agreed
    01:16 ichthyo with usecs + metadata it should be possible
    01:16 ichthyo modulo some extreme cases (high speed cams, weeks of footage....)
    01:16 cehteh yes .. you need framerate and other infos depending on the metadata
    01:17 cehteh you need to be careful to do the math right so that inverse functions dont drift
    01:17 gmerlin I'll export something lossless, which repduces MXF, DV and Quicktime timecodes losslessly
    01:17 gmerlin You can then do what you want with them :)
    01:17 cehteh thats why i would like to do it at only *one* place/library .. because its delicate and bugs are easier to spot/fix there
    01:18 ichthyo and then there is some api to get at the additional metadata
    01:18 cehteh yeah
    01:18 ichthyo and beyond that: lets devise a libmetadata
    01:18 cehteh just shove the data over .. YYYYMMDDHHMMSSFF as int64_t would be ok
    01:18 gmerlin Ok.
    01:18 cehteh we make a libmetadata (as part of our support lib)
    01:19 cehteh somewhat independent so that it can be spun out
    }}}

    !!!! about Metadata
    {{{
    01:19 cehteh gmerlin: well .. how bout other metadata
    01:19 cehteh your decoder needs to pass that too
    01:20 gmerlin like?
    01:20 gmerlin Author, Artist title...
    01:20 cehteh some cameras encode shutter speed, focus, gain control, colour balance
    01:20 cehteh and other things
    01:20 gmerlin Hmmm
    01:20 gmerlin I think MXF exports some of these
    01:21 ichthyo wav files can have additional chunks; whats with flac?
    01:21 gmerlin flac has vorbis metadata
    01:21 ichthyo important for the more modern sound formats
    01:21 cehteh dunno .. just thinkin about pro codecs and raw film metadata
    01:21 ichthyo just wanting to point out: things to come here,
    01:22 ichthyo e.g for sound: what stream is what channel
    01:22 gmerlin Channel locations are handles by gavl
    01:22 gmerlin If you have a multichannel stream
    01:22 cehteh well .. note that there is per-asset metadata you want to pass .. and per frame metadata
    01:22 cehteh maybe even some more undiscovered cases :)
    01:23 cehteh did someone say this is easy??
    01:23 sakalli did any of you watch the video regarding red workflow that i sent to the mailing list? redcode raw holds everyting, asa, wb, etc...  hope lumiera will be able to facilitate that as well.
    01:23 ichthyo at some point I want to be able to support ambisonics
    01:24 ichthyo and maybe some day there will be wave field sysnthesis in more broad use
    01:24 cehteh the codec in the back needs to pass us these things else we cantb handle it
    01:24 gmerlin well, the easiest would be to extend bgav_metadata_t
    01:24 ichthyo rationale is: just be open
    01:24 cehteh gmerlin: maybe we need to investigate this things more, nothing needs to be decided now
    01:24 ichthyo ack
    01:25 cehteh see my key/value metadata proposal .. at some point maybe you make a complete sidechannel just for metadata
    01:25 cehteh decoder stuffs that in on demand and it is passed along with its own api like the bgav_timecode_from_pts()
    01:26 cehteh that way you dont need to touch it more than necessary
    01:26 gmerlin shouldn't that key/value stuff be unified with plugin parameters?
    01:27 cehteh for lumiera, maybe, maybe not
    01:27 ichthyo you mean: you have a common api for describing "values" ?
    01:27 cehteh some plugin parameters are determined by math functions
    01:27 gmerlin You have a key, a type and a value
    01:27 cehteh maybe for caching them
    01:27 cehteh the api might be unified .. but the storage not
    01:28 gmerlin why?
    01:28 ichthyo because any block of data could be in the metadata
    01:28 cehteh metadata which belongs to the frame coming from the decoder is const
    01:28 cehteh plugin parameters are volatile

    01:33 gmerlin One other point (but too late for it now) are audio timecodes. I'll adress that on libopenvideo
    01:33 cehteh we will write a little more sophisticated timecode library
    01:34 cehteh gmerlin: that should be unified :)
    }}}

    ! 8. May.2008 on #lumiera
    __Participants__:
     * cehteh
     * joelholdsworth
     * ichthyo
     * raffa
     * ~WesLappy
     * gmerlin

    ! Boilerplate
    !! Organization of this meeting
    * cehteh writes the protocol

    ! Webpage-Infrastructure, Maintenance

    Cehteh put this on topic because it's really urgent to bring up some infrastructure to manage the information we produce.

    The Lumiera pages on pipapo.org were always meant as intermediary solution. Pipapo.org gets much spam on the moinmoin wiki and cehteh expresses that he wants to move pipapo.org to a new infrastructure based on asciidoc and git he created (see http://git.pipapo.org/uWiki.html). This system is barely useable and needs lots of work to be completed. It would be nice to use it for Lumiera too, if the others agree. Maintaining and extending (scripting) needs someone who knows shell scripting and doesn't need to be done by the core devs freeing their resources to work on Lumiera. Cehteh expresses that none of the people who proposed to help before showed up yet. ~WesLappy tells he might help (addendum not this week, because he is busy).

    Next there was a suggestion by cehteh to convert the tiddlywikis to asciidoc. Ichthyo expresses that he likes the tiddlywikis, Joel mentions that they feel a little odd. Generally we all agree that they have some problems in sense of workflow and merging.

    Ichthyo makes the suggestion to keep the tiddlywikis as scrapbook and build up 'official' documentation based on their content in whatever-we-use-then (asciidoc) documentation system. All agree on this approach.

    Back to the new wiki, cehteh suggests to make stricter access rules to prevent spam: "There will be a group of 'Validated' people which following rules: only Validated people can edit general content and 'Validated' people can add new people to 'Validated' themselves". That means that we can have a lightweight self-administrating authentication where new people have to be introduced by someone who is already there.

    Ichthyo suggests to send a reply to Serge G. who send an introduction to the cinelerra mailing list expressing that he would like to help.

    Raffa will take care of content/design as much her time/knowledge permits.

    __Conclusion__:
    * We really need someone to help with the webpage scripting.
    * Documentation needs to be well organized and moved over.
    * Content of the pipapo.org moinmoin wiki should be moved over.
    * The new website should be well organized with a nice looking frontpage
    * All other documentation should be below that

    -----

    ! Whats pending in DesignProcess

    !! MistakestoAvoid
    http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MistakestoAvoid

    rick_777 wrote a "MistakestoAvoid" page which explains some possible gotchas. We basically agree with most points there while we already decided to address some things differently than he suggested. One noteable difference is that we do not intent to provide a windows version of Lumiera, which was explained in serveral places. Cehteh added some comments to the page explaining some things.

    -----

    nothing more to discuss in 'Ideas', we go over to 'Drafts'

    !! ArchitectureOverview
    http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview

    Cehteh suggests to put that drawing under version control, as .fig. Ichthyo explains that it is already a .SVG and that he does not like .fig.

    Conclusion: We agree to keep it as .SVG, add it to the repository and improve/complete it.

    !! GitSubmoduleTransistion
    http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/GitSubmoduleTransistion

    Another suggestion made by cehteh is to make managing of subprojects within the sourcetree easier. Joel and ichthyo oppose that it is not really needed now and needs more understanding of git. Ichthyo suggests that the documentation might be separated into its own git, he further explains that the things are not settled yet and we don't know if we will some rearrangements and movements of files between modules.

    Conclusion: We transform the documentation to a submodule and see how it works. Other things will be decided much later.

    !! GlobalInitialization
    http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/GlobalInitialization

    This topic is discussed and agreed on the DesignProcess page already.

    __Conclusion__: finalize it

    !! MasterRepositorySetup
    http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MasterRepositorySetup

    Setting up an master repository was decided on the last meeting. cehteh now set one up which also does some automatic, but intended fragile merging from subsystem maintainer branches.
    # it updates automatically for the maintainers repo for conflict free fast-forwards
    # it can always be overridden with explicit pushes

    The others agree on the setup.

    Ichthyo stresses that maintainers shall watch that their 'master' branch should compile cleanly and pass the testsuite always, test which are not operational should be tagged as PLANNED. We all agree...

    Then a short discussion about building and synchronizing the docs follows. Problem is that docs build in maintainer branches are different for each branch, rsyncing them up to the server will always change a lot of things. We agree that the 'official' docs shall be build from the LUMIERA/master repository, preferably on the 'devel' vserver which has to be set up.

    __Conclusions__: Make this final, setup build environment in the devel server and build docs there.

    !! NoBugFlags
    http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/NoBugFlags

    Defining a debugging control hierarchy. This is work in progress and cehteh explains that he works it out and deploys it, this depends on the GlobalInitialization decided earlier.

    __Conclusion__: accepted, finish and finalize it.

    ! Further Technical Discussion

    Ichthyo asks how the GUI will be pulled up. Since he didn't attend IRC discussions recently he has no information yet what's going on. We explain him that we already made some discussions. Integrate the GUI into the build system probably linked as library, nothing finally decided yet. Communication will go over the plugin/interface facility (Plain C API). This things should be worked out and documented in DesignProcess.

    Cehteh made a small tool {{{./admin/headercheck}}} which will gradually extended to proof that headers are sufficiently selfstanding.

    ! Progress

    ''Cehteh'' finished low level file handling and working in mmaping and frameprovider next. When thats finished, the finalization of the Plugin loader and interface definition things is the most urgent thing.

    ''Ichthyo'' works on the builder internals and next on some sort of "connection manager".

    ''Joel'' goes on with GUI pro9gramming and integrating it into the source tree next.

    Gmerlin and cehteh discuss about how to handle the index files which avdecoder uses internally. cehteh would like to manage them in the Lumiera backend to, because filehandles are a precious resource. Gmerlin explains that this index files are just loaded and kept in memory. So this poses no problem for filehandle exhaustion. We will discuss this further via email.

    Cehteh suggests that we should think about some kind of preferences/registry sometime next to store default configs.

    Following a discussion about how messages are passed between GUI and core. Generally we will use the interfaces defined by the plugin system. Gmerlin says that he uses message queues in 'gmerlin', Joel requests that a lot of things should be done synchronous and he wants to avoid message queues. Cehteh suggests to use use the scheduler for GUI things too. For the parts where the GUI interacts with the high level proc model ichthyo and joel agree on working something (synchronous) out. Ichthyo stresses that the edit core is not threadsafe by design and relies on the backends scheduler. The underlying builder might sometimes to expensive for synchronous calls (ichthyo plans a rule system there) this needs to be worked out.

    Ichthyo explains that the builder needs to detect cycles and check if the high level model is translateable into the low level model (in case plugins git removed and so on). Parts in the render graph which are not 'doable' should be flagged as erroneous but not dropped since one doesn't want to loose project information when loading a project on a machine with different installed plugins. In any case it should be possible that the GUI gets immediate synchronous feedback for such things.

    ! Next Meeting

    Next meeting is on thursday 5th June 21:00 UTC

    ! 5.June 2008 on #lumiera
    21:00 -23:15 UTC. __Participants__:
     * cehteh
     * ichthyo
     * joelholdsworth
     * rcbarnes
     * raffa

    //Protocol written by ichthyo//

    ! Left over from the last meeting
    //Nothing left over and no urgent topics.//
    Seemingly, work is proceeding in all parts of the application.

    ! Discuss Ideas and Drafts in design process
    //There are no new design proposals and no proposals that can be finalized.//

    Ichthyo points out that he's about to work out the details of some of his proposals, which are currently in "idea" state. Following that, most of the meeting is spent on discussing the details of two of these proposals.

    !!! Idea: Design the Render Nodes interface
    [[Design of the render nodes interface|http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DesignRenderNodesInterface]]

    ''Cehteh'' points out that, as we are in the pre-alpha phase, interfaces may be growing on-demand. Later on, interface versions will be numbered. If needed, we could add a special "draft" or "experimental" tag, or, alternatively, use the common numbering scheme, where odd major version numbers denote the development line of an interface.

    ''Ichthyo'' agrees, but adds he also meant "interface" in this proposal in a wider sense, like in "what do we need and require from a processing node". Knowing how generally Lumiera will handle the processing nodes while rendering helps him with defining and implementing the builder

    __Conclusion__: "currently in work". For now, grow interfaces on demand.
    -----

    !!! Idea: Placement Metaphor used within the high-level view of Proc-Layer
    [[Placement Metaphor in the Proc-Layer|http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor]]

    In the course of the discussion, ''Ichthyo'' explains the rationale
    * one common mechanism for sticking objects together and putting them into the session
    * either specify the "placement"-parameters (time, output destination, track) directly, link to another object's parameters, or derive some or all of those values from the context (up the tree of tracks)
    * ability to build a system of high-level media objects (clips, effects...) which re-adjust automatically on change
    * extensible to handle or derive some parameters based on conditions and rules, e.g. for semi-automatic wiring of the output destination based on tags

    ''Joelholdsworth'' is concerned that this proposal may go too far and tries to tie things together which aren't really connected. While basically it's no problem having the time position of a clip either absolute, or derived by a link to another object, he can't see a clear benefit of controlling sound pan or video layer order from the placement. Pan, for example, is just an parameter value or interpolated curve, similar to colour correction or gamma adjustment. For the gui, he points out, it's probably better to stick to the object metaphor, so start time, output, layer number or sound pan would be properties of the object.

    But that's exactly what Ichthyo wants to avoid. Obviously, this would be the standard solution employed by most current editing apps, and works reasonably well in average cases. But he is looking for a solution which covers this standard case, but also doesn't get into the way when dealing with advanced compositing, working with spatial sound systems (Ambisonics, Wave Field Synthesis) or stereoscopic (3D) video.

    //On the whole, there is no conclusion yet.// Certainly, this proposal needs more discussion, parts need to be defined much more clear (esp. the "Pro" arguments), maybe parts of the functionality should be separated out.

    While in this discussion, several aspects of the cooperation of GUI and Proc layer are considered.
    * it is not necessary to make all of the Placement proposal visible to the GUI (and the user). Proc layer may as well provide a simplyfied and hard wired API for the most common properties (layer index, pan) and only use this part of the Placement concept for building and wiring the nodes.
    * the adjustment of objects linked together by a placement can be handled as follows:
    *# GUI notifies Proc of a position/parameter change of one object and gets immediate, synchronous feedback (OK or fail)
    *# Proc detects the other linked objects affected by the change and notifies GUI (both synchronous and asynchronous is possible) to update information regarding those objects
    *# GUI pulls the necessary properties by calling Proc on a per object base.
    * as a rule of thumb, GUI <-> Proc is mostly synchronous, while Backend <-> GUI is often asynchronous, but there are exceptions from the rule
    * we have general //parameters//, which are automatible. These are represented as //control data connections between the nodes.// We certainly don't want to represent some things in this way, though. For example, the in/out points of clips are fixed values.
    * in Ichthyo's concept, the Placement doesn't itself provide such parameter values/sources, rather it can be used to //find// or //derive// parameter sources.
    * the node graph is built bottom up, starting at the source, then via the effects attached locally to a clip, further on upwards (directed by the tree of tracks) to be finally connected via global busses to the output ports. Rendering pulls from these output ports.
    * Joelholdsworth, Cehteh, Ichthyo and Rcbarnes agree that the plain //node-editor// approach is problematic in the context of a NLE. It shows too much details and fails to capture the temporal aspect. We strive at having node-like features and flexibility, but rather within the timeline.
    * especially, the topology of the node graph isn't constant over the whole timeline. But it's the job of the builder in the Proc layer to deal with these complexities, the user shouldn't be overwhelmed with all those details.
    -----

    ! Next meeting
    * some people in europe complained that 21:00 UTC is too late, esp. with daylight saving
    * there was the proposal to alternate between the current schedule, and sunday 16:00 UTC
    * but Joel can't attend on sunday afternoon for now
    * so we settle down on thursday, 16:30

    Next meeting: ''Thursday 3.July 2008 16:30 UTC''

    ! 6.July 2008 on #lumiera
    __Participants__
    * ichthyo
    * cehteh
    * jilt
    * dmj726
    * Teld
    * _nasa_
    * alcarinque_
    * MNO
    * Wescotte
    * weatherhead

    //Protocol written by Teld//

    !Boilerplate
    !!Organization of this meeting
    * dmj726 intends to write the protocol
    * ichtyo is chairman
    * there is no agenda, so this is a freeform meeting
    !!Leftovers from last meeting
    //There are no leftovers//

    !Introduction of Lumiera
    Because there are quite some new participants, an introduction of the project Lumiera is given

    There are 3 core devs:
    * cehteh: backend serving data (from filesystem and so on), manages threads, using C, Posix System programming, maintains autotools and git
    * ichthyo: proc layer, render graph, in the middle, C++, he maintains scons
    * joelholdsworth: GUI in C++/Gtkm
    Other people involved:
    * rcbarnes: ui designer and HCI expert
    * raffa: web content
    * Simav: gives a hand when and where he can
    * Teld: web infrastructure

    The foundations of the design are already done but a lot of detail needs to be worked out. cehteh and ichtyo provide a non exhaustive list.

    cehteh:
    * improvement of the testsuite (simple Bash)
    * start of a worker thread manager (Posix knowledge required)
    * start of the scheduler (some Posix, good C coding)
    * runtime profiler (little but advanced Posix realtime programming job)
    * review of code and documentation
    * system administration
    * setup of a build/test environment on the server
    * setup and maintain postfix/dovecot by a mail administrator
    ichtyo:
    * asset management (keeping track of all media files, captures, clips, scenes)
    * session loading saving and the issues of compound documents
    * session structure related issues to be able to Import/Export/Connect via e.g. OSC (Open Sound Control) or JACK
    * flesh out the more high level "edit operations" and the interface to UNDO
    * Prolog integration after the first integration round has been reached. The Prolog interpreter will do some of the more advanced configuration (example: if effect XYZ is used, then deinterlace beforehand).
    * integration with some sort of production support software (like Celtx)
    cehteh emphasizes that Lumiera is an open project, so anybody can jump in where he sees fit as long as he communicates and acknowledges with the persons involved. ichtyo points out that the plugin structure is very important: anything that is not legally completely clean (proprietary), should be factored out into a sister project and be loaded as plugin.

    !Issues and questions that come up
    !!handling of config errors.
    When the configuration has a syntax error, in 90% of the cases there will be no possibility to do anything sane. Therefore, the config system will be built to log a warning and the user code does not need to care. The user just gets an alert and the application continues to work.

    !!scripting language.
    There will be a scripting interface. ichtyo does not want scripts everywhere, only at well defined interfaces. That implies also that scripts cannot just do anything, only that what is permitted in a controlled way. The meeting agrees on that. cehteh wants one default language and proposes Lua: light, simple.

    Other members suggestions: Python, Ruby, Scheme. However, Python and Ruby are very slow. Scheme has many variants.

    !!editing on small devices (eeePC)
    Problem: video editors GUIs are some of the most elaborate and complicated GUIs. However, basic functions consist of only a few buttons. Proxy editing could be a solution. It is decided that it is not a primary goal now. First the basics have to be implemented.

    !!uWiki.
    uWiki is the glue between a markup driver (Asciidoc) and revision control (git). Haserl with Bash is used now. Haserl appears to have problems with conditional includes. Its limits have been reached while prototyping. Lua could very well be a valid replacement. It will be investigated. PHP is rejected because it is not stable and suffers from serious security problems.

    !!'musical' timeline in bars and beats
    The questions of syncing and linking things together are already on the core agenda: the so-called placement concept. Discussion is still going on, especially with the GUI developer joelholdsworth. See for detailed information: http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcPlacementMetaphor

    !Next meeting
    The next meeting will be held ''Thursday, 7 August 19:00 UTC''

    !Oct 10, 2008 on #lumiera
    19:00 - 23:15 UTC
    __Participants__
    * cehteh
    * ichthyo
    * joelholdsworth
    * alcarinque
    * ~KenSentMe
    * Plouj
    * raffa
    * thorwil
    * Victor_Sigma
    * wildhostile

    //Protocol written by Ichthyo//

    !!!organisational
    Not much of a fixed agenda this time.
    Agreement to start with the Logo discussion, as this is of general interest, followed by the design drafts and similar dev topics.

    !The Lumiera Logo
    Summary of the situation: discussion regarding a logo for Lumiera is going on sporadically since quite some time. Several people from the community have made proposals. Also, there was discussion about the criteria a logo would have to fulfil. Especially the core devs raised the bar and required quite some professional level of design. On the contrary, several members of the community were concerned that such a demanding attitude will hinder creativity in a domain which is far off from coding. Moreover, many people complained they are really excited about Lumiera and strongly want to participate in some manner, but find it very difficult in the current phase of the project to give any valuable contribution.

    This summer, one of the proposals by [[Leandro Ribeiro|http://farm4.static.flickr.com/3060/2927333034_ac94be80ea_b.jpg]] gained some popularity and especially was embraced by two of the core devs, while the GUI core dev wasn't convinced and [[explained|http://www.pipapo.org/pipawiki/JoelHoldsworth/LogoThoughts]] his reservation. Prior to this meeting some people joined a brainstorming session and came up with [[another design|http://www.pipapo.org/pipawiki/Lumiera/Logos?action=AttachFile&do=get&target=combo.png]] compiled of several proposals, which could meet the acceptance of the core devs. At the same time, Raffa made an argument for conducting a public contest, similar to the one which gave us the name of Lumiera. The situation for Lumiera is somewhat special. Usually, the community builds when the product is already minimally usable; we can't have users for now, but we have a lot of prospective users.

    Thus, while basically it would be possible for the core devs to shorten the process by just picking a design which is acceptable for all, maybe after augmenting it a little, several of the arguments articulated this far are in favour of a more formal decision by a contest:
    * it would allow for a lot of people to really participate
    * it could help to shape a general (graphic) style for Lumiera
    * it could underpin the fact Lumiera indeed is a collaborative effort
    * it doesn't mean additional work for the core devs on the whole
    * it helps spreading the word

    Then, there is some discussion about the requirements. The core devs are concerned to keep up some quality level, because there is the possibility for the community to embrace a design, but when Lumiera enters the area it is intended to do, the standards of comparison will be different. The GIMP logo can be quoted as a negative example here.

    !!Conclusion
    There will be a Lumiera Logo contest.
    * we should further discuss requirements on the Mailinglist until the end of the next week
    * the ''deadline for submissions'' will be the next meeting (Nov 12 2008)
    * then, after a pre-selection phase, the vote shall be conducted prior to the December meeting.

    Some minimal technical requirements will be enforced:
    * the basic sign fits a compact rather quadratic bounding box (like 4:3)
    * easy to print on various media (on posters, t-shirts, ..)
    * basically a shape, using only a small number of solid colours (web safe)
    * should work on different backgrounds, esp. not requiring white background
    * the design should scale from microscopic size (favicon) up to big posters
    * vector graphic source is mandatory

    Besides, we give some artistic guidelines
    * it should be recognisable
    * it should contain something like a sign, not just "Lumiera" in a fancy font
    * it should not rely on transparencies, gradients and subtle shades,
    * it should be viable, possibly work well in different presentation styles, able to be simplified as well as graphically augmented

    Raffa volunteers to help organizing the contest and the voting.
    ----

    !Recurring Topics: design proposals
    Discussion of open [[design process|http://www.pipapo.org/pipawiki/Lumiera/DesignProcess]] drafts.

    !!Mistakes to avoid
    [http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/MistakestoAvoid Mistakes to avoid in the Lumiera Design]
    We are carrying this one along since quite some time and we'd like to get rid of it, either by reworking it or by dropping it as-is. Because it contains a mixture of things
    * we fully agree to 80% of the statements made there, but we think those statements are so very basic and self-evident as to be considered off-topic here. We are aware of the recurring problems with open source video editing. That's why we are here.
    * the proposal draws conclusions on two technically substantial points, at which we don't agree. And it fails to provide sufficient (technically sound) arguments to prove these statements.

    While it is certainly //desirable// to be cross-platform as much as possible and especially ''target Microsoft Windows'', we don't see much possibilities with today's mainstream technology to build an application which is as technologically demanding as a video editor is. We would end up developing two or even three sister applications, or we are forced to sacrifice performance for portability. When put up to face such options, we have a clear preference to concentrate on a really free and open platform.

    While it is certainly //desirable// to make the application as robust as possible, we don't see how ''using multiple separate processes'' could help us with this goal //without creating major scalability or performance problems// due to the use of shared memory. And, yet more important: we don't share the basic assumption made in the proposal, namely that video processing is inherently dangerous. We think the basic algorithms involved are sufficiently well-known and understandable to implement them in a sound manner.

    __Conclusion__: drop it

    !!!!on the question of separate processes
    The only practical solution would be to separate the GUI. Separating backend and proc-layer doesn't make much sense, technically speaking. We re-considered this question. Joelholdsworth (GUI) and Ichthyo (Proc-layer)prefer running the GUI in-process and to avoid the additional hassle with shared memory. Cehteh (backend) doesn't care for know and would like to re-discuss it as an option later on. This is somewhat similar to the possibility of running Lumiera distributed over the network, which is a goal, but not an immediate one.

    !!Tag Clouds
    [http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/TagCloudsOnResources Tag clouds on resources]
    Tags are considered very important. Meanwhile, we have a much more advanced proposal, which superseeds this one: [http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/DelectusShotEvaluator "Delectus"]

    __Conclusion__: drop it

    !!Overview of Lumiera Architecture
    [http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ArchitectureOverview Architecture Overview]
    The purpose of this drawing to give an first impression what subsystem is where and what the names mean. Since discussed last time, Ichthyo re-arranged the plugins as requested and added some details for the backend. Joelholdsworth points out that it's OK for him to show the GUI just as a single block here (and of course the GUI has much more internal structure). Cehteh adds that maintaining this drawing surely is a moving target, so we better remove the rendered image and just retain the textual description and link to the source (SVG), which is in GIT.

    __Conclusion__: accept it, change the image to a link

    !!EDLs as Meta-Clips
    [http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/EDLsAreMetaClips EDLs are meta-clips]
    This is just a high-level proposal, which doesn't go into technical details of implementing nested EDLs. It just poses the question "do we want to treat nested EDLs as being meta-clip" -- which we do.

    __Conclusion__: accepted

    !!The Builder
    [http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcBuilder Builder in the Proc-Layer]
    Similar to the previous one, this is a high-level proposal. It covers the fundamental approach Ichthyo takes within the Proc-Layer. Cehteh adds that he agrees to 98% and the remaining 2% are just matter of favour. Personally, he would have preferred one large graph which gets garbage collected (instead of the segmented graph)

    __Conclusion__: accepted

    !!High-level Model
    [http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ProcHighLevelModel Overview of the High-level model within the Proc-Layer]
    Cehteh queries if this shouldn't be better moved over to the documentation? He is fine with the contents, but it seems to be a bit voluminous for a design proposal. Ichthyo asks to leave it there just for now, as he feels it still needs review.

    __Conclusion__: leave it for now, maybe retract it from the design proposals and file it as documentation?

    !!Lua scripting language
    [http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/ScriptingLanguage use Lua as required scripting language]
    All core devs agree with this decision. Joelholdsworth points out that he is fine with Lua, just he didn't want to write the GUI in it. Ichthyo adds that Lua is probably the best choice from today's mainstream scripting languages, because it is very lightweight. He further points out, that having Lua as //required// scripting language doesn't rule out using other popular languages (Python, Ruby) for scripting. Just they aren't required for running Lumiera. Cehteh will have a look at the details as soon as possible, but has currently other more urgent things in the queue. (Plouj shows interest to help here)

    __Conclusion__: accepted

    !!Time Handling
    [http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/time_handling time handling]
    A long standing proposal; meanwhile we've decided to build on GAVL, which is now reflected in the text of this proposal too. Ichthyo points out he changed the rounding rule in this proposal from "mathematical" to "floor (x+0.5)". Cehteh asks if we should use a thin library layer on top of gavl, to centralize all the time calculations. There seems to be agreement that this should actually be done //on demand.// Joelholdsworth sais sometimes he'd prefer to have a simple raw type to represent time, because it makes calculations much easier. Ichthyo adds that internally (within the layers, but not on interfaces) one could use a thin C++ wrapper with overloaded operators, which is default-convertible to gavl_time.

    __Conclusion__: accepted

    Note: the proposed rigid testsuite for time handling is necessary only when we introduce a wrapper...

    !!Interface naming convention
    See the design proposal [http://www.pipapo.org/pipawiki/Lumiera/DesignProcess/InterfaceNamespaces Interface Namespaces]. While working on the plugin loader, ''Cehteh'' and ''nasa'' did some brainstorming about a plugin naming scheme and how to get unique interface identifiers. The idea is to use a distinctive prefix, like a condensed organisation domain or email name, or a GPG fingerprint or even a UID, followed by the interface namespace hierarchy. These would be combined into a single identifier (valid C name). The intention is to get non-ambiguous names, yet avoiding the need of a central registry.

    __Conclusion__: accepted

    ----
    general Topics

    !Config System
    ''cehteh'' landed the first version of this subsystem and asked for review and testing. Currently it's "work with no progress", but it is basically usable (you can get values, you can set values by environment variables, but you can't persist). It should be augmented on demand, e.g. by adding the support for more value types (value types are a hint how to parse, and link the parsed value to a given C type).

    !Use of Namespaces
    Currently there is no clear uniform rule regarding namespaces use. ''Joelholdsworth'' places his code within lumiera::gui and below. He points out that external libs like Cairo, GTK, GLib will bring in their hierarchies and all of Lumiera should comply and put anything below a lumiera:: root. On the contrary, ''Ichthyo'' deliberately moved his implementation code away from the central lumiera:: interface hierarchy into shallow namespaces and avoids nesting. He argues that having all code below luimiera:: effectively makes this namespace global or forces it to be void of any function; rather he'd prefer to import every interface explicitly into the implementation namespace. ''Cehteh'' argues that having a global lumiera::, even if empty, would mark a general claim and stand for the uniformity of the project. Generally, there should be some correspondence between folders and namespaces.

    No conclusion yet, to be discussed further.

    !Interface Definition Language
    In his work on the plugin loader, ''Cehteh'' created a first draft how to export an interface, and calls for review. An example can be found in [http://www.lumiera.org/gitweb?p=lumiera/ct;a=blob;f=tests/backend/test-interfaces.c;h=fb1c4d30a34414767a313d24df60e679c96ad2a7;hb=7323114e77348995ccaf03417136aef7ee332776 tests/backend/test-interfaces.c]

    An interface is a list of "slots" mapping functions. The interface descriptor is itself realised as interface, an thus can be versioned, extended and specialised. By use of some glue code and macros we create a simple Interface Definition Language
     * after exporting a header with the C interface, including the types to be used...
     * LUMIERA_INTERFACE_DECLARE creates an interface description (i.e. the official interface)
     * implementing such an interface can be done in 3 major ways
       * LUMIERA_INTERFACE_INSTANCE creates an instance on-the-fly (e.g. for descriptors)
       * LUMIERA_EXPORT for defining a table of functions/interfaces to export from the core
       * LUMIERA_PLUGIN for defining an interface table for functions located within a dynlib module (plugin)
     * besides, with LUMIERA_INTERFACE_INLINE you can create a function on-the-fly while LUMIERA_INTERFACE_MAP maps onto an existing function directly

    The plugin loading system cares for mapping the given implementation function to the interface slots. Interfaces from the core need to be registered before they can be used, while for plugins this is done automatically on loading the module. The client code later just calls {{{interface_open()}}} and {{{interface_close()}}} where it doesn't matter anymore if the invoked function is in the core or loaded from an dynlib (plugin); loader, registry and/or plugin-DB shall manage it transparently.

    Version numbering starts with 1 and uses minor version numbers for compatible changes and major version numbers for everything that breaks existing asumptions. Version number zero is reserved for experimental work and per definition always the most recent version number.

    The system is designed to be very flexible and extensible, but this foundation really needs thorough review.

    Joelholdworth expresses some concern regarding the UIDs in octal notation used within the interface description. Cehteh explains they never need to be specified by client code. They are just distinctive IDs and provided for some special case within the plugin loader / serializer. He plans to provide a simple tool which automatically replaces a $LUIDGEN with such a bitstring. The octal notation was chosen, because it is the most compact albeit portable notation possible in C source code.

    !!Conclusion

    looks good, agreement by all core devs.
    Should be reviewed and investigated in detail to find any hidden problems.

    !Next meeting

    There were some problems with the meeting schedule. Using the first week of month seems to be problematic. We'll try with second wednesday...

    The next meeting is scheduled for ''Wednesday Nov 12 2008 19:30 UTC'' at #lumiera

    ! 5.June 2008 on #lumiera
    __cehteh__ and __ichthyo__
    {{{
    [2008-06-05 19:21:21] <cehteh> do you need me? .. i am away if not .. i have no much to say for the today meeting either
    [2008-06-05 19:21:57] <ichthyo> I have one topic I want to discuss with you, cehteh
    [2008-06-05 19:22:07] <ichthyo> but it need not be now, or in the meeting
    [2008-06-05 19:22:07] <cehteh> ok
    [2008-06-05 19:22:24] <ichthyo> it's about allocating processing buffers
    [2008-06-05 19:23:20] <cehteh> the backend will provide them as temporary files/cyclic buffers
    [2008-06-05 19:23:52] <cehteh> its not there yet but in my mind
    [2008-06-05 19:24:11] <ichthyo> haha, same for the builder... it's mostly just in my mind
    [2008-06-05 19:24:42] <cehteh> opened almost like a normal file but giving frame properties instead filename
    [2008-06-05 19:24:56] <cehteh> (there will be a distinct api for that)
    [2008-06-05 19:25:01] <ichthyo> ok
    [2008-06-05 19:25:05] <ichthyo> regarding the buffers: my question is more special
    [2008-06-05 19:25:19] <ichthyo> if you want to cache a frame (intermediary result)
    [2008-06-05 19:25:35] <ichthyo> then I thought we could avoid the copy operation
    [2008-06-05 19:25:44] <ichthyo> I could arrange things accordingly
    [2008-06-05 19:25:46] <cehteh> then the backend creates a backing mmaped file for that maybe manages its size (or do you want to tell how much frames you want to cache?)
    [2008-06-05 19:26:06] <cehteh> yes perfect .. thats what i am planning
    [2008-06-05 19:26:26] <ichthyo> you know, many processing nodes will be able to process "in place"
    [2008-06-05 19:26:34] <ichthyo> but ther are some that can't do this
    [2008-06-05 19:27:44] <ichthyo> so basically each processing function will "see" input frame buffer(s) and output frame buffer(s). but when a node is "in-place-capable", actually the in and out buffer may point to the same location
    [2008-06-05 19:26:55] <cehteh> basiically all temporary frames with the same properties are allcoated from the same backing file (well maybe 2 caching levels but not important here)
    [2008-06-05 19:27:06] <cehteh> the index give them meaning
    [2008-06-05 19:27:49] <cehteh> do you can query (and lock) a frame by that
    [2008-06-05 19:28:04] <ichthyo> that sounds good
    [2008-06-05 19:28:24] <cehteh> do some inplace editing and then tell the backend "this is now frame N of node X"
    [2008-06-05 19:28:34] <ichthyo> yeah, exactly
    [2008-06-05 19:28:44] <cehteh> (plus a uuid or preferably genertion number)
    [2008-06-05 19:28:39] <ichthyo> basically my Idea was as follows:
    [2008-06-05 19:29:47] <ichthyo> when I know the result will be cached, I'll let the node process into the location of the cache frame, and any node which will /use/ this frame as an input will be wired such that it isn't allowed to modify this frame (which is supposed to be located in the cache)
    [2008-06-05 19:30:45] <cehteh> yes thats managed in the index
    [2008-06-05 19:30:48] <ichthyo> for this to work, I need to "allocate and lock" a location in the cache, and release it when it contains the final processed result
    [2008-06-05 19:31:17] <cehteh> well i try to make no locks there, you query frames which are uniquely identified
    [2008-06-05 19:31:44] <ichthyo> it doesnt need to be a "lock
    [2008-06-05 19:31:55] <ichthyo> just some way to tell that this frame is "under construction"
    [2008-06-05 19:32:01] <cehteh> yes
    [2008-06-05 19:32:14] <cehteh> we thinking the same :)
    [2008-06-05 19:32:57] <cehteh> well problem is when shortly after that another node queries the source frame which got destructed .. thats something the builder needs to avoid, nothing i can do then
    [2008-06-05 19:33:21] <ichthyo> yes, builder will care for that
    [2008-06-05 19:33:41] <ichthyo> I can even tell in advance the maximum number of temporary buffers I need
    [2008-06-05 19:33:51] <cehteh> and it not only needs a under-construcion
    [2008-06-05 19:34:44] <cehteh> there are 2 indices one for source and one for destination
    [2008-06-05 19:35:11] <cehteh> indices will have a pointer to the 'job' working on it i tihnk
    [2008-06-05 19:35:24] <ichthyo> ok
    [2008-06-05 19:35:48] <cehteh> (actually there is a list planed many jobs can read-share an frame)
    [2008-06-05 19:36:40] <cehteh> i would like if I do not need to do *any* checks in that direction ... means the builder delivers clean jobs which dont step on their own foot
    [2008-06-05 19:36:54] <ichthyo> my understanding too
    [2008-06-05 19:37:07] <ichthyo> also, I want the nodes to be freed of any checks
    [2008-06-05 19:37:33] <ichthyo> so they can assume they get a valid buffer pointer to the right sort of buffer
    [2008-06-05 19:37:54] <cehteh> yes thats guranteed
    [2008-06-05 19:37:41] <cehteh> if it fails then we get some hairy bugs ... but checking job dependencies afterwards is costly
    [2008-06-05 19:38:53] <ichthyo> I mean -- I want to prepare everything as much as possible while building, so that all that needs to be "filled in" when starting the processing are the actual buffer locations
    [2008-06-05 19:38:58] <cehteh> *thinkin* prolly easier than it looks
    [2008-06-05 19:39:10] <cehteh> exaxctly
    [2008-06-05 19:39:50] <ichthyo> we can't prepare everything, because, some nodes may include a variable ammount of source frames
    [2008-06-05 19:40:11] <ichthyo> and this number can depend on automation. Classic example is the "time average" video effect
    [2008-06-05 19:39:53] <cehteh> problem is only when the builder generates one node which takes X and in-place generates Y from it
    [2008-06-05 19:40:10] <cehteh> and you have a 2nd node which takes X too
    [2008-06-05 19:40:23] <cehteh> this needs to be serialized somehow
    [2008-06-05 19:41:12] <ichthyo> regarding the problem you mention: I want to exclude/avoid this situation already when building
    [2008-06-05 19:41:35] <cehteh> yes thats what i was thinking .. thats easiest addressed there
    [2008-06-05 19:41:46] <cehteh> and a very ugly bug when it fails :(
    [2008-06-05 19:41:42] <ichthyo> when a node puts its result into a frame located within the cache
    [2008-06-05 19:41:59] <ichthyo> this frame is treated as if it is read-only
    [2008-06-05 19:42:21] <ichthyo> no node depending on this frame will be wired in a way that allows "in-place"
    [2008-06-05 19:42:33] <cehteh> about the time averaging: i plan to hint some dependencies so you can ask for "maybe" or by some priority depending on quality/whatever
    [2008-06-05 19:43:19] <cehteh> where quality should be runtime adjusted by the profiler
    [2008-06-05 19:43:39] <ichthyo> the problem with time averaging is: we don't know how much frames will be averaged at build time, because that's a automatable effect parameter
    [2008-06-05 19:43:47] <cehteh> thats a case where a dependencie might not be fullfilled .. but only on request
    [2008-06-05 19:44:08] <ichthyo> but the "quality" thing sounds like a good idea
    [2008-06-05 19:44:17] <cehteh> yes then split that rendering into 3 passes?
    [2008-06-05 19:44:27] <cehteh> 1st pass : building the graph
    [2008-06-05 19:44:53] <cehteh> 2nd pass: determine dependencies (by inspecting automation)
    [2008-06-05 19:45:00] <cehteh> 3rd pass: do the render
    [2008-06-05 19:45:10] <ichthyo> maybe?
    [2008-06-05 19:45:17] <ichthyo> 1st pass of course is clear
    [2008-06-05 19:45:25] <cehteh> well do you have a better idea?
    [2008-06-05 19:45:49] <cehteh> so far i thought about 2 pass where the dependency analysis was part of the builder
    [2008-06-05 19:46:02] <ichthyo> agreed
    [2008-06-05 19:46:28] <cehteh> but making it three pass shouldnt be a problem or?
    [2008-06-05 19:46:51] <ichthyo> I also thought after having finished the raw graph, I'll do some configuration calldown, e.g. to determine the maximum number of buffers needed
    [2008-06-05 19:46:59] <cehteh> maybe even adaptive 2/3 pass depending on effects ... but maybe that would complicate it unnecessary
    [2008-06-05 19:47:43] <ichthyo> its not really a problem, just need to be aware and work the details out correctlyy
    [2008-06-05 19:47:49] <cehteh> i dont think you need  to count the buffers (not yet, maybe i oversee soemthing)
    [2008-06-05 19:48:08] <cehteh> otherwise the backend should manage that automatically
    [2008-06-05 19:48:18] <ichthyo> yes, I'm fine with that
    [2008-06-05 19:48:46] <ichthyo> just to note, if it helps with the allocation, I /can/ tell the maximum number of buffers needed
    [2008-06-05 19:49:00] <ichthyo> (for a given segment of the graph, of course)
    [2008-06-05 19:49:09] <cehteh> not sure if i overseen something, but i think when needed such a 'configuration calldown' (and optimizing pass) could be added later
    [2008-06-05 19:49:27] <ichthyo> sure
    [2008-06-05 19:49:50] <cehteh> buffers itself doesnt cost .. but if you really need a lot it will cause IO
    [2008-06-05 19:49:57] <cehteh> but that unavoidable anyways
    [2008-06-05 19:50:05] <ichthyo> no no
    [2008-06-05 19:50:19] <cehteh> yes yes
    [2008-06-05 19:50:20] <ichthyo> I'll try to minimize buffer use as much as possible
    [2008-06-05 19:50:24] <cehteh> :)
    [2008-06-05 19:50:30] <cehteh> of course
    [2008-06-05 19:51:00] <cehteh> but there are always some limits on finite machines
    [2008-06-05 19:51:26] <ichthyo> the problematic case are usual rather rare corner cases, but it should handle those flawless, of course
    [2008-06-05 19:51:36] <ichthyo> similar for the size of the buffers
    [2008-06-05 19:51:46] <ichthyo> I dont want Lumiera to clip the image
    [2008-06-05 19:51:49] <ichthyo> as cinelerra does
    [2008-06-05 19:52:04] <ichthyo> e.g. when using the motion tracker
    [2008-06-05 19:52:20] <cehteh> well if you need safe-regions around you need to use biggier frames
    [2008-06-05 19:52:31] <cehteh> but memory requirements grow quadratic!
    [2008-06-05 19:52:46] <ichthyo> the user should NEVER need to set up the processing buffer size, as is necessary in cinelerra
    [2008-06-05 19:52:59] <cehteh> yes agreed
    [2008-06-05 19:53:15] <ichthyo> I don't think we need safe-regions allways,
    [2008-06-05 19:53:31] <ichthyo> but, as e.g. the motion tracking will create automation data in Lumiera
    [2008-06-05 19:53:38] <cehteh> yes only for some effect .. motion tracker doesnt need it
    [2008-06-05 19:53:50] <ichthyo> it means the actual buffer size depends on automation data for a given frame
    [2008-06-05 19:53:56] <cehteh> that just xyr transformation
    [2008-06-05 19:54:35] <cehteh> a blur is something which might require a small safe-region to bleed over the edges
    [2008-06-05 19:54:43] <ichthyo> yes, you are right
    [2008-06-05 19:54:52] <ichthyo> if the motion tracker is wired intelligently
    [2008-06-05 19:55:05] <ichthyo> it doesn't need to move anyting itself
    [2008-06-05 19:55:18] <cehteh> mapping the motion tracker transformation to a destionation might need safe regions
    [2008-06-05 19:55:30] <cehteh> (in case of rotations)
    [2008-06-05 19:55:36] <ichthyo> yes agreed
    [2008-06-05 19:56:16] <cehteh> well temp buffers will be allcocated for frames of the same 'class' i aleready saied that
    [2008-06-05 19:56:50] <cehteh> and i will group these classes so that some similar sizes fall in the same class
    [2008-06-05 19:57:19] <cehteh> that might waste some memory on disk at the end of each frame .. but that doesnt need to be mapped in
    [2008-06-05 19:57:32] <cehteh> the kernel will do that automatically for us
    [2008-06-05 19:57:37] <ichthyo> :)
    [2008-06-05 19:57:59] <cehteh> well mostly .. i need to whip it with the right hints ;)
    [2008-06-05 19:58:10] <ichthyo> :-o
    }}}

    /***
    ''InlineJavascriptPlugin for ~TiddlyWiki version 1.2.x and 2.0''
    ^^author: Eric Shulman - ELS Design Studios
    source: http://www.TiddlyTools.com/#InlineJavascriptPlugin
    license: [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]^^

    Insert Javascript executable code directly into your tiddler content. Lets you ''call directly into TW core utility routines, define new functions, calculate values, add dynamically-generated TiddlyWiki-formatted output'' into tiddler content, or perform any other programmatic actions each time the tiddler is rendered.
    !!!!!Usage
    <<<
    When installed, this plugin adds new wiki syntax for surrounding tiddler content with {{{<script>}}} and {{{</script>}}} markers, so that it can be treated as embedded javascript and executed each time the tiddler is rendered.

    ''Deferred execution from an 'onClick' link''
    By including a label="..." parameter in the initial {{{<script>}}} marker, the plugin will create a link to an 'onclick' script that will only be executed when that specific link is clicked, rather than running the script each time the tiddler is rendered.

    ''External script source files:''
    You can also load javascript from an external source URL, by including a src="..." parameter in the initial {{{<script>}}} marker (e.g., {{{<script src="demo.js"></script>}}}). This is particularly useful when incorporating third-party javascript libraries for use in custom extensions and plugins. The 'foreign' javascript code remains isolated in a separate file that can be easily replaced whenever an updated library file becomes available.

    ''Defining javascript functions and libraries:''
    Although the external javascript file is loaded while the tiddler content is being rendered, any functions it defines will not be available for use until //after// the rendering has been completed. Thus, you cannot load a library and //immediately// use it's functions within the same tiddler. However, once that tiddler has been loaded, the library functions can be freely used in any tiddler (even the one in which it was initially loaded).

    To ensure that your javascript functions are always available when needed, you should load the libraries from a tiddler that will be rendered as soon as your TiddlyWiki document is opened. For example, you could put your {{{<script src="..."></script>}}} syntax into a tiddler called LoadScripts, and then add {{{<<tiddler LoadScripts>>}}} in your MainMenu tiddler.

    Since the MainMenu is always rendered immediately upon opening your document, the library will always be loaded before any other tiddlers that rely upon the functions it defines. Loading an external javascript library does not produce any direct output in the tiddler, so these definitions should have no impact on the appearance of your MainMenu.

    ''Creating dynamic tiddler content''
    An important difference between this implementation of embedded scripting and conventional embedded javascript techniques for web pages is the method used to produce output that is dynamically inserted into the document:
    * In a typical web document, you use the document.write() function to output text sequences (often containing HTML tags) that are then rendered when the entire document is first loaded into the browser window.
    * However, in a ~TiddlyWiki document, tiddlers (and other DOM elements) are created, deleted, and rendered "on-the-fly", so writing directly to the global 'document' object does not produce the results you want (i.e., replacing the embedded script within the tiddler content), and completely replaces the entire ~TiddlyWiki document in your browser window.
    * To allow these scripts to work unmodified, the plugin automatically converts all occurences of document.write() so that the output is inserted into the tiddler content instead of replacing the entire ~TiddlyWiki document.

    If your script does not use document.write() to create dynamically embedded content within a tiddler, your javascript can, as an alternative, explicitly return a text value that the plugin can then pass through the wikify() rendering engine to insert into the tiddler display. For example, using {{{return "thistext"}}} will produce the same output as {{{document.write("thistext")}}}.

    //Note: your script code is automatically 'wrapped' inside a function, {{{_out()}}}, so that any return value you provide can be correctly handled by the plugin and inserted into the tiddler. To avoid unpredictable results (and possibly fatal execution errors), this function should never be redefined or called from ''within'' your script code.//

    ''Accessing the ~TiddlyWiki DOM''
    The plugin provides one pre-defined variable, 'place', that is passed in to your javascript code so that it can have direct access to the containing DOM element into which the tiddler output is currently being rendered.

    Access to this DOM element allows you to create scripts that can:
    * vary their actions based upon the specific location in which they are embedded
    * access 'tiddler-relative' information (use findContainingTiddler(place))
    * perform direct DOM manipulations (when returning wikified text is not enough)
    <<<
    !!!!!Examples
    <<<
    an "alert" message box:
    {{{
    <script>alert('InlineJavascriptPlugin: this is a demonstration message');</script>
    }}}
    <script>alert('InlineJavascriptPlugin: this is a demonstration message');</script>

    dynamic output:
    {{{
    <script>return (new Date()).toString();</script>
    }}}
    <script>return (new Date()).toString();</script>

    wikified dynamic output:
    {{{
    <script>return "link to current user: [["+config.options.txtUserName+"]]";</script>
    }}}
    <script>return "link to current user: [["+config.options.txtUserName+"]]";</script>

    dynamic output using 'place' to get size information for current tiddler
    {{{
    <script>
     if (!window.story) window.story=window;
     var title=story.findContainingTiddler(place).id.substr(7);
     return title+" is using "+store.getTiddlerText(title).length+" bytes";
    </script>
    }}}
    <script>
     if (!window.story) window.story=window;
     var title=story.findContainingTiddler(place).id.substr(7);
     return title+" is using "+store.getTiddlerText(title).length+" bytes";
    </script>

    creating an 'onclick' button/link that runs a script
    {{{
    <script label="click here">
     if (!window.story) window.story=window;
     alert("Hello World!\nlinktext='"+place.firstChild.data+"'\ntiddler='"+story.findContainingTiddler(place).id.substr(7)+"'");
    </script>
    }}}
    <script label="click here">
     if (!window.story) window.story=window;
     alert("Hello World!\nlinktext='"+place.firstChild.data+"'\ntiddler='"+story.findContainingTiddler(place).id.substr(7)+"'");
    </script>

    loading a script from a source url
    {{{
    <script src="demo.js">return "loading demo.js..."</script>
    <script label="click to execute demo() function">demo()</script>
    }}}
    where http://www.TiddlyTools.com/demo.js contains:
    >function demo() { alert('this output is from demo(), defined in demo.js') }
    >alert('InlineJavascriptPlugin: demo.js has been loaded');
    <script src="demo.js">return "loading demo.js..."</script>
    <script label="click to execute demo() function">demo()</script>
    <<<
    !!!!!Installation
    <<<
    import (or copy/paste) the following tiddlers into your document:
    ''InlineJavascriptPlugin'' (tagged with <<tag systemConfig>>)
    <<<
    !!!!!Revision History
    <<<
    ''2006.01.05 [1.4.0]''
    added support 'onclick' scripts. When label="..." param is present, a button/link is created using the indicated label text, and the script is only executed when the button/link is clicked. 'place' value is set to match the clicked button/link element.
    ''2005.12.13 [1.3.1]''
    when catching eval error in IE, e.description contains the error text, instead of e.toString(). Fixed error reporting so IE shows the correct response text. Based on a suggestion by UdoBorkowski
    ''2005.11.09 [1.3.0]''
    for 'inline' scripts (i.e., not scripts loaded with src="..."), automatically replace calls to 'document.write()' with 'place.innerHTML+=' so script output is directed into tiddler content
    Based on a suggestion by BradleyMeck
    ''2005.11.08 [1.2.0]''
    handle loading of javascript from an external URL via src="..." syntax
    ''2005.11.08 [1.1.0]''
    pass 'place' param into scripts to provide direct DOM access
    ''2005.11.08 [1.0.0]''
    initial release
    <<<
    !!!!!Credits
    <<<
    This feature was developed by EricShulman from [[ELS Design Studios|http:/www.elsdesign.com]]
    <<<
    !!!!!Code
    ***/
    //{{{
    version.extensions.inlineJavascript= {major: 1, minor: 4, revision: 0, date: new Date(2006,1,5)};

    config.formatters.push( {
     name: "inlineJavascript",
     match: "\\<script",
     lookahead: "\\<script(?: src=\\\"((?:.|\\n)*?)\\\")?(?: label=\\\"((?:.|\\n)*?)\\\")?\\>((?:.|\\n)*?)\\</script\\>",

     handler: function(w) {
     var lookaheadRegExp = new RegExp(this.lookahead,"mg");
     lookaheadRegExp.lastIndex = w.matchStart;
     var lookaheadMatch = lookaheadRegExp.exec(w.source)
     if(lookaheadMatch && lookaheadMatch.index == w.matchStart) {
     if (lookaheadMatch[1]) { // load a script library
     // make script tag, set src, add to body to execute, then remove for cleanup
     var script = document.createElement("script"); script.src = lookaheadMatch[1];
     document.body.appendChild(script); document.body.removeChild(script);
     }
     if (lookaheadMatch[2] && lookaheadMatch[3]) { // create a link to an 'onclick' script
     // add a link, define click handler, save code in link (pass 'place'), set link attributes
     var link=createTiddlyElement(w.output,"a",null,"tiddlyLinkExisting",lookaheadMatch[2]);
     link.onclick=function(){try{return(eval(this.code))}catch(e){alert(e.description?e.description:e.toString())}}
     link.code="function _out(place){"+lookaheadMatch[3]+"};_out(this);"
     link.setAttribute("href","javascript:;"); link.setAttribute("title",""); link.style.cursor="pointer";
     }
     else if (lookaheadMatch[3]) { // run inline script code
     var code="function _out(place){"+lookaheadMatch[3]+"};_out(w.output);"
     code=code.replace(/document.write\(/gi,'place.innerHTML+=(');
     try { var out = eval(code); } catch(e) { out = e.description?e.description:e.toString(); }
     if (out && out.length) wikify(out,w.output);
     }
     w.nextMatch = lookaheadMatch.index + lookaheadMatch[0].length;
     }
     }
    } )
    //}}}

    /***
    |''Name:''|InlineJavascriptPlugin|
    |''Source:''|http://www.TiddlyTools.com/#InlineJavascriptPlugin|
    |''Author:''|Eric Shulman - ELS Design Studios|
    |''License:''|[[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]|
    |''~CoreVersion:''|2.0.10|

    Insert Javascript executable code directly into your tiddler content. Lets you ''call directly into TW core utility routines, define new functions, calculate values, add dynamically-generated TiddlyWiki-formatted output'' into tiddler content, or perform any other programmatic actions each time the tiddler is rendered.
    !!!!!Usage
    <<<
    When installed, this plugin adds new wiki syntax for surrounding tiddler content with {{{<script>}}} and {{{</script>}}} markers, so that it can be treated as embedded javascript and executed each time the tiddler is rendered.

    ''Deferred execution from an 'onClick' link''
    By including a label="..." parameter in the initial {{{<script>}}} marker, the plugin will create a link to an 'onclick' script that will only be executed when that specific link is clicked, rather than running the script each time the tiddler is rendered.

    ''External script source files:''
    You can also load javascript from an external source URL, by including a src="..." parameter in the initial {{{<script>}}} marker (e.g., {{{<script src="demo.js"></script>}}}). This is particularly useful when incorporating third-party javascript libraries for use in custom extensions and plugins. The 'foreign' javascript code remains isolated in a separate file that can be easily replaced whenever an updated library file becomes available.

    ''Display script source in tiddler output''
    By including the keyword parameter "show", in the initial {{{<script>}}} marker, the plugin will include the script source code in the output that it displays in the tiddler.

    ''Defining javascript functions and libraries:''
    Although the external javascript file is loaded while the tiddler content is being rendered, any functions it defines will not be available for use until //after// the rendering has been completed. Thus, you cannot load a library and //immediately// use it's functions within the same tiddler. However, once that tiddler has been loaded, the library functions can be freely used in any tiddler (even the one in which it was initially loaded).

    To ensure that your javascript functions are always available when needed, you should load the libraries from a tiddler that will be rendered as soon as your TiddlyWiki document is opened. For example, you could put your {{{<script src="..."></script>}}} syntax into a tiddler called LoadScripts, and then add {{{<<tiddler LoadScripts>>}}} in your MainMenu tiddler.

    Since the MainMenu is always rendered immediately upon opening your document, the library will always be loaded before any other tiddlers that rely upon the functions it defines. Loading an external javascript library does not produce any direct output in the tiddler, so these definitions should have no impact on the appearance of your MainMenu.

    ''Creating dynamic tiddler content''
    An important difference between this implementation of embedded scripting and conventional embedded javascript techniques for web pages is the method used to produce output that is dynamically inserted into the document:
    * In a typical web document, you use the document.write() function to output text sequences (often containing HTML tags) that are then rendered when the entire document is first loaded into the browser window.
    * However, in a ~TiddlyWiki document, tiddlers (and other DOM elements) are created, deleted, and rendered "on-the-fly", so writing directly to the global 'document' object does not produce the results you want (i.e., replacing the embedded script within the tiddler content), and completely replaces the entire ~TiddlyWiki document in your browser window.
    * To allow these scripts to work unmodified, the plugin automatically converts all occurences of document.write() so that the output is inserted into the tiddler content instead of replacing the entire ~TiddlyWiki document.

    If your script does not use document.write() to create dynamically embedded content within a tiddler, your javascript can, as an alternative, explicitly return a text value that the plugin can then pass through the wikify() rendering engine to insert into the tiddler display. For example, using {{{return "thistext"}}} will produce the same output as {{{document.write("thistext")}}}.

    //Note: your script code is automatically 'wrapped' inside a function, {{{_out()}}}, so that any return value you provide can be correctly handled by the plugin and inserted into the tiddler. To avoid unpredictable results (and possibly fatal execution errors), this function should never be redefined or called from ''within'' your script code.//

    ''Accessing the ~TiddlyWiki DOM''
    The plugin provides one pre-defined variable, 'place', that is passed in to your javascript code so that it can have direct access to the containing DOM element into which the tiddler output is currently being rendered.

    Access to this DOM element allows you to create scripts that can:
    * vary their actions based upon the specific location in which they are embedded
    * access 'tiddler-relative' information (use findContainingTiddler(place))
    * perform direct DOM manipulations (when returning wikified text is not enough)
    <<<
    !!!!!Examples
    <<<
    an "alert" message box:
    ><script show>
     alert('InlineJavascriptPlugin: this is a demonstration message');
    </script>
    dynamic output:
    ><script show>
     return (new Date()).toString();
    </script>
    wikified dynamic output:
    ><script show>
     return "link to current user: [["+config.options.txtUserName+"]]";
    </script>
    dynamic output using 'place' to get size information for current tiddler:
    ><script show>
     if (!window.story) window.story=window;
     var title=story.findContainingTiddler(place).id.substr(7);
     return title+" is using "+store.getTiddlerText(title).length+" bytes";
    </script>
    creating an 'onclick' button/link that runs a script:
    ><script label="click here" show>
     if (!window.story) window.story=window;
     alert("Hello World!\nlinktext='"+place.firstChild.data+"'\ntiddler='"+story.findContainingTiddler(place).id.substr(7)+"'");
    </script>
    loading a script from a source url:
    >http://www.TiddlyTools.com/demo.js contains:
    >>{{{function demo() { alert('this output is from demo(), defined in demo.js') } }}}
    >>{{{alert('InlineJavascriptPlugin: demo.js has been loaded'); }}}
    ><script src="demo.js" show>
     return "loading demo.js..."
    </script>
    ><script label="click to execute demo() function" show>
     demo()
    </script>
    <<<
    !!!!!Installation
    <<<
    import (or copy/paste) the following tiddlers into your document:
    ''InlineJavascriptPlugin'' (tagged with <<tag systemConfig>>)
    <<<
    !!!!!Revision History
    <<<
    ''2006.06.01 [1.5.1]'' when calling wikify() on script return value, pass hightlightRegExp and tiddler params so macros that rely on these values can render properly
    ''2006.04.19 [1.5.0]'' added 'show' parameter to force display of javascript source code in tiddler output
    ''2006.01.05 [1.4.0]'' added support 'onclick' scripts. When label="..." param is present, a button/link is created using the indicated label text, and the script is only executed when the button/link is clicked. 'place' value is set to match the clicked button/link element.
    ''2005.12.13 [1.3.1]'' when catching eval error in IE, e.description contains the error text, instead of e.toString(). Fixed error reporting so IE shows the correct response text. Based on a suggestion by UdoBorkowski
    ''2005.11.09 [1.3.0]'' for 'inline' scripts (i.e., not scripts loaded with src="..."), automatically replace calls to 'document.write()' with 'place.innerHTML+=' so script output is directed into tiddler content. Based on a suggestion by BradleyMeck
    ''2005.11.08 [1.2.0]'' handle loading of javascript from an external URL via src="..." syntax
    ''2005.11.08 [1.1.0]'' pass 'place' param into scripts to provide direct DOM access
    ''2005.11.08 [1.0.0]'' initial release
    <<<
    !!!!!Credits
    <<<
    This feature was developed by EricShulman from [[ELS Design Studios|http:/www.elsdesign.com]]
    <<<
    !!!!!Code
    ***/
    //{{{
    version.extensions.inlineJavascript= {major: 1, minor: 5, revision: 1, date: new Date(2006,6,1)};

    config.formatters.push( {
     name: "inlineJavascript",
     match: "\\<script",
     lookahead: "\\<script(?: src=\\\"((?:.|\\n)*?)\\\")?(?: label=\\\"((?:.|\\n)*?)\\\")?( show)?\\>((?:.|\\n)*?)\\</script\\>",

     handler: function(w) {
     var lookaheadRegExp = new RegExp(this.lookahead,"mg");
     lookaheadRegExp.lastIndex = w.matchStart;
     var lookaheadMatch = lookaheadRegExp.exec(w.source)
     if(lookaheadMatch && lookaheadMatch.index == w.matchStart) {
     if (lookaheadMatch[1]) { // load a script library
     // make script tag, set src, add to body to execute, then remove for cleanup
     var script = document.createElement("script"); script.src = lookaheadMatch[1];
     document.body.appendChild(script); document.body.removeChild(script);
     }
     if (lookaheadMatch[4]) { // there is script code
     if (lookaheadMatch[3]) // show inline script code in tiddler output
     wikify("{{{\n"+lookaheadMatch[0]+"\n}}}\n",w.output);
     if (lookaheadMatch[2]) { // create a link to an 'onclick' script
     // add a link, define click handler, save code in link (pass 'place'), set link attributes
     var link=createTiddlyElement(w.output,"a",null,"tiddlyLinkExisting",lookaheadMatch[2]);
     link.onclick=function(){try{return(eval(this.code))}catch(e){alert(e.description?e.description:e.toString())}}
     link.code="function _out(place){"+lookaheadMatch[4]+"};_out(this);"
     link.setAttribute("href","javascript:;"); link.setAttribute("title",""); link.style.cursor="pointer";
     }
     else { // run inline script code
     var code="function _out(place){"+lookaheadMatch[4]+"};_out(w.output);"
     code=code.replace(/document.write\(/gi,'place.innerHTML+=(');
     try { var out = eval(code); } catch(e) { out = e.description?e.description:e.toString(); }
     if (out && out.length) wikify(out,w.output,w.highlightRegExp,w.tiddler);
     }
     }
     w.nextMatch = lookaheadMatch.index + lookaheadMatch[0].length;
     }
     }
    } )
    //}}}

    ! Lumiera design process
    A lightweight formalized process how people can add proposals for the Lumiera development.

    !! Description
    Use the Wiki at http://www.pipapo.org/pipawiki/Lumiera/DesignProcess to make it easy to add proposals in a well defined manner.

    I'd like to introduce a slightly formalized process for the ongoing Lumiera planning:
    * Every proposal is instantiated as 'Idea', the author gives other people the opportunity to review and comment on it with extreme prejudice, while still working out details.
    * When the the 'Idea' in a proper form 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.
    * At some point we may decide that a 'Draft' becomes a 'Final' (I leave it open how this decision shall be done for now). 'Final' Documents will be imported into the repository (this wiki, you are reading such a Document right now!).

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

    !!! Pros
    * simple
    * flexible
    * no much rules
    * persistent and at Final stage well documented process

    !!! Cons
    * could be abused/vandalized (but wiki can use ACL's)
    * depends on my server, this might be unfavorable or unreliable, ymmv.
    * will only work if all or almost all involved people agree on this process

    !!! Alternatives
    We could use some forum, Trac, Mailinglist or whatever instead.

    Just for Design documentation I would give [[Bouml|http://bouml.free.fr/]] a try. For myself, I am not very fond of UML Design tools, while Bouml looks quite promising and we could maintain the UML model in git repositories which would be more favorable than this centralized wiki. The backside is that this needs even more agreement between the developers, everyone has to install and use Bouml (and learn its usage) and design is constrained by a external tool.

    This distributed wiki might be used instead the pipapo.org wiki, investigate that for future.

    !! Rationale
    Wiki works. It is simple to use and just flexible enough to handle the task. I don't go to install any other software for such tasks on my server. While the design progresses I'd propose to move our work into git repositories and eventually phase this wiki pages out anyways. I'd rather like to start out distributed/git right away .. but git gives us only a fine storage layer, for a design process we need some good presentation layer (later when using git and starting the implementation everyones favorite editor serves for that) I have no better ideas yet to solve the presentation problem other than using this wiki (or maybe Bouml).

    [<img[draw/LumiLogo.png]]

      ''Lumiera'' is the emerging professional non linear video editor for Linux

    This is the entry point to several [[TiddlyWiki]]-Pages containing the developer and design documentation. The documentation is split in several parts corresponding to the parts of the application. Those TiddlyWiki pages are self modifying HTML pages; we include them into the GIT source tree. For the future we plan to move the contents of these developer doc wikis into a GIT backed uWiki (still under development as of 10/2008)
    * we maintain (semi-) final design docs in DesignDocumentation
    * Things get often worked out on IRC, see IRC-Transcripts for protocols, transcripts and decisions made there

    ----
    !Architecture and Subsystems
    &rarr; see the ArchitectureOverview

    * Cehteh works on the data backend, see [[this page|backend.html]]
    * Ichthyo focuses mainly on Edit operations and Builder, [[see this separate page|renderengine.html]]
    * Joel builds the Lumiera GUI based on GTK
    * Gmerlin is in charge of [[GAVL|http://gmerlin.sourceforge.net/gavl.html]] for processing of video data
    * Some tools which don't fit somewhere else and are used everywhere are put into a [[Support Library|support_library.html]]

    !Coding &mdash; Building &mdash; Testing
    how to organize several aspects of the practical coding...
    * what to do in BOUML?                          &rarr; [[more|whatInBOUML]]
    * how to organize packages, files, includes?    &rarr; [[more|SrcTreeStructure]]
    * how to organize the executable to be built?
    * what coding conventions to prefer?            &rarr; [[GNU Style|DesignDocumentation]]
    * what [[build system|BuildSystem]] to use?
    * various [[build dependencies|BuildDependenceis]]
    * we embrace __Test Driven Development__.       &rarr; Description of [[Test System|TestSh]] and TestSuite

    GettingStarted
    [[LumieraWiki]]
    [[Compatibility|compatibility.html]]
    [[ToDo|todo.html]]
    [[Backend|backend.html]]
    [[Proc-Layer|renderengine.html]]
    [[Support-Library|support_library.html]]
    [[Admin]]
    <<fullscreen>>

    ! Manifest
    This Proposal describe the general ideas how the community will work together to create Lumiera.

    !! Description
    I started with my personal opinions, so far people expressed their commitment with this text.

    !!! Background
    Cinelerra is quite an old project, there is an original version from heroinewarrior.com and a community fork at cinelerra.org. The original author claims that there was no-one producing usable input despite their proposes while cinelerra was in development, and indeed the cinelerra.org community only feeds back the source released by the original author into their SVN repository and maintains few fixes. There is not much development going on. Some people have created new functionality/features from time to time which have rarely been merged into the main repository and maintained by themselves.

    The Cinelerra community is a quite loose group of individuals, there is some fluctuation on the developer base and almost all developers have day jobs which restricts their involvement time on the cinelerra project.

    Some of these things work quite well, there is an overall friendly relation between the involved people. People who know C++ and have the time to edit the source have satisfactory added their own features. The Mailing-list and the IRC channel is also quite helpful and even new users who ask stupid questions are welcome.

    But there are some bad things too. Notably there is not much progress on the community development. Users don't benefit from new improvements which other people have made. There is a endlessly growing list of bugs and feature requests, when someone sends a patch to the ML he has to invest quite some time to maintain it until it might be merged. Finally we don't know what heroine virtual is working on, until we see his next tarball.

    !! Solution for "Cinelerra3" / Lumiera
    Cinelerra is heroine's product, this time we should work together with him to make it pleasant and progressing for anyone.
    We are in need of a new development model which is acceptable by all involved people and benefits from the way Cinelerra development worked the years before, without maintaining the bad sides again:

    # ''Make it easy to contribute''<<br>>Even if it is favorable when we have people which are continuously working on Lumiera / Cinelerra, it's a fact that people show up, send a few patches and then disappear. The development model should be prepared for this by:
    ## Good documentation
    ## Well defined design and interfaces
    ## Establish some coding guidelines to make it easy for others maintain code written by others
    ## Prefer known and simple approaches/coding over bleeding edge and highly complex techniques
    # ''Simple access''<<br>>We will use a fully distributed development model using git. I'll open a anonymous pushable repository which anyone can use to publish his changes.
    # ''Freedom to do, or not to do''<<br>>The model allows everyone to do as much as he wants. In a free project there is no way to put demands on people. This is good since it's easy to join and is open for anyone. The community might expect some responsibility for people maintaining their patches, but at worst, things which don't match our expected quality and when there is no one who keeps them up, will be removed. Since we are working in a distributed way with each developer maintaining his own repository and merging from other people, there is no easy way that bad code will leap into the project.
    # ''No Rule is better than a Rule which is not engaged''<<br>>We have to agree on some rules to make teamwork possible. These rules should be kept to a minimum required and accepted by all involved people. It is vital that we can trust each other on simple things, like properly formatted code or that patches one proposes to merge don't break the system etc..
    # ''Legal status must be clear''<<br>>Lumiera is developed under the GPL, every contributor must acknowledge this. Even when we provide anonymous commits, every non trivial patch should be traceable to the person who made it, GPG signatures would be proper here - details need to be worked out.
    # ''All for Lumiera''<<br>>The goal is to make the best Linux video editor to date, nothing less. Everyone puts in their best abilities. This project is not the place to blame people for things where they are not profound, help each other, make things right instead of blaming someone. Everyone should rate himself at what he can do best on the project.

    <!--{{{-->
    <link rel='alternate' type='application/rss+xml' title='RSS' href='index.xml'/>
    <!--}}}-->

    <style type="text/css">#contentWrapper {display:none;}</style><div id="SplashScreen" style="border: 3px solid #ccc; display: block; text-align: center; width: 320px; margin: 100px auto; padding: 50px; color:#000; font-size: 28px; font-family:Tahoma; background-color:#eee;"><b>Lumiera TiddlyWiki</b> is loading<blink> ...</blink><br><br><span style="font-size: 14px; color:red;">Requires Javascript.</span></div>

    I (cehteh) just paste my configs and give very few hints here, refer to the gpg manpage, the gpg documentation, google or ask on IRC for details. Maybe you improve this.

    First of all you need to install gpg and generate your keypair if you don't have done that already. generating keys is done with {{{gpg --gen-key}}} refer to the manpage for details.

    Be very careful that your private key has a **GOOD** passphrase and be kept secret.

    Configuration files are in {{{~/.gnupg}}}

    Here are the things I have in my {{{~/.gnupg/gpg.conf}}} (there are a lot of comments too, which I leave out here, instead I add some notes as comments)
    {{{
    no-greeting

    # enter your keyid AC4F4FF4 is mine!
    default-key AC4F4FF4

    force-v3-sigs

    compress-algo 1

    # you can add alternative keyservers
    keyserver hkp://subkeys.pgp.net
    #keyserver blackhole.pca.dfn.de

    # to let gpg automatically download public keys from the net, makes usage much easier
    keyserver-options auto-key-retrieve

    # using a gpg agent makes usage easier too, but you should only use it on a personal computer
    use-agent
    }}}

    when you want to use the gpg agent you need to add following line to your {{{~/.bash_profile}}} to start the agent on login:
    {{{
    eval $(gpg-agent --daemon)
    }}}

    further you need to add following lines to your {{{~/.bash_logout}}} to stop the agent when logging off:
    {{{
    if test "$GPG_AGENT_INFO"; then
            kill -TERM $(echo $GPG_AGENT_INFO | sed -s 's/.*:\(.*\):.*/\1/')
    fi
    }}}

    further the gpg agent needs some configuration in {{{~/.gnupg/gpg-agent.conf}}}:
    {{{
    pinentry-program /usr/bin/pinentry-gtk-2
    no-grab
    default-cache-ttl 1209600
    max-cache-ttl 1209600
    }}}

    Note that I am using very long timeouts, refer to the manual about its implications or leave the defaults.

    <!--{{{-->
    <div class='header' macro='gradient vert [[ColorPalette::PrimaryLight]] [[ColorPalette::PrimaryMid]]'>
    	<div class='headerShadow'>
    		<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>&nbsp;
    		<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
    	</div>
    	<div class='headerForeground'>
    		<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>&nbsp;
    		<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
    	</div>
    </div>
    <!-- horizontal MainMenu -->
    <div id='topMenu' refresh='content' tiddler='MainMenu'></div>
    <!-- original MainMenu menu -->
    <!-- <div id='mainMenu' refresh='content' tiddler='MainMenu'></div> -->
    <div id='sidebar'>
    	<div id='sidebarOptions' refresh='content' tiddler='SideBarOptions'></div>
    	<div id='sidebarTabs' refresh='content' force='true' tiddler='SideBarTabs'></div>
    </div>
    <div id='displayArea'>
    	<div id='messageArea'></div>
    	<div id='tiddlerDisplay'></div>
    </div>
    <!--}}}-->

    /***
    |<html><a name="Top"/></html>''Name:''|PartTiddlerPlugin|
    |''Version:''|1.0.6 (2006-11-07)|
    |''Source:''|http://tiddlywiki.abego-software.de/#PartTiddlerPlugin|
    |''Author:''|UdoBorkowski (ub [at] abego-software [dot] de)|
    |''Licence:''|[[BSD open source license]]|
    |''TiddlyWiki:''|2.0|
    |''Browser:''|Firefox 1.0.4+; InternetExplorer 6.0|
    !Table of Content<html><a name="TOC"/></html>
    * <html><a href="javascript:;" onclick="window.scrollAnchorVisible('Description',null, event)">Description, Syntax</a></html>
    * <html><a href="javascript:;" onclick="window.scrollAnchorVisible('Applications',null, event)">Applications</a></html>
    ** <html><a href="javascript:;" onclick="window.scrollAnchorVisible('LongTiddler',null, event)">Refering to Paragraphs of a Longer Tiddler</a></html>
    ** <html><a href="javascript:;" onclick="window.scrollAnchorVisible('Citation',null, event)">Citation Index</a></html>
    ** <html><a href="javascript:;" onclick="window.scrollAnchorVisible('TableCells',null, event)">Creating "multi-line" Table Cells</a></html>
    ** <html><a href="javascript:;" onclick="window.scrollAnchorVisible('Tabs',null, event)">Creating Tabs</a></html>
    ** <html><a href="javascript:;" onclick="window.scrollAnchorVisible('Sliders',null, event)">Using Sliders</a></html>
    * <html><a href="javascript:;" onclick="window.scrollAnchorVisible('Revisions',null, event)">Revision History</a></html>
    * <html><a href="javascript:;" onclick="window.scrollAnchorVisible('Code',null, event)">Code</a></html>
    !Description<html><a name="Description"/></html>
    With the {{{<part aPartName> ... </part>}}} feature you can structure your tiddler text into separate (named) parts.
    Each part can be referenced as a "normal" tiddler, using the "//tiddlerName//''/''//partName//" syntax (e.g. "About/Features"). E.g. you may create links to the parts, use it in {{{<<tiddler...>>}}} or {{{<<tabs...>>}}} macros etc.

    ''Syntax:''
    |>|''<part'' //partName// [''hidden''] ''>'' //any tiddler content// ''</part>''|
    |//partName//|The name of the part. You may reference a part tiddler with the combined tiddler name "//nameOfContainerTidder//''/''//partName//.|
    |''hidden''|When defined the content of the part is not displayed in the container tiddler. But when the part is explicitly referenced (e.g. in a {{{<<tiddler...>>}}} macro or in a link) the part's content is displayed.|
    |<html><i>any&nbsp;tiddler&nbsp;content</i></html>|<html>The content of the part.<br>A part can have any content that a "normal" tiddler may have, e.g. you may use all the formattings and macros defined.</html>|
    |>|~~Syntax formatting: Keywords in ''bold'', optional parts in [...]. 'or' means that exactly one of the two alternatives must exist.~~|
    <html><sub><a href="javascript:;" onclick="window.scrollAnchorVisible('Top',null, event)">[Top]</sub></a></html>

    !Applications<html><a name="Applications"/></html>
    !!Refering to Paragraphs of a Longer Tiddler<html><a name="LongTiddler"/></html>
    Assume you have written a long description in a tiddler and now you want to refer to the content of a certain paragraph in that tiddler (e.g. some definition.) Just wrap the text with a ''part'' block, give it a nice name, create a "pretty link" (like {{{[[Discussion Groups|Introduction/DiscussionGroups]]}}}) and you are done.

    Notice this complements the approach to first writing a lot of small tiddlers and combine these tiddlers to one larger tiddler in a second step (e.g. using the {{{<<tiddler...>>}}} macro). Using the ''part'' feature you can first write a "classic" (longer) text that can be read "from top to bottom" and later "reuse" parts of this text for some more "non-linear" reading.

    <html><sub><a href="javascript:;" onclick="window.scrollAnchorVisible('Top',null, event)">[Top]</sub></a></html>

    !!Citation Index<html><a name="Citation"/></html>
    Create a tiddler "Citations" that contains your "citations".
    Wrap every citation with a part and a proper name.

    ''Example''
    {{{
    <part BAX98>Baxter, Ira D. et al: //Clone Detection Using Abstract Syntax Trees.//
    in //Proc. ICSM//, 1998.</part>

    <part BEL02>Bellon, Stefan: //Vergleich von Techniken zur Erkennung duplizierten Quellcodes.//
    Thesis, Uni Stuttgart, 2002.</part>

    <part DUC99>Ducasse, Stéfane et al: //A Language Independent Approach for Detecting Duplicated Code.//
    in //Proc. ICSM//, 1999.</part>
    }}}

    You may now "cite" them just by using a pretty link like {{{[[Citations/BAX98]]}}} or even more pretty, like this {{{[[BAX98|Citations/BAX98]]}}}.

    <html><sub><a href="javascript:;" onclick="window.scrollAnchorVisible('Top',null, event)">[Top]</sub></a></html>

    !!Creating "multi-line" Table Cells<html><a name="TableCells"/></html>
    You may have noticed that it is hard to create table cells with "multi-line" content. E.g. if you want to create a bullet list inside a table cell you cannot just write the bullet list
    {{{
    * Item 1
    * Item 2
    * Item 3
    }}}
    into a table cell (i.e. between the | ... | bars) because every bullet item must start in a new line but all cells of a table row must be in one line.

    Using the ''part'' feature this problem can be solved. Just create a hidden part that contains the cells content and use a {{{<<tiddler >>}}} macro to include its content in the table's cell.

    ''Example''
    {{{
    |!Subject|!Items|
    |subject1|<<tiddler ./Cell1>>|
    |subject2|<<tiddler ./Cell2>>|

    <part Cell1 hidden>
    * Item 1
    * Item 2
    * Item 3
    </part>
    ...
    }}}

    Notice that inside the {{{<<tiddler ...>>}}} macro you may refer to the "current tiddler" using the ".".

    BTW: The same approach can be used to create bullet lists with items that contain more than one line.

    <html><sub><a href="javascript:;" onclick="window.scrollAnchorVisible('Top',null, event)">[Top]</sub></a></html>

    !!Creating Tabs<html><a name="Tabs"/></html>
    The build-in {{{<<tabs ...>>}}} macro requires that you defined an additional tiddler for every tab it displays. When you want to have "nested" tabs you need to define a tiddler for the "main tab" and one for every tab it contains. I.e. the definition of a set of tabs that is visually displayed at one place is distributed across multiple tiddlers.

    With the ''part'' feature you can put the complete definition in one tiddler, making it easier to keep an overview and maintain the tab sets.

    ''Example''
    The standard tabs at the sidebar are defined by the following eight tiddlers:
    * SideBarTabs
    * TabAll
    * TabMore
    * TabMoreMissing
    * TabMoreOrphans
    * TabMoreShadowed
    * TabTags
    * TabTimeline

    Instead of these eight tiddlers one could define the following SideBarTabs tiddler that uses the ''part'' feature:
    {{{
    <<tabs txtMainTab
     Timeline Timeline SideBarTabs/Timeline
     All 'All tiddlers' SideBarTabs/All
     Tags 'All tags' SideBarTabs/Tags
     More 'More lists' SideBarTabs/More>>
    <part Timeline hidden><<timeline>></part>
    <part All hidden><<list all>></part>
    <part Tags hidden><<allTags>></part>
    <part More hidden><<tabs txtMoreTab
     Missing 'Missing tiddlers' SideBarTabs/Missing
     Orphans 'Orphaned tiddlers' SideBarTabs/Orphans
     Shadowed 'Shadowed tiddlers' SideBarTabs/Shadowed>></part>
    <part Missing hidden><<list missing>></part>
    <part Orphans hidden><<list orphans>></part>
    <part Shadowed hidden><<list shadowed>></part>
    }}}

    Notice that you can easily "overwrite" individual parts in separate tiddlers that have the full name of the part.

    E.g. if you don't like the classic timeline tab but only want to see the 100 most recent tiddlers you could create a tiddler "~SideBarTabs/Timeline" with the following content:
    {{{
    <<forEachTiddler
     sortBy 'tiddler.modified' descending
     write '(index < 100) ? "* [["+tiddler.title+"]]\n":""'>>
    }}}
    <html><sub><a href="javascript:;" onclick="window.scrollAnchorVisible('Top',null, event)">[Top]</sub></a></html>

    !!Using Sliders<html><a name="Sliders"/></html>
    Very similar to the build-in {{{<<tabs ...>>}}} macro (see above) the {{{<<slider ...>>}}} macro requires that you defined an additional tiddler that holds the content "to be slid". You can avoid creating this extra tiddler by using the ''part'' feature

    ''Example''
    In a tiddler "About" we may use the slider to show some details that are documented in the tiddler's "Details" part.
    {{{
    ...
    <<slider chkAboutDetails About/Details details "Click here to see more details">>
    <part Details hidden>
    To give you a better overview ...
    </part>
    ...
    }}}

    Notice that putting the content of the slider into the slider's tiddler also has an extra benefit: When you decide you need to edit the content of the slider you can just doubleclick the content, the tiddler opens for editing and you can directly start editing the content (in the part section). In the "old" approach you would doubleclick the tiddler, see that the slider is using tiddler X, have to look for the tiddler X and can finally open it for editing. So using the ''part'' approach results in a much short workflow.

    <html><sub><a href="javascript:;" onclick="window.scrollAnchorVisible('Top',null, event)">[Top]</sub></a></html>

    !Revision history<html><a name="Revisions"/></html>
    * v1.0.6 (2006-11-07)
    ** Bugfix: cannot edit tiddler when UploadPlugin by Bidix is installed. Thanks to José Luis González Castro for reporting the bug.
    * v1.0.5 (2006-03-02)
    ** Bugfix: Example with multi-line table cells does not work in IE6. Thanks to Paulo Soares for reporting the bug.
    * v1.0.4 (2006-02-28)
    ** Bugfix: Shadow tiddlers cannot be edited (in TW 2.0.6). Thanks to Torsten Vanek for reporting the bug.
    * v1.0.3 (2006-02-26)
    ** Adapt code to newly introduced Tiddler.prototype.isReadOnly() function (in TW 2.0.6). Thanks to Paulo Soares for reporting the problem.
    * v1.0.2 (2006-02-05)
    ** Also allow other macros than the "tiddler" macro use the "." in the part reference (to refer to "this" tiddler)
    * v1.0.1 (2006-01-27)
    ** Added Table of Content for plugin documentation. Thanks to RichCarrillo for suggesting.
    ** Bugfix: newReminder plugin does not work when PartTiddler is installed. Thanks to PauloSoares for reporting.
    * v1.0.0 (2006-01-25)
    ** initial version
    <html><sub><a href="javascript:;" onclick="window.scrollAnchorVisible('Top',null, event)">[Top]</sub></a></html>

    !Code<html><a name="Code"/></html>
    <html><sub><a href="javascript:;" onclick="window.scrollAnchorVisible('Top',null, event)">[Top]</sub></a></html>
    ***/
    //{{{
    //============================================================================
    // PartTiddlerPlugin

    // Ensure that the PartTiddler Plugin is only installed once.
    //
    if (!version.extensions.PartTiddlerPlugin) {

    version.extensions.PartTiddlerPlugin = {
     major: 1, minor: 0, revision: 6,
     date: new Date(2006, 10, 7),
     type: 'plugin',
     source: "http://tiddlywiki.abego-software.de/#PartTiddlerPlugin"
    };

    if (!window.abego) window.abego = {};
    if (version.major < 2) alertAndThrow("PartTiddlerPlugin requires TiddlyWiki 2.0 or newer.");

    //============================================================================
    // Common Helpers

    // Looks for the next newline, starting at the index-th char of text.
    //
    // If there are only whitespaces between index and the newline
    // the index behind the newline is returned,
    // otherwise (or when no newline is found) index is returned.
    //
    var skipEmptyEndOfLine = function(text, index) {
     var re = /(\n|[^\s])/g;
     re.lastIndex = index;
     var result = re.exec(text);
     return (result && text.charAt(result.index) == '\n')
     ? result.index+1
     : index;
    }

    //============================================================================
    // Constants

    var partEndOrStartTagRE = /(<\/part>)|(<part(?:\s+)((?:[^>])+)>)/mg;
    var partEndTagREString = "<\\/part>";
    var partEndTagString = "</part>";

    //============================================================================
    // Plugin Specific Helpers

    // Parse the parameters inside a <part ...> tag and return the result.
    //
    // @return [may be null] {partName: ..., isHidden: ...}
    //
    var parseStartTagParams = function(paramText) {
     var params = paramText.readMacroParams();
     if (params.length == 0 || params[0].length == 0) return null;

     var name = params[0];
     var paramsIndex = 1;
     var hidden = false;
     if (paramsIndex < params.length) {
     hidden = params[paramsIndex] == "hidden";
     paramsIndex++;
     }

     return {
     partName: name,
     isHidden: hidden
     };
    }

    // Returns the match to the next (end or start) part tag in the text,
    // starting the search at startIndex.
    //
    // When no such tag is found null is returned, otherwise a "Match" is returned:
    // [0]: full match
    // [1]: matched "end" tag (or null when no end tag match)
    // [2]: matched "start" tag (or null when no start tag match)
    // [3]: content of start tag (or null if no start tag match)
    //
    var findNextPartEndOrStartTagMatch = function(text, startIndex) {
     var re = new RegExp(partEndOrStartTagRE);
     re.lastIndex = startIndex;
     var match = re.exec(text);
     return match;
    }

    //============================================================================
    // Formatter

    // Process the <part ...> ... </part> starting at (w.source, w.matchStart) for formatting.
    //
    // @return true if a complete part section (including the end tag) could be processed, false otherwise.
    //
    var handlePartSection = function(w) {
     var tagMatch = findNextPartEndOrStartTagMatch(w.source, w.matchStart);
     if (!tagMatch) return false;
     if (tagMatch.index != w.matchStart || !tagMatch[2]) return false;

     // Parse the start tag parameters
     var arguments = parseStartTagParams(tagMatch[3]);
     if (!arguments) return false;

     // Continue processing
     var startTagEndIndex = skipEmptyEndOfLine(w.source, tagMatch.index + tagMatch[0].length);
     var endMatch = findNextPartEndOrStartTagMatch(w.source, startTagEndIndex);
     if (endMatch && endMatch[1]) {
     if (!arguments.isHidden) {
     w.nextMatch = startTagEndIndex;
     w.subWikify(w.output,partEndTagREString);
     }
     w.nextMatch = skipEmptyEndOfLine(w.source, endMatch.index + endMatch[0].length);

     return true;
     }
     return false;
    }

    config.formatters.push( {
     name: "part",
     match: "<part\\s+[^>]+>",

     handler: function(w) {
     if (!handlePartSection(w)) {
     w.outputText(w.output,w.matchStart,w.matchStart+w.matchLength);
     }
     }
    } )

    //============================================================================
    // Extend "fetchTiddler" functionality to also recognize "part"s of tiddlers
    // as tiddlers.

    var currentParent = null; // used for the "." parent (e.g. in the "tiddler" macro)

    // Return the match to the first <part ...> tag of the text that has the
    // requrest partName.
    //
    // @return [may be null]
    //
    var findPartStartTagByName = function(text, partName) {
     var i = 0;

     while (true) {
     var tagMatch = findNextPartEndOrStartTagMatch(text, i);
     if (!tagMatch) return null;

     if (tagMatch[2]) {
     // Is start tag

     // Check the name
     var arguments = parseStartTagParams(tagMatch[3]);
     if (arguments && arguments.partName == partName) {
     return tagMatch;
     }
     }
     i += tagMatch[0].length;
     }
    }

    // Return the part "partName" of the given parentTiddler as a "readOnly" Tiddler
    // object, using fullName as the Tiddler's title.
    //
    // All remaining properties of the new Tiddler (tags etc.) are inherited from
    // the parentTiddler.
    //
    // @return [may be null]
    //
    var getPart = function(parentTiddler, partName, fullName) {
     var text = parentTiddler.text;
     var startTag = findPartStartTagByName(text, partName);
     if (!startTag) return null;

     var endIndexOfStartTag = skipEmptyEndOfLine(text, startTag.index+startTag[0].length);
     var indexOfEndTag = text.indexOf(partEndTagString, endIndexOfStartTag);

     if (indexOfEndTag >= 0) {
     var partTiddlerText = text.substring(endIndexOfStartTag,indexOfEndTag);
     var partTiddler = new Tiddler();
     partTiddler.set(
     fullName,
     partTiddlerText,
     parentTiddler.modifier,
     parentTiddler.modified,
     parentTiddler.tags,
     parentTiddler.created);
     partTiddler.abegoIsPartTiddler = true;
     return partTiddler;
     }

     return null;
    }

    // Hijack the store.fetchTiddler to recognize the "part" addresses.
    //

    var oldFetchTiddler = store.fetchTiddler ;
    store.fetchTiddler = function(title) {
     var result = oldFetchTiddler.apply(this, arguments);
     if (!result && title) {
     var i = title.lastIndexOf('/');
     if (i > 0) {
     var parentName = title.substring(0, i);
     var partName = title.substring(i+1);
     var parent = (parentName == ".")
     ? currentParent
     : oldFetchTiddler.apply(this, [parentName]);
     if (parent) {
     return getPart(parent, partName, parent.title+"/"+partName);
     }
     }
     }
     return result;
    };

    // The user must not edit a readOnly/partTiddler
    //

    config.commands.editTiddler.oldIsReadOnlyFunction = Tiddler.prototype.isReadOnly;

    Tiddler.prototype.isReadOnly = function() {
     // Tiddler.isReadOnly was introduced with TW 2.0.6.
     // For older version we explicitly check the global readOnly flag
     if (config.commands.editTiddler.oldIsReadOnlyFunction) {
     if (config.commands.editTiddler.oldIsReadOnlyFunction.apply(this, arguments)) return true;
     } else {
     if (readOnly) return true;
     }

     return this.abegoIsPartTiddler;
    }

    config.commands.editTiddler.handler = function(event,src,title)
    {
     var t = store.getTiddler(title);
     // Edit the tiddler if it either is not a tiddler (but a shadowTiddler)
     // or the tiddler is not readOnly
     if(!t || !t.abegoIsPartTiddler)
     {
     clearMessage();
     story.displayTiddler(null,title,DEFAULT_EDIT_TEMPLATE);
     story.focusTiddler(title,"text");
     return false;
     }
    }

    // To allow the "./partName" syntax in macros we need to hijack
    // the invokeMacro to define the "currentParent" while it is running.
    //
    var oldInvokeMacro = window.invokeMacro;
    function myInvokeMacro(place,macro,params,wikifier,tiddler) {
     var oldCurrentParent = currentParent;
     if (tiddler) currentParent = tiddler;
     try {
     oldInvokeMacro.apply(this, arguments);
     } finally {
     currentParent = oldCurrentParent;
     }
    }
    window.invokeMacro = myInvokeMacro;

    // Scroll the anchor anchorName in the viewer of the given tiddler visible.
    // When no tiddler is defined use the tiddler of the target given event is used.
    window.scrollAnchorVisible = function(anchorName, tiddler, evt) {
     var tiddlerElem = null;
     if (tiddler) {
     tiddlerElem = document.getElementById(story.idPrefix + tiddler);
     }
     if (!tiddlerElem && evt) {
     var target = resolveTarget(evt);
     tiddlerElem = story.findContainingTiddler(target);
     }
     if (!tiddlerElem) return;

     var children = tiddlerElem.getElementsByTagName("a");
     for (var i = 0; i < children.length; i++) {
     var child = children[i];
     var name = child.getAttribute("name");
     if (name == anchorName) {
     var y = findPosY(child);
     window.scrollTo(0,y);
     return;
     }
     }
    }

    } // of "install only once"
    //}}}

    /***
    <html><sub><a href="javascript:;" onclick="scrollAnchorVisible('Top',null, event)">[Top]</sub></a></html>

    !Licence and Copyright
    Copyright (c) abego Software ~GmbH, 2006 ([[www.abego-software.de|http://www.abego-software.de]])

    Redistribution and use in source and binary forms, with or without modification,
    are permitted provided that the following conditions are met:

    Redistributions of source code must retain the above copyright notice, this
    list of conditions and the following disclaimer.

    Redistributions in binary form must reproduce the above copyright notice, this
    list of conditions and the following disclaimer in the documentation and/or other
    materials provided with the distribution.

    Neither the name of abego Software nor the names of its contributors may be
    used to endorse or promote products derived from this software without specific
    prior written permission.

    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
    EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
    OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
    SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
    INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
    TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
    BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
    CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
    ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
    DAMAGE.

    <html><sub><a href="javascript:;" onclick="scrollAnchorVisible('Top',null, event)">[Top]</sub></a></html>
    ***/

    /***
    |''Name:''|RSSReaderPlugin|
    |''Description:''|This plugin provides a RSSReader for TiddlyWiki|
    |''Version:''|1.1.1|
    |''Date:''|Apr 21, 2007|
    |''Source:''|http://tiddlywiki.bidix.info/#RSSReaderPlugin|
    |''Documentation:''|http://tiddlywiki.bidix.info/#RSSReaderPluginDoc|
    |''Author:''|BidiX (BidiX (at) bidix (dot) info)|
    |''Credit:''|BramChen for RssNewsMacro|
    |''License:''|[[BSD open source license|http://tiddlywiki.bidix.info/#%5B%5BBSD%20open%20source%20license%5D%5D ]]|
    |''~CoreVersion:''|2.2.0|
    |''OptionalRequires:''|http://www.tiddlytools.com/#NestedSlidersPlugin|
    ***/
    //{{{
    version.extensions.RSSReaderPlugin = {
    	major: 1, minor: 1, revision: 1,
    	date: new Date("Apr 21, 2007"),
    	source: "http://TiddlyWiki.bidix.info/#RSSReaderPlugin",
    	author: "BidiX",
    	coreVersion: '2.2.0'
    };

    config.macros.rssReader = {
    	dateFormat: "DDD, DD MMM YYYY",
    	itemStyle: "display: block;border: 1px solid black;padding: 5px;margin: 5px;", //useed  '@@'+itemStyle+itemText+'@@'
    	msg:{
    		permissionDenied: "Permission to read preferences was denied.",
    		noRSSFeed: "No RSS Feed at this address %0",
    		urlNotAccessible: " Access to %0 is not allowed"
    	},
    	cache: [], 	// url => XMLHttpRequest.responseXML
    	desc: "noDesc",

    	handler: function(place,macroName,params,wikifier,paramString,tiddler) {
    		var desc = params[0];
    		var feedURL = params[1];
    		var toFilter = (params[2] ? true : false);
    		var filterString = (toFilter?(params[2].substr(0,1) == ' '? tiddler.title:params[2]):'');
    		var place = createTiddlyElement(place, "div", "RSSReader");
    		wikify("^^<<rssFeedUpdate "+feedURL+" [[" + tiddler.title + "]]>>^^\n",place);
    		if (this.cache[feedURL]) {
    			this.displayRssFeed(this.cache[feedURL], feedURL, place, desc, toFilter, filterString);
    		}
    		else {
    			var r = loadRemoteFile(feedURL,config.macros.rssReader.processResponse, [place, desc, toFilter, filterString]);
    			if (typeof r == "string")
    				displayMessage(r);
    		}

    	},

    	// callback for loadRemoteFile
    	// params : [place, desc, toFilter, filterString]
    	processResponse: function(status, params, responseText, url, xhr) { // feedURL, place, desc, toFilter, filterString) {
    		if (window.netscape){
    			try {
    				if (document.location.protocol.indexOf("http") == -1) {
    					netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead");
    				}
    			}
    			catch (e) { displayMessage(e.description?e.description:e.toString()); }
    		}
    		if (xhr.status == httpStatus.NotFound)
    		 {
    			displayMessage(config.macros.rssReader.noRSSFeed.format([url]));
    			return;
    		}
    		if (!status)
    		 {
    			displayMessage(config.macros.rssReader.noRSSFeed.format([url]));
    			return;
    		}
    		if (xhr.responseXML) {
    			// response is interpreted as XML
    			config.macros.rssReader.cache[url] = xhr.responseXML;
    			config.macros.rssReader.displayRssFeed(xhr.responseXML, params[0], url, params[1], params[2], params[3]);
    		}
    		else {
    			if (responseText.substr(0,5) == "<?xml") {
    				// response exists but not return as XML -> try to parse it
    				var dom = (new DOMParser()).parseFromString(responseText, "text/xml");
    				if (dom) {
    					// parsing successful so use it
    					config.macros.rssReader.cache[url] = dom;
    					config.macros.rssReader.displayRssFeed(dom, params[0], url, params[1], params[2], params[3]);
    					return;
    				}
    			}
    			// no XML display as html
    			wikify("<html>" + responseText + "</html>", params[0]);
    			displayMessage(config.macros.rssReader.msg.noRSSFeed.format([url]));
    		}
    	},

    	// explore down the DOM tree
    	displayRssFeed: function(xml, place, feedURL, desc, toFilter, filterString){
    		// Channel
    		var chanelNode = xml.getElementsByTagName('channel').item(0);
    		var chanelTitleElement = (chanelNode ? chanelNode.getElementsByTagName('title').item(0) : null);
    		var chanelTitle = "";
    		if ((chanelTitleElement) && (chanelTitleElement.firstChild))
    			chanelTitle = chanelTitleElement.firstChild.nodeValue;
    		var chanelLinkElement = (chanelNode ? chanelNode.getElementsByTagName('link').item(0) : null);
    		var chanelLink = "";
    		if (chanelLinkElement)
    			chanelLink = chanelLinkElement.firstChild.nodeValue;
    		var titleTxt = "!![["+chanelTitle+"|"+chanelLink+"]]\n";
    		var title = createTiddlyElement(place,"div",null,"ChanelTitle",null);
    		wikify(titleTxt,title);
    		// ItemList
    		var itemList = xml.getElementsByTagName('item');
    		var article = createTiddlyElement(place,"ul",null,null,null);
    		var lastDate;
    		var re;
    		if (toFilter)
    			re = new RegExp(filterString.escapeRegExp());
    		for (var i=0; i<itemList.length; i++){
    			var titleElm = itemList[i].getElementsByTagName('title').item(0);
    			var titleText = (titleElm ? titleElm.firstChild.nodeValue : '');
    			if (toFilter && ! titleText.match(re)) {
    				continue;
    			}
    			var descText = '';
    			descElem = itemList[i].getElementsByTagName('description').item(0);
    			if (descElem){
    				try{
    					for (var ii=0; ii<descElem.childNodes.length; ii++) {
    						descText += descElem.childNodes[ii].nodeValue;
    					}
    				}
    				catch(e){}
    				descText = descText.replace(/<br \/>/g,'\n');
    				if (desc == "asHtml")
    					descText = "<html>"+descText+"</html>";
    			}
    			var linkElm = itemList[i].getElementsByTagName("link").item(0);
    			var linkURL = linkElm.firstChild.nodeValue;
    			var pubElm = itemList[i].getElementsByTagName('pubDate').item(0);
    			var pubDate;
    			if (!pubElm) {
    				pubElm = itemList[i].getElementsByTagName('date').item(0); // for del.icio.us
    				if (pubElm) {
    					pubDate = pubElm.firstChild.nodeValue;
    					pubDate = this.formatDateString(this.dateFormat, pubDate);
    					}
    					else {
    						pubDate = '0';
    					}
    				}
    			else {
    				pubDate = (pubElm ? pubElm.firstChild.nodeValue : 0);
    				pubDate = this.formatDate(this.dateFormat, pubDate);
    			}
    			titleText = titleText.replace(/\[|\]/g,'');
    			var rssText = '*'+'[[' + titleText + '|' + linkURL + ']]' + '' ;
    			if ((desc != "noDesc") && descText){
    				rssText = rssText.replace(/\n/g,' ');
    				descText = '@@'+this.itemStyle+descText + '@@\n';
    				if (version.extensions.nestedSliders){
    					descText = '+++[...]' + descText + '===';
    				}
    				rssText = rssText + descText;
    			}
    			var story;
    			if ((lastDate != pubDate) && ( pubDate != '0')) {
    				story = createTiddlyElement(article,"li",null,"RSSItem",pubDate);
    				lastDate = pubDate;
    			}
    			else {
    				lastDate = pubDate;
    			}
    			story = createTiddlyElement(article,"div",null,"RSSItem",null);
    			wikify(rssText,story);
    		}
    	},

    	formatDate: function(template, date){
    		var dateString = new Date(date);
    		// template = template.replace(/hh|mm|ss/g,'');
    		return dateString.formatString(template);
    	},

    	formatDateString: function(template, date){
    		var dateString = new Date(date.substr(0,4), date.substr(5,2) - 1, date.substr(8,2)
    			);
    		return dateString.formatString(template);
    	}

    };

    config.macros.rssFeedUpdate = {
    	label: "Update",
    	prompt: "Clear the cache and redisplay this RssFeed",
    	handler: function(place,macroName,params) {
    		var feedURL = params[0];
    		var tiddlerTitle = params[1];
    		createTiddlyButton(place, this.label, this.prompt,
    			function () {
    				if (config.macros.rssReader.cache[feedURL]) {
    					config.macros.rssReader.cache[feedURL] = null;
    			}
    			story.refreshTiddler(tiddlerTitle,null, true);
    		return false;});
    	}
    };

    //}}}

    //last update: RSSReaderPlugin v 1.1.1//

    !Description
    This plugin provides a RSSReader for TiddlyWiki
    * It accesses asynchronously an RSSFeed
    *Depending on the chanel item format, each item could be written as :
    **simple text wikified
    **html

    !Usage
    {{{
    <<rssReader noDesc|asHtml|asText rssUrl ['filtering string']>>
    	noDesc: only title of item is printed

    	asHtml: if you know that description contain html (links, img ...),
    		the text is enclosed with <html> </html> tags

     	asText: if the description should not be interpreted as html the
    		description is wikified

    	rssUrl: the rssFeed url that could be accessed.

    	'filtering string': if present, the rssfeed item title must contained
    		this string to be displayed.
    		If 'filering string' contained space characters only, the tiddler
    		title is used for filtering.

    }}}

    For security reasons, if the TiddlyWiki is accessed from http, a ProxyService should be used to access an rssFeed from an other site.

    !examples
    | !reader | !RSSFeed type | !working from |
    | BidiXTWRSS | Description asHtml | file: or tiddlywiki.bidix.info |
    | [[Le Monde]] | Description asText | file: or tiddlywiki.bidix.info using proxy |
    | YahooNewsSport | Description asHtml | file: or tiddlywiki.bidix.info using proxy |
    | TiddlyWikiRSS | Description asHtml | file: or tiddlywiki.bidix.info using proxy |
    | [[Libération]] | noDesc | file: or tiddlywiki.bidix.info using proxy |
    | [[TestComment]] | asText and filters | file: or tiddlywiki.bidix.info using proxy |
    see : <<tag RSSFeed>> for the full list.

    !Revision history
    * V1.1.0 (2207/04/13)
    **No more import functions
    * V1.0.0 (2006/11/11)
    **refactoring using core loadRemoteFile function
    **import using new tiddlywiki:tiddler element
    **import and presentation preserved without EricShulman's NestedSliderPlugin
    **better display of items
    * v0.3.0 (24/08/2006)
    ** Filter on RSS item title
    ** Place to display redefined for asynchronous processing
    * v0.2.2 (22/08/2006)
    **Haloscan feed has no pubDate.
    * v0.2.1 (08/05/2006)
    * v0.2.0 (01/05/2006)
    **Small adapations for del.icio.us feed
    * v0.1.1 (28/04/2006)
    **Bug : Channel without title
    * v0.1.0 (24/04/2006)
    ** initial release

    ||'''State'''||''Final''||
    ||'''Date'''||[[Date(2007-06-09T00:48:02Z)]]||
    ||'''Proposed by'''||["ct"]||

    ! Repository Setup
    Here we describe the Directory hierarchy and how the git repository are set up.

    !! Description
    Use "./admin/treeinfo.sh" to produce a annotated directory tree like this:
    {{{
    .                                       : The root dir for the Lumiera project
    ./admin                                 : administrative scripts
    ./admin/git_hooks                       : git hook scripts
    ./build                                 : build dir
    ./doc                                   : documentation
    ./doc/devel                             : developer documentation, extra sources, doxygen
    ./doc/devel/uml                         : Bouml generated HTML doc
    ./doc/user                              : user documentation in texinfo
    ./oldsrc                                : Cinelerra2 sources, added per case when needed
    ./src                                   : every components source in a own subdir here
    ./tests                                 : test suite
    ./tests/bugs                            : tests against reported bugs
    ./uml                                   : uml models, created with bouml
    ./uml/lumiera                           : Lumiera UML model
    ./wiki                                  : tiddlywiki for semi-persistent documentation
    }}}

    !! New Directories:

    When you need to add a new mariginally important directory please provides a file named DIR_INFO within this directory. It's first line should note the purpose of the directory in a few words (less than 40 characters). The following lines are free form description about the details.

    !! Submodules:

    We want to use the new GIT feature of "Superprojects and Submodules" when it is ready for general use.
    Then we will transform several subtrees into separate GIT repos which will be linked to from the main
    Project (then called the "Superproject") as submodules.

    !!! Pros
    * because its a text-like structure, it is partially self-documenting
    * GIT is flexible and with the planned submodules it can be separated in chunks of manageable size if necessary

    !!! Cons
    * can get large and confusing
    * has no real "portal" or entrance point for people wanting to join

    !!Rationale
    Every important document, draft, text and code (including) prototypes should be checked into
    one SCM (or a set of related SCMs). This repo should be "almost everything" you need for the
    project. Because we try to use a distributed development model, every dev can/should have
    his own copy and fed his changes back.

    This ''Repository approach'' avoids the problems of a central infrastructure and helps cut down
    project management time. Basically, every dev is responsible himself for getting every important
    piece of information added into "the general view of matters" in a consistent way.

    ! Conclusion
    ## When approbate (this proposal becomes a Final) write some conclusions about its process:

    ! Comments
    Basically the structure is just fine.
    * maybe add a "pastebin" somewhere in the dev-documentation area?
    * i would add the source tree roots at level 2, so we can have several submodules here:
    ** oldsrc
    ** cin3
    ** prototype
     -- ["Ichthyostega"] [[DateTime(2007-06-16T23:10:01Z)]]

    Draft now.

    Yes I left source dirs out but this sounds fine, note that with git, there is no problem to reorganize the repo (in contrast to CVS) later. We can fix things afterward when we find better ways.
     -- ["ct"] [[DateTime(2007-06-17T17:36:46Z)]]

    Whats prototype for? won't that be better a branch?
     -- ["ct"] [[DateTime(2007-06-17T22:04:39Z)]]

    I just wanted to show there could be additional things beside the main tree (later to be separate submodules). The example was meant as a classical
    throwaway prototype. But I agree, in our case we just start hacking at the new tree and make feature/tryout/prototype branches...

    The point I wanted to make is: every directory 2 levels deep in the source tree, e.g. /src/cinelerra3 or /src/oldsrource should be a completely
    self-contained tree which can be built without needing anything of the rest of the repo. Thats an prerequisite for moving to Submodules IMHO.
    But you seem rather to put the sourcetree-roots 1 level deep. As we have just two trees at the moment (and can easily reorganize), I have no
    objections against this. The only point I really care is to try to keep the source tree self-contained without any dependencies to the rest
    of the "design GIT" (because of this Superprojects-Submodules thing...)
     -- ["Ichthyostega"] [[DateTime(2007-06-17T23:45:06Z)]]

    we could make the trees deeper than one level, I didn't intended 1-level depth. but also be careful with that not to make it too complex. While I am not sure if we want a complete oldsrc, that just adds weight and confusion for now (lets see). Neither I am fully decided about the hierarchy in /src (want /libs /plugins or /src/libs /src/plugins or /src/render/plugins? name it rather 'effects' than 'plugins'?). While I am quite sure that I want to separate /oldssrc and /src quite much (in /src should only be new stuff or stuff which is carefully reviewed, with know license and author).
     -- ["ct"] [[DateTime(2007-06-18T08:38:43Z)]]

    I made this proposal 'final' now further details are likely better worked out in the git repository (and we already started to define things there) see ./admin/treeinfo.sh
     -- ["ct"] [[DateTime(2007-06-27T16:01:52Z)]]

    [SCons|http://www.scons.org/] is an //alternate build system// written in Python and using specific python-scripts for defining the buildprocess. These build scripts, called {{{SConstruct}}} and {{{SConsscript}}} are indeed //definitions//, not scripts for //doing// the build. If you are new to SCons (and familiar with make), you should really read the [Introduction of the users guide|http://www.scons.org/doc/0.97/HTML/scons-user/book1.html], because SCons is quite a different beast then make and the autotools.

    To learn how to use SCons and to get a better feeling of its strenghtes and weaknesses, Ichthyo started a SCons based build system for Lumiera in July 2007 and will maintain it for some time parallel to the automake system (maintained by Cehteh). Every build system looks good in theory and has some big advantages, but only in real use one can see how much effort is needed to keep up with the demands of a given project.

    !some Notes
    * we build always in the top level directory
    * at the moment, we use no separate build directory, rather we place the object files alongside with the sources
    * but we place the created executables and shared libraries into one $BINDIR (configurable in the top level {{{SConstruct}}})
    * note: for SCons, each file (which is buildable) and each directory (containing buildable files) is on itself a Target.
    * additionally, we provide some //aliasses//
    ** build == $BINDIR
    ** install places some of the created artifacts into $DESTDIR
    ** testcode is an alias for all the executables comprising the testsuite
    ** check == directory {{{tests}}} and runs the testsuite
    * run scons -h to get additional explanations.

    Typically, one would just write the necessary definitions as they come into one global scope. But because the buildscripts are actually Python scripts, ichthyo found it preferable to use some more structuring and break down the code into several python functions and pass all necessary variables as parameters. This may seem overkill at first look, but the Lumiera project is expected to become a large project.

    Moreover, one could simply list all needed files or break everything down into a hierarchical build. But instead, we use for most objects a helper function (located in {{{admin/scons/Buildhelper.py}}}) called {{{srcSubtree()}}}, which will scan a directory tree and add all {{{'*.c','*.cpp','*.cc'}}} - files as Object nodes to the build process. Besides that, we use the //hierarchical aproach rather reluctant//: at the moment, only the subtree for separate tools and the tests-directory have a separate buildscript. Probably, the subtree for plugins will get one as well at some point in the future.

    ~~This small Tiddler contains usefull Shortcuts, Info, Links~~

    *[[Wiki-Markup|http://tiddlywiki.org/wiki/TiddlyWiki_Markup]]
    *[[Design-Process|http://www.pipapo.org/pipawiki/Lumiera/DesignProcess]]
    *
    ----

    <<search>><<closeAll>><<permaview>><<newTiddler>><<saveChanges>><<slider chkSliderOptionsPanel OptionsPanel "options »" "Change TiddlyWiki advanced options">>

    Distributed Developer Wiki

    Lumiera

    /***

    ''Inspired by [[TiddlyPom|http://www.warwick.ac.uk/~tuspam/tiddlypom.html]]''

    |Name|SplashScreenPlugin|
    |Created by|SaqImtiaz|
    |Location|http://tw.lewcid.org/#SplashScreenPlugin|
    |Version|0.21 |
    |Requires|~TW2.08+|
    !Description:
    Provides a simple splash screen that is visible while the TW is loading.

    !Installation
    Copy the source text of this tiddler to your TW in a new tiddler, tag it with systemConfig and save and reload. The SplashScreen will now be installed and will be visible the next time you reload your TW.

    !Customizing
    Once the SplashScreen has been installed and you have reloaded your TW, the splash screen html will be present in the MarkupPreHead tiddler. You can edit it and customize to your needs.

    !History
    * 20-07-06 : version 0.21, modified to hide contentWrapper while SplashScreen is displayed.
    * 26-06-06 : version 0.2, first release

    !Code
    ***/
    //{{{
    var old_lewcid_splash_restart=restart;

    restart = function()
    {   if (document.getElementById("SplashScreen"))
            document.getElementById("SplashScreen").style.display = "none";
          if (document.getElementById("contentWrapper"))
            document.getElementById("contentWrapper").style.display = "block";

        old_lewcid_splash_restart();

        if (splashScreenInstall)
           {if(config.options.chkAutoSave)
    			{saveChanges();}
            displayMessage("TW SplashScreen has been installed, please save and refresh your TW.");
            }
    }

    var oldText = store.getTiddlerText("MarkupPreHead");
    if (oldText.indexOf("SplashScreen")==-1)
       {var siteTitle = store.getTiddlerText("SiteTitle");
       var splasher='\n\n<style type="text/css">#contentWrapper {display:none;}</style><div id="SplashScreen" style="border: 3px solid #ccc; display: block; text-align: center; width: 320px; margin: 100px auto; padding: 50px; color:#000; font-size: 28px; font-family:Tahoma; background-color:#eee;"><b>'+siteTitle +'</b> is loading<blink> ...</blink><br><br><span style="font-size: 14px; color:red;">Requires Javascript.</span></div>';
       if (! store.tiddlerExists("MarkupPreHead"))
           {var myTiddler = store.createTiddler("MarkupPreHead");}
       else
          {var myTiddler = store.getTiddler("MarkupPreHead");}
          myTiddler.set(myTiddler.title,oldText+splasher,config.options.txtUserName,null,null);
          store.setDirty(true);
          var splashScreenInstall = true;
    }
    //}}}

    * add a ''~DIR_INFO'' file to each marginally important directory. The first line should give a short abstract about this dir (40 characters, not more), following lines can give more precise information. There is a 'admin/treeinfo.sh' script which generates a texual overview of the directory tree.

    /*{{{*/
    /* a contrasting background so I can see where one tiddler ends and the other begins */
    body {
    	background: [[ColorPalette::TertiaryLight]];
    }

    /* sexy colours and font for the header */
    .headerForeground {
    	color: [[ColorPalette::PrimaryPale]];
    }
    .headerShadow, .headerShadow a {
    	color: [[ColorPalette::PrimaryMid]];
    }
    .headerForeground, .headerShadow {
    	padding: 1em 1em 0;
    	font-family: 'Trebuchet MS' sans-serif;
    	font-weight:bold;
    }
    .headerForeground .siteSubtitle {
    	color: [[ColorPalette::PrimaryLight]];
    }
    .headerShadow .siteSubtitle {
    	color: [[ColorPalette::PrimaryMid]];
    }

    /* make shadow go and down right instead of up and left */
    .headerShadow {
    	left: 2px;
    	top: 3px;
    }

    /* prefer monospace for editing */
    .editor textarea {
    	font-family: 'Consolas' monospace;
    }

    /* sexy tiddler titles */
    .title {
    	font-size: 250%;
    	color: [[ColorPalette::PrimaryLight]];
    	font-family: 'Trebuchet MS' sans-serif;
    }

    /* more subtle tiddler subtitle */
    .subtitle {
    	padding:0px;
    	margin:0px;
    	padding-left:0.5em;
    	font-size: 90%;
    	color: [[ColorPalette::TertiaryMid]];
    }
    .subtitle .tiddlyLink {
    	color: [[ColorPalette::TertiaryMid]];
    }

    /* a little bit of extra whitespace */
    .viewer {
    	padding-bottom:3px;
    }

    /* don't want any background color for headings */
    h1,h2,h3,h4,h5,h6 {
    	background: [[ColorPalette::Background]];
    	color: [[ColorPalette::Foreground]];
    }

    /* give tiddlers 3d style border and explicit background */
    .tiddler {
    	background: [[ColorPalette::Background]];
    	border-right: 2px [[ColorPalette::TertiaryMid]] solid;
    	border-bottom: 2px [[ColorPalette::TertiaryMid]] solid;
    	margin-bottom: 1em;
    	padding-bottom: 2em;
    }

    /* make options slider look nicer */
    #sidebarOptions .sliderPanel {
    	border:solid 1px [[ColorPalette::PrimaryLight]];
    }

    /* the borders look wrong with the body background */
    #sidebar .button {
    	border-style: none;
    }

    /* displays the list of a tiddler's tags horizontally. used in ViewTemplate */
    .tagglyTagged li.listTitle {
    	display:none
    }
    .tagglyTagged li {
    	display: inline; font-size:90%;
    }
    .tagglyTagged ul {
    	margin:0px; padding:0px;
    }

    /* this means you can put line breaks in SidebarOptions for readability */
    #sidebarOptions br {
    	display:none;
    }
    /* undo the above in OptionsPanel */
    #sidebarOptions .sliderPanel br {
    	display:inline;
    }

    /* horizontal main menu stuff */
    #displayArea {
    	margin: 1em 15.7em 0em 1em; /* use the freed up space */
    }
    #topMenu br {
    	display: none;
    }
    #topMenu {
    	background: [[ColorPalette::PrimaryMid]];
    	color:[[ColorPalette::PrimaryPale]];
    }
    #topMenu {
    	padding:2px;
    }
    #topMenu .button, #topMenu .tiddlyLink, #topMenu a {
    	margin-left: 0.5em;
    	margin-right: 0.5em;
    	padding-left: 3px;
    	padding-right: 3px;
    	color: [[ColorPalette::PrimaryPale]];
    	font-size: 115%;
    }
    #topMenu .button:hover, #topMenu .tiddlyLink:hover {
    	background: [[ColorPalette::PrimaryDark]];
    }

    /* make it print a little cleaner */
    @media print {
    	#topMenu {
    		display: none ! important;
    	}
    	/* not sure if we need all the importants */
    	.tiddler {
    		border-style: none ! important;
    		margin:0px ! important;
    		padding:0px ! important;
    		padding-bottom:2em ! important;
    	}
    	.tagglyTagging .button, .tagglyTagging .hidebutton {
    		display: none ! important;
    	}
    	.headerShadow {
    		visibility: hidden ! important;
    	}
    	.tagglyTagged .quickopentag, .tagged .quickopentag {
    		border-style: none ! important;
    	}
    	.quickopentag a.button, .miniTag {
    		display: none ! important;
    	}
    }
    /*}}}*/

    <<timeline better:true maxDays:14 maxEntries:20>>

    /***
    |Name|TaskMacroPlugin|
    |Author|<<extension TaskMacroPlugin author>>|
    |Location|<<extension TaskMacroPlugin source>>|
    |License|<<extension TaskMacroPlugin license>>|
    |Version|<<extension TaskMacroPlugin versionAndDate>>|
    !Description
    A set of macros to help you keep track of time estimates for tasks.

    Macros defined:
    * {{{task}}}: Displays a task description and makes it easy to estimate and track the time spent on the task.
    * {{{taskadder}}}: Displays text entry field to simplify the adding of tasks.
    * {{{tasksum}}}: Displays a summary of tasks sandwiched between two calls to this macro.
    * {{{extension}}}: A simple little macro that displays information about a TiddlyWiki plugin, and that will hopefully someday migrate to the TW core in some form.
    Core overrides:
    * {{{wikify}}}: when wikifying a tiddler's complete text, adds refresh information so the tiddler will be refreshed when it changes
    * {{{config.refreshers}}}: have the built-in refreshers return true; also, add a new refresher ("fullContent") that redisplays a full tiddler whenever it or any nested tiddlers it shows are changed
    * {{{refreshElements}}}: now checks the return value from the refresher and only short-circuits the recursion if the refresher returns true
    !Plugin Information
    ***/
    //{{{
    version.extensions.TaskMacroPlugin = {
    	major: 1, minor: 1, revision: 0,
    	date: new Date(2006,5-1,13),
    	author: "LukeBlanshard",
    	source: "http://labwiki.sourceforge.net/#TaskMacroPlugin",
    	license: "http://labwiki.sourceforge.net/#CopyrightAndLicense"
    }
    //}}}
    /***
    A little macro for pulling out extension info.  Use like {{{<<extension PluginName datum>>}}}, where {{{PluginName}}} is the name you used for {{{version.extensions}}} and {{{datum}}} is either {{{versionAndDate}}} or a property of the extension description object, such as {{{source}}}.
    ***/
    //{{{
    config.macros.extension = {
    	handler: function( place, macroName, params, wikifier, paramString, tiddler ) {
    		var info  = version.extensions[params[0]]
    		var datum = params[1]
    		switch (params[1]) {
    		case 'versionAndDate':
    			createTiddlyElement( place, "span", null, null,
    				info.major+'.'+info.minor+'.'+info.revision+', '+info.date.formatString('DD MMM YYYY') )
    			break;
    		default:
    			wikify( info[datum], place )
    			break;
    		}
    	}
    }
    //}}}
    /***
    !Core Overrides
    ***/
    //{{{
    window.wikify_orig_TaskMacroPlugin = window.wikify
    window.wikify = function(source,output,highlightRegExp,tiddler)
    {
    	if ( tiddler && tiddler.text === source )
    		addDisplayDependency( output, tiddler.title )
    	wikify_orig_TaskMacroPlugin.apply( this, arguments )
    }
    config.refreshers_orig_TaskMacroPlugin = config.refreshers
    config.refreshers = {
    	link: function() {
    		config.refreshers_orig_TaskMacroPlugin.link.apply( this, arguments )
    		return true
    	},
    	content: function() {
    		config.refreshers_orig_TaskMacroPlugin.content.apply( this, arguments )
    		return true
    	},
    	fullContent: function( e, changeList ) {
    		var tiddlers = e.refreshTiddlers
    		if ( changeList == null || tiddlers == null )
    			return false
    		for ( var i=0; i < tiddlers.length; ++i )
    			if ( changeList.find(tiddlers[i]) != null ) {
    				var title = tiddlers[0]
    				story.refreshTiddler( title, null, true )
    				return true
    			}
    		return false
    	}
    }
    function refreshElements(root,changeList)
    {
    	var nodes = root.childNodes;
    	for(var c=0; c<nodes.length; c++)
    		{
    		var e = nodes[c],type;
    		if(e.getAttribute)
    			type = e.getAttribute("refresh");
    		else
    			type = null;
    		var refresher = config.refreshers[type];
    		if ( ! refresher || ! refresher(e, changeList) )
    			{
    			if(e.hasChildNodes())
    				refreshElements(e,changeList);
    			}
    		}
    }
    //}}}
    /***
    !Global Functions
    ***/
    //{{{
    // Add the tiddler whose title is given to the list of tiddlers whose
    // changing will cause a refresh of the tiddler containing the given element.
    function addDisplayDependency( element, title ) {
    	while ( element && element.getAttribute ) {
    		var idAttr = element.getAttribute("id"), tiddlerAttr = element.getAttribute("tiddler")
    		if ( idAttr && tiddlerAttr && idAttr == story.idPrefix+tiddlerAttr ) {
    			var list = element.refreshTiddlers
    			if ( list == null ) {
    				list = [tiddlerAttr]
    				element.refreshTiddlers = list
    				element.setAttribute( "refresh", "fullContent" )
    			}
    			list.pushUnique( title )
    			return
    		}
    		element = element.parentNode
    	}
    }

    // Lifted from Story.prototype.focusTiddler: just return the field instead of focusing it.
    Story.prototype.findEditField = function( title, field )
    {
    	var tiddler = document.getElementById(this.idPrefix + title);
    	if(tiddler != null)
    		{
    		var children = tiddler.getElementsByTagName("*")
    		var e = null;
    		for (var t=0; t<children.length; t++)
    			{
    			var c = children[t];
    			if(c.tagName.toLowerCase() == "input" || c.tagName.toLowerCase() == "textarea")
    				{
    				if(!e)
    					e = c;
    				if(c.getAttribute("edit") == field)
    					e = c;
    				}
    			}
    		return e
    		}
    }

    // Wraps the given event function in another function that handles the
    // event in a standard way.
    function wrapEventHandler( otherHandler ) {
    	return function(e) {
    		if (!e) var e = window.event
    		e.cancelBubble = true
    		if (e.stopPropagation) e.stopPropagation()
    		return otherHandler( e )
    	}
    }
    //}}}
    /***
    !Task Macro
    Usage:
    > {{{<<task orig cur spent>>description}}}
    All of orig, cur, and spent are optional numbers of hours.  The description goes through the end of the line, and is wikified.
    ***/
    //{{{
    config.macros.task = {
    	NASCENT:	0, // Task not yet estimated
    	LIVE:		1, // Estimated but with time remaining
    	DONE:		2, // Completed: no time remaining
    	bullets:	["\u25cb", // nascent (open circle)
    			 "\u25ba", // live (right arrow)
    			 "\u25a0"],// done (black square)
    	styles:		["nascent", "live", "done"],

    	// Translatable text:
    	lingo: {
    		spentTooBig:	"Spent time %0 can't exceed current estimate %1",
    		noNegative:	"Times may not be negative numbers",
    		statusTips:	["Not yet estimated", "To do", "Done"], // Array indexed by state (NASCENT/LIVE/DONE)
    		descClickTip:	" -- Double-click to edit task description",
    		statusClickTip:	" -- Double-click to mark task complete",
    		statusDoneTip:	" -- Double-click to adjust the time spent, to revive the task",
    		origTip:	"Original estimate in hours",
    		curTip:		"Current estimate in hours",
    		curTip2:	"Estimate in hours", // For when orig == cur
    		clickTip:	" -- Click to adjust",
    		spentTip:	"Hours spent on this task",
    		remTip:		"Hours remaining",
    		curPrompt:	"Estimate this task in hours, or adjust the current estimate by starting with + or -.\n\nYou may optionally also set or adjust the time spent by putting a second number after the first.",
    		spentPrompt:	"Enter the number of hours you've spent on this task, or adjust the current number by starting with + or -.\n\nYou may optionally also set or adjust the time remaining by putting a second number after the first.",
    		remPrompt:	"Enter the number of hours it will take to finish this task, or adjust the current estimate by starting with + or -.\n\nYou may optionally also set or adjust the time spent by putting a second number after the first.",
    		numbersOnly:	"Enter numbers only, please",
    		notCurrent:	"The tiddler has been modified since it was displayed, please redisplay it before doing this."
    	},

    	// The macro handler
    	handler: function( place, macroName, params, wikifier, paramString, tiddler )
    	{
    		var start = wikifier.matchStart, end = wikifier.nextMatch

    		var origStr	= params.length > 0? params.shift() : "?"
    		var orig	= +origStr // as a number
    		var cur		= params.length > 1? +params.shift() : orig
    		var spent	= params.length > 0? +params.shift() : 0
    		if ( spent > cur )
    			throw Error( this.lingo.spentTooBig.format([spent, cur]) )
    		if ( orig < 0 || cur < 0 || spent < 0 )
    			throw Error( this.lingo.noNegative )
    		var rem		= cur - spent
    		var state	= isNaN(orig+rem)? this.NASCENT : rem > 0? this.LIVE : this.DONE
    		var table	= createTiddlyElement( place, "table", null, "task "+this.styles[state] )
    		var tbody	= createTiddlyElement( table, "tbody" )
    		var row		= createTiddlyElement( tbody, "tr" )
    		var statusCell	= createTiddlyElement( row,   "td", null, "status", this.bullets[state] )
    		var descCell	= createTiddlyElement( row,   "td", null, "description" )

    		var origCell	= state==this.NASCENT || orig==cur? null
    				: createTiddlyElement( row, "td", null, "numeric original" )
    		var curCell	= createTiddlyElement( row, "td", null, "numeric current" )
    		var spentCell	= createTiddlyElement( row, "td", null, "numeric spent" )
    		var remCell	= createTiddlyElement( row, "td", null, "numeric remaining" )

    		var sums = config.macros.tasksum.tasksums
    		if ( sums && sums.length ) {
    			var summary = [(state == this.NASCENT? NaN : orig), cur, spent]
    			summary.owner = tiddler
    			sums[0].push( summary )
    		}

    		// The description goes to the end of the line
    		wikifier.subWikify( descCell, "$\\n?" )
    		var descEnd = wikifier.nextMatch

    		statusCell.setAttribute( "title", this.lingo.statusTips[state] )
    		descCell.setAttribute(   "title", this.lingo.statusTips[state]+this.lingo.descClickTip )
    		if (origCell) {
    			createTiddlyElement( origCell, "div", null, null, orig )
    			origCell.setAttribute( "title", this.lingo.origTip )
    			curCell.setAttribute( "title", this.lingo.curTip )
    		}
    		else {
    			curCell.setAttribute( "title", this.lingo.curTip2 )
    		}
    		var curDivContents = (state==this.NASCENT)? "?" : cur
    		var curDiv = createTiddlyElement( curCell, "div", null, null, curDivContents )
    		spentCell.setAttribute( "title", this.lingo.spentTip )
    		var spentDiv = createTiddlyElement( spentCell, "div", null, null, spent )
    		remCell.setAttribute( "title", this.lingo.remTip )
    		var remDiv = createTiddlyElement( remCell, "div", null, null, rem )

    		// Handle double-click on the description by going
    		// into edit mode and selecting the description
    		descCell.ondblclick = this.editDescription( tiddler, end, descEnd )

    		function appTitle( el, suffix ) {
    			el.setAttribute( "title", el.getAttribute("title")+suffix )
    		}

    		// For incomplete tasks, handle double-click on the bullet by marking the task complete
    		if ( state != this.DONE ) {
    			appTitle( statusCell, this.lingo.statusClickTip )
    			statusCell.ondblclick = this.markTaskComplete( tiddler, start, end, macroName, orig, cur, state )
    		}
    		// For complete ones, handle double-click on the bullet by letting you adjust the time spent
    		else {
    			appTitle( statusCell, this.lingo.statusDoneTip )
    			statusCell.ondblclick = this.adjustTimeSpent( tiddler, start, end, macroName, orig, cur, spent )
    		}

    		// Add click handlers for the numeric cells.
    		if ( state != this.DONE ) {
    			appTitle( curCell, this.lingo.clickTip )
    			curDiv.className = "adjustable"
    			curDiv.onclick = this.adjustCurrentEstimate( tiddler, start, end, macroName,
    				orig, cur, spent, curDivContents )
    		}
    		appTitle( spentCell, this.lingo.clickTip )
    		spentDiv.className = "adjustable"
    		spentDiv.onclick = this.adjustTimeSpent( tiddler, start, end, macroName, orig, cur, spent )
    		if ( state == this.LIVE ) {
    			appTitle( remCell, this.lingo.clickTip )
    			remDiv.className = "adjustable"
    			remDiv.onclick = this.adjustTimeRemaining( tiddler, start, end, macroName, orig, cur, spent )
    		}
    	},

    	// Puts the tiddler into edit mode, and selects the range of characters
    	// defined by start and end.  Separated for leak prevention in IE.
    	editDescription: function( tiddler, start, end ) {
    		return wrapEventHandler( function(e) {
    			story.displayTiddler( null, tiddler.title, DEFAULT_EDIT_TEMPLATE )
    			var tiddlerElement = document.getElementById( story.idPrefix + tiddler.title )
    			window.scrollTo( 0, ensureVisible(tiddlerElement) )
    			var element = story.findEditField( tiddler.title, "text" )
    			if ( element && element.tagName.toLowerCase() == "textarea" ) {
    				// Back up one char if the last char's a newline
    				if ( tiddler.text[end-1] == '\n' )
    					--end
    				element.focus()
    				if ( element.setSelectionRange != undefined ) { // Mozilla
    					element.setSelectionRange( start, end )
    					// Damn mozilla doesn't scroll to visible.  Approximate.
    					var max = 0.0 + element.scrollHeight
    					var len = element.textLength
    					var top = max*start/len, bot = max*end/len
    					element.scrollTop = Math.min( top, (bot+top-element.clientHeight)/2 )
    				}
    				else if ( element.createTextRange != undefined ) { // IE
    					var range = element.createTextRange()
    					range.collapse()
    					range.moveEnd("character", end)
    					range.moveStart("character", start)
    					range.select()
    				}
    				else // Other? Too bad, just select the whole thing.
    					element.select()
    				return false
    			}
    			else
    				return true
    		} )
    	},

    	// Modifies a task macro call such that the task appears complete.
    	markTaskComplete: function( tiddler, start, end, macroName, orig, cur, state ) {
    		var macro = this, text = tiddler.text
    		return wrapEventHandler( function(e) {
    			if ( text !== tiddler.text ) {
    				alert( macro.lingo.notCurrent )
    				return false
    			}
    			if ( state == macro.NASCENT )
    				orig = cur = 0
    			// The second "cur" in the call below bumps up the time spent
    			// to match the current estimate.
    			macro.replaceMacroCall( tiddler, start, end, macroName, orig, cur, cur )
    			return false
    		} )
    	},

    	// Asks the user for an adjustment to the current estimate, modifies the macro call accordingly.
    	adjustCurrentEstimate: function( tiddler, start, end, macroName, orig, cur, spent, curDivContents ) {
    		var macro = this, text = tiddler.text
    		return wrapEventHandler( function(e) {
    			if ( text !== tiddler.text ) {
    				alert( macro.lingo.notCurrent )
    				return false
    			}
    			var txt = prompt( macro.lingo.curPrompt, curDivContents )
    			if ( txt != null ) {
    				var a = macro.breakInput( txt )
    				cur = macro.offset( cur, a[0] )
    				if ( a.length > 1 )
    					spent = macro.offset( spent, a[1] )
    				macro.replaceMacroCall( tiddler, start, end, macroName, orig, cur, spent )
    			}
    			return false
    		} )
    	},

    	// Asks the user for an adjustment to the time spent, modifies the macro call accordingly.
    	adjustTimeSpent: function( tiddler, start, end, macroName, orig, cur, spent ) {
    		var macro = this, text = tiddler.text
    		return wrapEventHandler( function(e) {
    			if ( text !== tiddler.text ) {
    				alert( macro.lingo.notCurrent )
    				return false
    			}
    			var txt = prompt( macro.lingo.spentPrompt, spent )
    			if ( txt != null ) {
    				var a = macro.breakInput( txt )
    				spent = macro.offset( spent, a[0] )
    				var rem = cur - spent
    				if ( a.length > 1 ) {
    					rem = macro.offset( rem, a[1] )
    					cur = spent + rem
    				}
    				macro.replaceMacroCall( tiddler, start, end, macroName, orig, cur, spent )
    			}
    			return false
    		} )
    	},

    	// Asks the user for an adjustment to the time remaining, modifies the macro call accordingly.
    	adjustTimeRemaining: function( tiddler, start, end, macroName, orig, cur, spent ) {
    		var macro = this
    		var text  = tiddler.text
    		var rem   = cur - spent
    		return wrapEventHandler( function(e) {
    			if ( text !== tiddler.text ) {
    				alert( macro.lingo.notCurrent )
    				return false
    			}
    			var txt = prompt( macro.lingo.remPrompt, rem )
    			if ( txt != null ) {
    				var a = macro.breakInput( txt )
    				var newRem = macro.offset( rem, a[0] )
    				if ( newRem > rem || a.length > 1 )
    					cur += (newRem - rem)
    				else
    					spent += (rem - newRem)
    				if ( a.length > 1 )
    					spent = macro.offset( spent, a[1] )
    				macro.replaceMacroCall( tiddler, start, end, macroName, orig, cur, spent )
    			}
    			return false
    		} )
    	},

    	// Breaks input at spaces & commas, returns array
    	breakInput: function( txt ) {
    		var a = txt.trim().split( /[\s,]+/ )
    		if ( a.length == 0 )
    			a = [NaN]
    		return a
    	},

    	// Adds to, subtracts from, or replaces a numeric value
    	offset: function( num, txt ) {
    		if ( txt == "" || typeof(txt) != "string" )
    			return NaN
    		if ( txt.match(/^[+-]/) )
    			return num + (+txt)
    		return +txt
    	},

    	// Does some error checking, then replaces the indicated macro
    	// call within the text of the given tiddler.
    	replaceMacroCall: function( tiddler, start, end, macroName, orig, cur, spent )
    	{
    		if ( isNaN(cur+spent) ) {
    			alert( this.lingo.numbersOnly )
    			return
    		}
    		if ( spent < 0 || cur < 0 ) {
    			alert( this.lingo.noNegative )
    			return
    		}
    		if ( isNaN(orig) )
    			orig = cur
    		if ( spent > cur )
    			cur = spent
    		var text = tiddler.text.substring(0,start) + "<<" + macroName + " " +
    			orig + " " + cur + " " + spent + ">>" + tiddler.text.substring(end)
    		var title = tiddler.title
    		store.saveTiddler( title, title, text, config.options.txtUserName, new Date(), undefined )
    		//story.refreshTiddler( title, null, true )
    		if ( config.options.chkAutoSave )
    			saveChanges()
    	}
    }
    //}}}
    /***
    !Tasksum Macro
    Usage:
    > {{{<<tasksum "start" ["here" [intro]]>>}}}
    or:
    > {{{<<tasksum "end" [intro]>>}}}
    Put one of the {{{<<tasksum start>>}}} lines before the tasks you want to summarize, and an {{{end}}} line after them.  By default, the summary goes at the end; if you include {{{here}}} in the start line, the summary will go at the top.  The intro argument, if supplied, replaces the default text introducing the summary.
    ***/
    //{{{
    config.macros.tasksum = {

    	// Translatable text:
    	lingo: {
    		unrecVerb:	"<<%0>> requires 'start' or 'end' as its first argument",
    		mustMatch:	"<<%0 end>> must match a preceding <<%0 start>>",
    		defIntro:	"Task summary:",
    		nascentSum:	"''%0 not estimated''",
    		doneSum:	"%0 complete (in %1 hours)",
    		liveSum:	"%0 ongoing (%1 hours so far, ''%2 hours remaining'')",
    		overSum:	"Total overestimate: %0%.",
    		underSum:	"Total underestimate: %0%.",
    		descPattern:	"%0 %1. %2",
                    origTip:	"Total original estimates in hours",
    		curTip:		"Total current estimates in hours",
    		spentTip:	"Total hours spent on tasks",
    		remTip:		"Total hours remaining"
    	},

    	// The macro handler
    	handler: function( place, macroName, params, wikifier, paramString, tiddler )
    	{
    		var sums = this.tasksums
    		if ( params[0] == "start" ) {
    			sums.unshift([])
    			if ( params[1] == "here" ) {
    				sums[0].intro = params[2] || this.lingo.defIntro
    				sums[0].place = place
    				sums[0].placement = place.childNodes.length
    			}
    		}
    		else if ( params[0] == "end" ) {
    			if ( ! sums.length )
    				throw Error( this.lingo.mustMatch.format([macroName]) )
    			var list = sums.shift()
    			var intro = list.intro || params[1] || this.lingo.defIntro
    			var nNascent=0, nLive=0, nDone=0, nMine=0
    			var totLiveSpent=0, totDoneSpent=0
    			var totOrig=0, totCur=0, totSpent=0
    			for ( var i=0; i < list.length; ++i ) {
    				var a = list[i]
    				if ( a.length > 3 ) {
    					nNascent 	+= a[0]
    					nLive 		+= a[1]
    					nDone 		+= a[2]
    					totLiveSpent 	+= a[3]
    					totDoneSpent 	+= a[4]
    					totOrig 	+= a[5]
    					totCur 		+= a[6]
    					totSpent 	+= a[7]
    					if ( a.owner == tiddler )
    						nMine	+= a[8]
    				}
    				else {
    					if ( a.owner == tiddler )
    						++nMine
    					if ( isNaN(a[0]) ) {
    						++nNascent
    					}
    					else {
    						if ( a[1] > a[2] ) {
    							++nLive
    							totLiveSpent += a[2]
    						}
    						else {
    							++nDone
    							totDoneSpent += a[2]
    						}
    						totOrig  += a[0]
    						totCur   += a[1]
    						totSpent += a[2]
    					}
    				}
    			}

    			// If we're nested, push a summary outward
                            if ( sums.length ) {
    				var summary = [nNascent, nLive, nDone, totLiveSpent, totDoneSpent,
    						totOrig, totCur, totSpent, nMine]
    				summary.owner = tiddler
    				sums[0].push( summary )
    			}

    			var descs = [], styles = []
    			if ( nNascent > 0 ) {
    				descs.push( this.lingo.nascentSum.format([nNascent]) )
    				styles.push( "nascent" )
    			}
    			if ( nDone > 0 )
    				descs.push( this.lingo.doneSum.format([nDone, totDoneSpent]) )
    			if ( nLive > 0 ) {
    				descs.push( this.lingo.liveSum.format([nLive, totLiveSpent, totCur-totSpent]) )
    				styles.push( "live" )
    			}
    			else
    				styles.push( "done" )
    			var off = ""
    			if ( totOrig > totCur )
    				off = this.lingo.overSum.format( [Math.round(100.0*(totOrig-totCur)/totCur)] )
    			else if ( totCur > totOrig )
    				off = this.lingo.underSum.format( [Math.round(100.0*(totCur-totOrig)/totOrig)] )

    			var top		= (list.intro != undefined)
    			var table	= createTiddlyElement( null, "table", null, "tasksum "+(top?"top":"bottom") )
    			var tbody	= createTiddlyElement( table, "tbody" )
    			var row		= createTiddlyElement( tbody, "tr", null, styles.join(" ") )
    			var descCell	= createTiddlyElement( row,   "td", null, "description" )

    			var description = this.lingo.descPattern.format( [intro, descs.join(", "), off] )
    			wikify( description, descCell, null, tiddler )

    			var origCell	= totOrig == totCur? null
    					: createTiddlyElement( row, "td", null, "numeric original", totOrig )
    			var curCell	= createTiddlyElement( row, "td", null, "numeric current", totCur )
    			var spentCell	= createTiddlyElement( row, "td", null, "numeric spent", totSpent )
    			var remCell	= createTiddlyElement( row, "td", null, "numeric remaining", totCur-totSpent )

    			if ( origCell )
    				origCell.setAttribute( "title", this.lingo.origTip )
    			curCell  .setAttribute( "title", this.lingo.curTip )
    			spentCell.setAttribute( "title", this.lingo.spentTip )
    			remCell  .setAttribute( "title", this.lingo.remTip )

    			// Discard the table if there are no tasks
    			if ( list.length > 0 ) {
    				var place = top? list.place : place
    				var placement = top? list.placement : place.childNodes.length
    				if ( placement >= place.childNodes.length )
    					place.appendChild( table )
    				else
    					place.insertBefore( table, place.childNodes[placement] )
    			}
    		}
    		else
    			throw Error( this.lingo.unrecVerb.format([macroName]) )

    		// If we're wikifying, and are followed by end-of-line, swallow the newline.
    		if ( wikifier && wikifier.source.charAt(wikifier.nextMatch) == "\n" )
    			++wikifier.nextMatch
    	},

    	// This is the stack of pending summaries
    	tasksums: []
    }
    //}}}
    /***
    !Taskadder Macro
    Usage:
    > {{{<<taskadder ["above"|"below"|"focus"|"nofocus"]...>>}}}
    Creates a line with text entry fields for a description and an estimate.  By default, puts focus in the description field and adds tasks above the entry fields.  Use {{{nofocus}}} to not put focus in the description field.  Use {{{below}}} to add tasks below the entry fields.
    ***/
    //{{{
    config.macros.taskadder = {

    	// Translatable text:
    	lingo: {
    		unrecParam:	"<<%0>> doesn't recognize '%1' as a parameter",
    		descTip:	"Describe a new task",
    		curTip:		"Estimate how long in hours the task will take",
    		buttonText:	"add task",
    		buttonTip:	"Add a new task with the description and estimate as entered",
    		notCurrent:	"The tiddler has been modified since it was displayed, please redisplay it before adding a task this way.",

    		eol:		"eol"
    	},

    	// The macro handler
    	handler: function( place, macroName, params, wikifier, paramString, tiddler )
    	{
    		var above = true
    		var focus = false

    		while ( params.length > 0 ) {
    			var p = params.shift()
    			switch (p) {
    			case "above": 	above = true;  break
    			case "below": 	above = false; break
    			case "focus": 	focus = true;  break
    			case "nofocus":	focus = false; break
    			default:	throw Error( this.lingo.unrecParam.format([macroName, p]) )
    			}
    		}

    		// If we're followed by end-of-line, swallow the newline.
    		if ( wikifier.source.charAt(wikifier.nextMatch) == "\n" )
    			++wikifier.nextMatch

    		var where	= above? wikifier.matchStart : wikifier.nextMatch

    		var table	= createTiddlyElement( place, "table", null, "task" )
    		var tbody	= createTiddlyElement( table, "tbody" )
    		var row		= createTiddlyElement( tbody, "tr" )
    		var statusCell	= createTiddlyElement( row,   "td", null, "status" )
    		var descCell	= createTiddlyElement( row,   "td", null, "description" )
    		var curCell	= createTiddlyElement( row,   "td", null, "numeric" )
    		var addCell	= createTiddlyElement( row,   "td", null, "addtask" )

    		var descId	= this.generateId()
    		var curId	= this.generateId()
    		var descInput	= createTiddlyElement( descCell, "input", descId )
    		var curInput	= createTiddlyElement( curCell,  "input", curId  )

    		descInput.setAttribute( "type", "text" )
    		curInput .setAttribute( "type", "text" )
    		descInput.setAttribute( "size", "40")
    		curInput .setAttribute( "size", "6" )
    		descInput.setAttribute( "autocomplete", "off" );
    		curInput .setAttribute( "autocomplete", "off" );
    		descInput.setAttribute( "title", this.lingo.descTip );
    		curInput .setAttribute( "title", this.lingo.curTip  );

    		var addAction	= this.addTask( tiddler, where, descId, curId, above )
    		var addButton	= createTiddlyButton( addCell, this.lingo.buttonText, this.lingo.buttonTip, addAction )

    		descInput.onkeypress = this.handleEnter(addAction)
    		curInput .onkeypress = descInput.onkeypress
    		addButton.onkeypress = this.handleSpace(addAction)
    		if ( focus || tiddler.taskadderLocation == where ) {
    			descInput.focus()
    			descInput.select()
    		}
    	},

    	// Returns a function that inserts a new task macro into the tiddler.
    	addTask: function( tiddler, where, descId, curId, above ) {
    		var macro = this, oldText = tiddler.text
    		return wrapEventHandler( function(e) {
    			if ( oldText !== tiddler.text ) {
    				alert( macro.lingo.notCurrent )
    				return false
    			}
    			var desc	= document.getElementById(descId).value
    			var cur		= document.getElementById(curId) .value
    			var init	= tiddler.text.substring(0,where) + "<<task " + cur + ">> " + desc + "\n"
    			var text	= init + tiddler.text.substring(where)
    			var title	= tiddler.title
    			tiddler.taskadderLocation = (above? init.length : where)
    			try {
    				store.saveTiddler( title, title, text, config.options.txtUserName, new Date(), undefined )
    				//story.refreshTiddler( title, null, true )
    			}
    			finally {
    				delete tiddler.taskadderLocation
    			}
    			if ( config.options.chkAutoSave )
    				saveChanges()
    		} )
    	},

    	// Returns an event handler that delegates to two other functions: "matches" to decide
    	// whether to consume the event, and "addTask" to actually perform the work.
    	handleGeneric: function( addTask, matches ) {
    		return function(e) {
    			if (!e) var e = window.event
    			var consume = false
    			if ( matches(e) ) {
    				consume = true
    				addTask( e )
    			}
    			e.cancelBubble = consume;
    			if ( consume && e.stopPropagation ) e.stopPropagation();
    			return !consume;
    		}
    	},

    	// Returns an event handler that handles enter keys by calling another event handler
    	handleEnter: function( addTask ) {
    		return this.handleGeneric( addTask, function(e){return e.keyCode == 13 || e.keyCode == 10} ) // Different codes for Enter
    	},

    	// Returns an event handler that handles the space key by calling another event handler
    	handleSpace: function( addTask ) {
    		return this.handleGeneric( addTask, function(e){return (e.charCode||e.keyCode) == 32} )
    	},

    	counter: 0,
    	generateId: function() {
    		return "taskadder:" + String(this.counter++)
    	}
    }
    //}}}
    /***
    !Stylesheet
    ***/
    //{{{
    var stylesheet = '\
    .viewer table.task, table.tasksum {\
    	width: 100%;\
    	padding: 0;\
    	border-collapse: collapse;\
    }\
    .viewer table.task {\
    	border: none;\
    	margin: 0;\
    }\
    table.tasksum, .viewer table.tasksum {\
    	border: solid 2px #999;\
    	margin: 3px 0;\
    }\
    table.tasksum td {\
    	text-align: center;\
    	border: 1px solid #ddd;\
    	background-color: #ffc;\
    	vertical-align: middle;\
    	margin: 0;\
    	padding: 0;\
    }\
    .viewer table.task tr {\
    	border: none;\
    }\
    .viewer table.task td {\
    	text-align: center;\
    	vertical-align: baseline;\
    	border: 1px solid #fff;\
    	background-color: inherit;\
    	margin: 0;\
    	padding: 0;\
    }\
    td.numeric {\
    	width: 3em;\
    }\
    table.task td.numeric div {\
    	border: 1px solid #ddd;\
    	background-color: #ffc;\
    	margin: 1px 0;\
    	padding: 0;\
    }\
    table.task td.original div {\
    	background-color: #fdd;\
    }\
    table.tasksum td.original {\
    	background-color: #fdd;\
    }\
    table.tasksum td.description {\
    	background-color: #e8e8e8;\
    }\
    table.task td.status {\
    	width: 1.5em;\
    	cursor: default;\
    }\
    table.task td.description, table.tasksum td.description {\
    	width: auto;\
    	text-align: left;\
    	padding: 0 3px;\
    }\
    table.task.done td.status,table.task.done td.description {\
    	color: #ccc;\
    }\
    table.task.done td.current, table.task.done td.remaining {\
    	visibility: hidden;\
    }\
    table.task.done td.spent div, table.tasksum tr.done td.current,\
    table.tasksum tr.done td.spent, table.tasksum tr.done td.remaining {\
    	background-color: #eee;\
    	color: #aaa;\
    }\
    table.task.nascent td.description {\
    	color: #844;\
    }\
    table.task.nascent td.current div, table.tasksum tr.nascent td.numeric.current {\
    	font-weight: bold;\
    	color: #c00;\
    	background-color: #def;\
    }\
    table.task.nascent td.spent, table.task.nascent td.remaining {\
    	visibility: hidden;\
    }\
    td.remaining {\
    	font-weight: bold;\
    }\
    .adjustable {\
    	cursor: pointer; \
    }\
    table.task input {\
    	display: block;\
    	width: 100%;\
    	font: inherit;\
    	margin: 2px 0;\
    	padding: 0;\
    	border: 1px inset #999;\
    }\
    table.task td.numeric input {\
    	background-color: #ffc;\
    	text-align: center;\
    }\
    table.task td.addtask {\
    	width: 6em;\
    	border-left: 2px solid white;\
    	vertical-align: middle;\
    }\
    '
    setStylesheet( stylesheet, "TaskMacroPluginStylesheet" )
    //}}}

    !!Changes in 1.1.0
    * Made the macros work in nested tiddlers (ie when one tiddler includes another using {{{<<tiddler>>}}} or something similar):
    ** Task summaries in the outer tiddler include the tasks from the inner one
    ** Using the editing shortcuts on the tasks as displayed in the outer tiddler correctly changes the inner tiddler and also redisplays the outer one
    ** Added sanity checks to the editing shortcuts so they will refuse to work if the tiddler has been modified behind their backs
    * Made some small usability fixes:
    ** The "add task" button now responds to the Space key (hat tip: Daniel Baird)
    ** Double-clicking on a completed task's bullet now does the same thing as clicking on the elapsed time: it lets you adjust the time spent, giving you the option of resurrecting the task (hat tip: ~JackF)
    ** Reworked the focus handling of the taskadder macro so it works more intuitively, by refocusing on the same adder you just used

    The task macro provided by the TaskMacroPlugin is for planning, estimating, and tracking detailed tasks such as those required for writing software.  It is inspired by [[Joel Spolsky|http://www.joelonsoftware.com/articles/fog0000000245.html]]'s method for scheduling software development, also popularized by [[Voo2do|http://voo2do.com]] and [[XPlanner|http://xplanner.org]].

    For changes since the previous version, see the TaskMacroReleaseNotes.

    This tutorial leads you through the use of the task macro itself, and supporting macros that summarize lists of tasks and simplify the adding of tasks to a list.  Follow along by clicking the links below.  Or click the little down-arrow next to this tiddler's title, above, and choose "Open all" to have all the tutorial sections displayed at once.

    <!---
    Includes portions of [[TagglyTaggingViewTemplate|http://simonbaird.com/mptw/#TagglyTaggingViewTemplate]], v1.2 (16-Jan-2006).
    Also adds a pair of tasksum macros around the tiddler, to summarize any contained tasks at the top.  Removes the "-" in front of closeTiddler, which can easily bite you if you have a focusable element in a tiddler, such as a taskadder entry field.
    Portions written by Luke Blanshard are hereby released into the public domain.
    --->
    <!--{{{-->
    <div class="toolbar" macro="toolbar closeTiddler closeOthers +editTiddler permalink references jump newHere"></div>
    <div class="tagglyTagged" macro="tags"></div>
    <div><span class="title" macro="view title"></span><span class="miniTag" macro="miniTag"></span></div>
    <div macro="tasksum start here"></div>
    <div class="viewer" macro="view text wikified"></div>
    <div macro="tasksum end"></div>
    <div class="tagglyTagging" macro="tagglyListWithSort"></div>
    <!--}}}-->

    ! The Test Script
    To drive the various tests, we use the script {{{tests/test.sh}}}. All tests are run under valgrind control if available unless {{{VALGRINDFLAGS=DISABLE}}} is defined.
    * The SCons buildsystem will build and run the testcode when executing the target {{{scons tests}}}.
    * This test script is integrated in the automake build and will be used when {{{make check}}} is called.

    ! Options for running the Test Suite
    One may define {{{TESTMODE}}} containing any one of the following strings:
    * {{{FAST}}} only run tests which failed recently
    * {{{FIRSTFAIL}}} abort the tests at the first failure

    The variable {{{TESTSUITES}}} may contain a list of string which are used to select which tests are run. If not given, all available tests are run.

    putting this together a very fast check (when using automake) while hacking on the source would look like:
    {{{
    VALGRINDFLAGS=DISABLE TESTMODE=FAST+FIRSTFAIL make check
    }}}
    This doesn't catch all errors, notably not regressions, but is useful to do coarse checks.

    Running the testsuite with everything enabled is just:
    {{{
    make check
    }}}

    ! Writing Tests
    ~Test-Definitons are written in files named {{{NNname.tests}}} in the {{{tests}}} dir, where NN is a number defining the order of the various test files, 'name' should be a descriptive name about whats going to be tested.

    In a .tests file one has to define following:
    * {{{TESTING <description> <binary>}}} set the program binary to be tested to <binary>, <description> should be a string which is displayed as header before running following tests
    * {{{TEST <description> [optargs] <<END}}} run the previously set binary with [optargs], <description> is displayed when running this test. A detailed test spec must follow this command and be terminated with {{{END}}} on a single line. Test specs can contain following statements:
    ** {{{in: <line>}}} send <line> to stdin of the test program
    ** {{{out: <line>}}} expect <line> at the stdout of the test program
    ** {{{err: <line>}}} expect <line> at the stderr of the test program
    ** {{{return: <status>}}} expect <status> as exit status of the program

    If no {{{out:}}} or {{{err:}}} is given, stdout and stderr are not considered as part of the test. If no {{{return:}}} is given, then 0 is expected.

    !! Numbering Tests
    It needs to be ensured that simpler tests come before more complex ones and that dependant tests come after their dependencies.

    Here is the order suggested:
    |00|The test system itself|
    |01..|Infrastructure, package consistency etc.|
    |10..|Basic support library functionality|
    |20..|Higher level support library services|
    |30..|Backend Unit tests|
    |40..|Proc Layer Unit tests|
    |50..|User interface Unit tests (Gui, Scripting)|
    |60..|Unit interaction tests (Backend, Proc, UI, ...)|
    |70..|Functionality tests on the complete program|
    |80..|Reported bugs which can be expressed in a test case|
    |90..|Optional tests, example code etc.|

    For running the automatic Tests, we use Cehteh's simple [[test.sh|TestSh]].

    This page is a proposal (by Ichthyo) how the various tests could be organized.
    * individual ''Testcases'' are classes, doing whatsoever and however they see fit.
    * it is up to the individual test classes to take care / handle / isolate themself form any ''dependencies'' (similar to the [[philosophy of TestNG|http://www.beust.com/weblog/archives/000082.html]])
    * Testcases are ''grouped'' together into thematic (Sub)-Testsuites. Each Testcase has an unique ID and can be tagged with several groupIDs
    * for running a ''Testsuite'' (=distinct collection of tests) we build an executable linked against the test class objects.
    * moreover, for ''simple Tests'', we can build separate stelf-contained executables or even use other scripts.
    * the Testsuite executable provides some command line magic to select individual tests.
    * Top-level Testsuites or ''~Test-Collections'' for [[test.sh|TestSh]] contain calls to the different (sub)-Suites, together with the expected results/output

    !internal Testsuite runner
    The class {{{test::Suite}}} (common/test/suite.hpp) helps building an executable which will run all //registered// test case objects, or some group of such testcases. Each test case implements a simple interface and thus provides a {{{run (args)}}} function, moreover, it registers itself immediately alongside with his definition; this works by the usual trick of defining a static class object and calling some registration function from the constructor of this static var. See the following __hello-world-Example__:
    {{{
    #include <iostream>
    #include "common/test/run.hpp"

        class HelloWorld_test : public Test
          {
            virtual void run(Arg arg)
              {
                greeting();
              }

            void greeting()
              {
                std::cout << "This is how the world ends...\n";
              }
          };

        /** Register this test class to be invoked in some test groups (suites) */
        LAUNCHER (HelloWorld_test, "unit function common");
    }}}
    Notes:
    * type Arg is {{{typedef std::vector<string> & Arg;}}}
    * this vector may be {{{size()==0}}}, which means no comandline args available.
    * otherwise arg[0] is always the ID (normally the classname) of the test
    * the following args may contain further arguments passed from system commandline.
    * the test can/should produce output that can be checked with Cehteh's [[./test.sh|TestSh]].
    * the macro "LAUNCHER" expands to {{{Launch<HelloWorld_test> run_HelloWorld_test("HelloWorld_test","unit function common");}}}
    * note the second parameter to the macro (or the Laucher-ctor) is a space-delimited list of group names
    * thus any test can declare itself as belonging to some groups, and we can create a {{{test::Suite}}} for each group if we want.

    !!!invoking the testrunner
    The class {{{test::TestOption}}} predefines a boost-commandlineparser to support the following optons:

    |>|!{{{./test-components --group <groupID> [testID [arguments...]]}}}|
    |{{{--help}}}| options summary|
    |{{{--group|-g <groupID>}}}| build a Testsuite out of all tests from this group. If missing, ALL tests will be included |
    |{{{[testID]}}}| (optional) one single testcase. If missing, all testcases of the group will be invoked |
    |{{{--describe}}}| print all registered tests to stdout in a format suited for use with test.sh |
    Further commandline arguments are deliverd to a single testcase only if you specify a {{{testID}}}. Otherwise, all commandline arguments remaining after options parsing will be discarded and all tests of the suite will be run with an commandline vector of size()==0

    !conventions for the Buildsystem
    to help with automating the build, ichthyo would appreciate to have the following conventions.
    * in the {{{tests}}} directory are
    ** the testdefinitions together with {{{test.sh}}}
    ** the test-executables, which should named according to the pattern {{{test-XXX}}}
    * below are the source directories for each of the aforementioned test-executables. When such a source directory is named "XXX", the corresponding executable is "test-XXX"
    * each of the source directories, which actually could be source trees, will be compiled and linked together with the Lumiera core classes and files. Thus, it needs to contain exactly //one// main(), but by using commandline parameters, one executable can drive a lot of different tests.

    -------
    //as of 18.8.2007, ichthyo has implemented this scheme for the SCons build//

    /***
    ''TextAreaPlugin for TiddlyWiki version 2.0''
    ^^author: Eric Shulman - ELS Design Studios
    source: http://www.elsdesign.com/tiddlywiki/#TextAreaPlugin
    license: [[Creative Commons Attribution-ShareAlike 2.5 License|http://creativecommons.org/licenses/by-sa/2.5/]]^^

    This plugin 'hijacks' the TW core function, ''Story.prototype.focusTiddler()'', so it can add special 'keyDown' handlers to adjust several behaviors associated with the textarea control used in the tiddler editor.  Specifically, it:
    * Adds text search INSIDE of edit fields.^^
    Use ~CTRL-F for "Find" (prompts for search text), and ~CTRL-G for "Find Next" (uses previous search text)^^
    * Enables TAB characters to be entered into field content^^
    (instead of moving to next field)^^
    * Option to set cursor at top of edit field instead of auto-selecting contents^^
    (see configuration section for checkbox)^^
    !!!!!Configuration
    <<<
    <<option chkDisableAutoSelect>> place cursor at start of textarea instead of pre-selecting content
    <<option chkTextAreaExtensions>> add control-f (find), control-g (find again) and allow TABs as input in textarea
    <<<
    !!!!!Installation
    <<<
    Import (or copy/paste) the following tiddlers into your document:
    ''TextAreaPlugin'' (tagged with <<tag systemConfig>>)
    <<<
    !!!!!Revision History
    <<<
    ''2006.01.22 [1.0.1]''
    only add extra key processing for TEXTAREA elements (not other edit fields).
    added option to enable/disable textarea keydown extensions (default is "standard keys" only)
    ''2006.01.22 [1.0.0]''
    Moved from temporary "System Tweaks" tiddler into 'real' TextAreaPlugin tiddler.
    <<<
    !!!!!Code
    ***/
    //{{{
    version.extensions.textAreaPlugin= {major: 1, minor: 0, revision: 1, date: new Date(2006,1,23)};
    //}}}

    //{{{
    if (!config.options.chkDisableAutoSelect) config.options.chkDisableAutoSelect=false; // default to standard action
    if (!config.options.chkTextAreaExtensions) config.options.chkTextAreaExtensions=false; // default to standard action

    // Focus a specified tiddler. Attempts to focus the specified field, otherwise the first edit field it finds
    Story.prototype.focusTiddler = function(title,field)
    {
    	var tiddler = document.getElementById(this.idPrefix + title);
    	if(tiddler != null)
    		{
    		var children = tiddler.getElementsByTagName("*")
    		var e = null;
    		for (var t=0; t<children.length; t++)
    			{
    			var c = children[t];
    			if(c.tagName.toLowerCase() == "input" || c.tagName.toLowerCase() == "textarea")
    				{
    				if(!e)
    					e = c;
    				if(c.getAttribute("edit") == field)
    					e = c;
    				}
    			}
    		if(e)
    			{
    			e.focus();
    			e.select(); // select entire contents

    			// TWEAK: add TAB and "find" key handlers
    			if (config.options.chkTextAreaExtensions) // add extra key handlers
    				addKeyDownHandlers(e);

    			// TWEAK: option to NOT autoselect contents
    			if (config.options.chkDisableAutoSelect) // set cursor to start of field content
    				if (e.setSelectionRange) e.setSelectionRange(0,0); // for FF
    				else if (e.createTextRange) { var r=e.createTextRange(); r.collapse(true); r.select(); } // for IE

    			}
    		}
    }
    //}}}

    //{{{
    function addKeyDownHandlers(e)
    {
    	// exit if not textarea or element doesn't allow selections
    	if (e.tagName.toLowerCase()!="textarea" || !e.setSelectionRange) return;

    	// utility function: exits keydown handler and prevents browser from processing the keystroke
    	var processed=function(ev) { ev.cancelBubble=true; if (ev.stopPropagation) ev.stopPropagation(); return false; }

    	// capture keypress in edit field
    	e.onkeydown = function(ev) { if (!ev) var ev=window.event;

    		// process TAB
    		if (!ev.shiftKey && ev.keyCode==9) {
    			// replace current selection with a TAB character
    			var start=e.selectionStart; var end=e.selectionEnd;
    			e.value=e.value.substr(0,start)+String.fromCharCode(9)+e.value.substr(end);
    			// update insertion point, scroll it into view
    			e.setSelectionRange(start+1,start+1);
    			var linecount=e.value.split('\n').length;
    			var thisline=e.value.substr(0,e.selectionStart).split('\n').length-1;
    			e.scrollTop=Math.floor((thisline-e.rows/2)*e.scrollHeight/linecount);
    			return processed(ev);
    		}

    		// process CTRL-F (find matching text) or CTRL-G (find next match)
    		if (ev.ctrlKey && (ev.keyCode==70||ev.keyCode==71)) {
    			// if ctrl-f or no previous search, prompt for search text (default to previous text or current selection)... if no search text, exit
    			if (ev.keyCode==70||!e.find||!e.find.length)
    				{ var f=prompt("find:",e.find?e.find:e.value.substring(e.selectionStart,e.selectionEnd)); e.focus(); e.find=f?f:e.find; }
    			if (!e.find||!e.find.length) return processed(ev);
    			// do case-insensitive match with 'wraparound'...  if not found, alert and exit
    			var newstart=e.value.toLowerCase().indexOf(e.find.toLowerCase(),e.selectionStart+1);
    			if (newstart==-1) newstart=e.value.toLowerCase().indexOf(e.find.toLowerCase());
    			if (newstart==-1) { alert("'"+e.find+"' not found"); e.focus(); return processed(ev); }
    			// set new selection, scroll it into view, and report line position in status bar
    			e.setSelectionRange(newstart,newstart+e.find.length);
    			var linecount=e.value.split('\n').length;
    			var thisline=e.value.substr(0,e.selectionStart).split('\n').length;
    			e.scrollTop=Math.floor((thisline-1-e.rows/2)*e.scrollHeight/linecount);
    			window.status="line: "+thisline+"/"+linecount;
    			return processed(ev);
    		}
    	}
    }
    //}}}

    The Name of the Software driving this Wiki. Is is written completely in ~JavaScript and contained in one single HTML page.
    Thus no server and no network connection is needed. Simply open the file in your browser and save changes locally. As the wiki HTML is located in the Lumiera source tree, all changes will be managed and distributed via [[GIT|GitNotes]]. While doing so, you sometimes will have to merge conflicing changes manually in the HTML source. There is a 'empty.html' in the same folder serving as template for generating new wikis. Please refrain from editing it.
     * see GettingStarted
     * see [[Homepage|http://tiddlywiki.com]], [[Wiki-Markup|http://tiddlywiki.org/wiki/TiddlyWiki_Markup]]

    The question to find out about is: how much of the coding to do with the help of BOUML. Basically, BOUML is capable to permanently support the coding; you can define all entities, fields and methods in the UML model an just develop the method bodies //conventionally// with a text editor.

    __Ichthyo__ tends to be sceptical about this approach. While it probably will work, it is questionable if it will result in &raquo;good code&laquo; the fear is, that this rigid hierarchical structure distracts from the more complex semantical concerns.

    Another approach could be to use BOUML just to create the basic structures and from this point on rather utilizing it for technical documentation.

    !!After some use
    After having used BOUML now (August 07) to some extent, Ichthyo notes down his observation:
    # __Assessment__
    #* it is fast, rock stable and complete up to a medium requirement level.
    #* the drawing functions are just basic and insufficient for corporate level demands, just enough for creating design drafts
    #* I miss real world round trip capabilities. Basically, it works fine as long as BOUML is the primary programming environment
    # __Benefits__: setting up new Entities together with all relations and the most important operations is very fast and convienient with bouml. You can get a fairly complete and consistent skeleton of some subsystem much more rapidly than when creating classes from templates in a normal IDE
    # __Drawbacks__: For fleshing out more implementation centric parts, it is seriousely lacking expressiveness, as far as C++ is concerned. This is partially due to the nature of UML. As a warning example, look at the source code of BOUML together with it's  "plugouts". It has about 250kLOC, several thousand source files, most of this caused by duplicating whole class hierarchies, set up in a classificatory manner (which is a big no-no for most modern object oriented programming styles).

    !!!conclusion
    I want to try out the following aproach
    *use it for reasoning about structure
    *use it for setting up all new major entities
    *don't use it for //real programming//