Welcome to TiddlyWiki created by Jeremy Ruston, Copyright © 2007 UnaMesa Association
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
/***
|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.3)
* 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 (→ glibc)
* std::tr1 — esp. for the former BOOST::shared_ptr (which is now proposed standard)
* BOOST ~~(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..''
//usually, newer versions are OK//
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
! Cinelerra3 design process
A lightweight formalized process how people can add proposals for the Cinelerra3 development.
!! Description
Use the Wiki at http://www.pipapo.org/pipawiki/Cinelerra3/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 Cinelerra3 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).
This is the entry point to several [[TiddlyWiki]]-Pages containing the developer and design documentation for Cinelrra-3.
* Cehteh started GitNotes where we will collect some information about git, howto and special setups
* since we prefer gpg signed tags in git and not each developer knows gpg well here is a Micro-GPG-HowTo
* we maintain (semi-) final design docs in DesignDocumentation
* Things get often worked out on IRC, see IRC-Transcripts for decisions made there and not yet put into the proper documentation places
Please __end your tiddlers in a newline__, this makes merging in git easier since the /pre tag used in tiddlywiki will become on a single line.
----
!Design Draft
to get started, we create design drafts emphasizing different aspects and regions of Cinelerra-3
* Ichthyo focuses mainly on the Render Engine and its interconnection to the EDL, [[see this separate page|renderengine.html]]
* Cehteh works on the data backend draft, see [[this page|backend.html]]
* Some tools which don't fit somewhere else and are used everywhere are put into a [[Support Library|support_library.html]]
* [[Description of the Test System|TestSh]]
!Coding Structures
next we should //start thinking// on how to organize several aspects of the practical coding...
* what to do in BOUML? → [[more|whatInBOUML]]
* how to organize packages, files, includes? → [[more|SrcTreeStructure]]
* how to organize the executable to be built?
* what coding conventions to prefer? → [[GNU Style|DesignDocumentation]]
* what [[build system|BuildSystem]] to use?
* various [[build dependencies|BuildDependenceis]]
* TestSuite
* There is a [[Manifest]] explaining the vision of the Cinelerra3 project
* The foundation how we work together is defined in Cinelerra3DesignProcess
* 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 | |Cinelerra3 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.
→ see [[Interesting Branches|GitBranches]]
This part should explain what you have to do in order to download the sources of Cinelerra3 (cin3) 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/cinelerra3/ct YOURCOPY'sNAME
//}}}
This will create a directory named YOURCOPY'sNAME which contains the whole data of the cinelerra3/ct branch of Cinelerra3. 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. Note e.g. the 3 in cinelerra3
* Install git before calling git
Now you could compile the source code or improve Cinelerra3 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/cinelerra3/mob
//}}}
cinelerra3/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
* [[1.official developer meeting 1.Feb.2008|IRC_2008-02-01]]
* [[informal developer meeting 10.Aug.2007|IRC_2007-08-10]]
!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 diffrent libraries anyway (ffmpeg, v4l, gstreamer, ...)
* we need a pool of worker threads and associated api's
* 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 ''attachement 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 themselfes of course //is// a reconfig.
* 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 'wireing' 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 processings...
*** the node objects themselfs should stay stateles, 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 aproach), 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/Cinelerra3/DesignProcess — do we need this formalism?
At start of the project last summer, Cehteh made a [[design process proposal|http://www.pipapo.org/pipawiki/Cinelerra3/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 — 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 — esp. when it fits into the core focus of the project — 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 — 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/Cinelerra3/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 — this swapout and size of temporary data is to be monitored and adjusted according to the current load — 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/Cinelerra3/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
/***
''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;
}
}
} )
//}}}
GettingStarted
[[Cinelerra3Wiki]]
[[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 Cinelerra3.
!! 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
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 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>>Cinelerra 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 Cinelerra''<<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>Cinelerra 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>
<span class='siteSubtitle' refresh='content' tiddler='SiteSubtitle'></span>
</div>
<div class='headerForeground'>
<span class='siteTitle' refresh='content' tiddler='SiteTitle'></span>
<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 tiddler 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 cinelerra3 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/cinelerra3 : cinelerra3 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 cinelerra 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 cinelerra 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.com/#MainFeatures]]
*
----
<<search>><<closeAll>><<permaview>><<newTiddler>><<saveChanges>><<slider chkSliderOptionsPanel OptionsPanel "options »" "Change TiddlyWiki advanced options">>
Distributed Developer Wiki
/***
''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 cinelerra 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 Cinelerra 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.com/#MainFeatures]]
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 »good code« 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//