List of open questions, notes on BOUML, some page tagging.
While refining the renderengine model, I came accros some difficult questions I can't quite decide at the moment
This commit is contained in:
parent
049c5e252b
commit
014106f2a8
4 changed files with 75 additions and 210 deletions
1
wiki/.gitignore
vendored
Normal file
1
wiki/.gitignore
vendored
Normal file
|
|
@ -0,0 +1 @@
|
|||
tmp/*
|
||||
|
|
@ -747,6 +747,17 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS
|
|||
}
|
||||
//}}}</pre>
|
||||
</div>
|
||||
<div title="BuildSystem" modifier="Ichthyostega" modified="200708051534" created="200708051532" tags="organization buildsys" changecount="3">
|
||||
<pre>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")
|
||||
* provide central interface for setting switches and configuration options
|
||||
* installing of some or all created artifacts</pre>
|
||||
</div>
|
||||
<div title="Cinelerra3DesignProcess" modifier="MichaelPloujnikov" modified="200706270317" created="200706181202" tags="process" changecount="5">
|
||||
<pre>! Cinelerra3 design process
|
||||
A lightweight formalized process how people can add proposals for the Cinelerra3 development.
|
||||
|
|
@ -784,7 +795,7 @@ This distributed wiki might be used instead the pipapo.org wiki, investigate tha
|
|||
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).
|
||||
</pre>
|
||||
</div>
|
||||
<div title="Cinelerra3Wiki" modifier="CehTeh" modified="200707102257" created="200706172308" tags="portal" changecount="19">
|
||||
<div title="Cinelerra3Wiki" modifier="Ichthyostega" modified="200708051525" created="200706172308" tags="portal" changecount="21">
|
||||
<pre>This 'index.html' becomes the entry point of some tiddlywikis managed under git. There is a 'empty.html' in the same folder serving as template for generating new wikis. Please refrain from editing it.
|
||||
|
||||
* I started a GitNotes where we will collect some information about git, howto and special setups
|
||||
|
|
@ -806,7 +817,7 @@ next we should //start thinking// on how to organize several aspects of the prac
|
|||
* how to organize packages, files, includes? &rarr; [[more|SrcTreeStructure]]
|
||||
* how to organize the executable to be built?
|
||||
* what coding conventions to prefer? &rarr; [[GNU Style|DesignDocumentation]]
|
||||
* what build system to use?
|
||||
* what [[build system|BuildSystem]] to use?
|
||||
|
||||
Ichthyo thinks we should do some informal brainstorming, test/prototypes to see how things work out and discuss them; then we should make them into formal project proposals on pipapo.org
|
||||
</pre>
|
||||
|
|
@ -815,7 +826,7 @@ Ichthyo thinks we should do some informal brainstorming, test/prototypes to see
|
|||
<pre>Cinelerra3Wiki
|
||||
ShortCuts</pre>
|
||||
</div>
|
||||
<div title="DesignDocumentation" modifier="CehTeh" modified="200707030409" created="200706181207" tags="process" changecount="6">
|
||||
<div title="DesignDocumentation" modifier="CehTeh" modified="200707030409" created="200706181207" tags="process policy" changecount="6">
|
||||
<pre>* 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
|
||||
|
|
@ -894,7 +905,7 @@ Slider.prototype.stop = function()
|
|||
}
|
||||
//}}}</pre>
|
||||
</div>
|
||||
<div title="GitAliases" modifier="MichaelPloujnikov" modified="200706270309" created="200706181050" changecount="5">
|
||||
<div title="GitAliases" modifier="MichaelPloujnikov" modified="200706270309" created="200706181050" tags="git organization" changecount="5">
|
||||
<pre>to make the admin/git_hooks/post-commit working add following to your .gitconfig:
|
||||
{{{
|
||||
[alias]
|
||||
|
|
@ -908,7 +919,7 @@ these two commands are used by 'admin/git-hooks/post-commit'
|
|||
|
||||
'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.</pre>
|
||||
</div>
|
||||
<div title="GitBranches" modifier="MichaelPloujnikov" modified="200706270309" created="200706260447" tags="overview" changecount="9">
|
||||
<div title="GitBranches" modifier="Ichthyostega" modified="200708051534" created="200706260447" tags="overview git organization" changecount="11">
|
||||
<pre>some ''interesting Branches''
|
||||
|
||||
|![[pipapo.org|PipapoOrg]] |!''mirrored'' |!|!description |
|
||||
|
|
@ -917,7 +928,7 @@ these two commands are used by 'admin/git-hooks/post-commit'
|
|||
|
||||
</pre>
|
||||
</div>
|
||||
<div title="GitNotes" modifier="MichaelPloujnikov" modified="200706270308" created="200706181049" tags="note" changecount="4">
|
||||
<div title="GitNotes" modifier="MichaelPloujnikov" modified="200706270308" created="200706181049" tags="note git" changecount="4">
|
||||
<pre>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.
|
||||
|
|
@ -958,7 +969,7 @@ Now you could compile the source code or improve Cinelerra3 or the documentation
|
|||
!!!Code
|
||||
//{{{
|
||||
git config --global user.name "YOUR REALNAME"
|
||||
git config --global user.email YOUR-E@MAIL.ADRESS
|
||||
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
|
||||
//}}}
|
||||
|
|
@ -2296,8 +2307,8 @@ if (oldText.indexOf("SplashScreen")==-1)
|
|||
}
|
||||
//}}}</pre>
|
||||
</div>
|
||||
<div title="SrcTreeStructure" modifier="CehTeh" modified="200706270059" created="200706262157" changecount="2">
|
||||
<pre>* 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.
|
||||
<div title="SrcTreeStructure" modifier="CehTeh" modified="200706270059" created="200706262157" tags="organization" changecount="2">
|
||||
<pre>* 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.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="StyleSheet" modifier="Ichthyostega" modified="200706260503" created="200701131624" tags="MPTWTheme excludeMissing" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200706090017" changecount="1">
|
||||
|
|
@ -3492,12 +3503,27 @@ function addKeyDownHandlers(e)
|
|||
* see GettingStarted
|
||||
* see [[Homepage|http://tiddlywiki.com]]</pre>
|
||||
</div>
|
||||
<div title="whatInBOUML" modifier="Ichthyostega" created="200706260559" changecount="1">
|
||||
<pre>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 develope the method bodies //conventionally// with a text editor.
|
||||
<div title="whatInBOUML" modifier="Ichthyostega" modified="200708051535" created="200706260559" tags="discuss policy" changecount="3">
|
||||
<pre>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 seceptical about this aproach. While it probably will work, it is questionable if it will result in &raquo;good code&laquo; the fear is, that this rigid hierarchical structure distracts from the more complex semantical concerns.
|
||||
__Ichthyo__ tends to be sceptical about this approach. While it probably will work, it is questionable if it will result in &raquo;good code&laquo; the fear is, that this rigid hierarchical structure distracts from the more complex semantical concerns.
|
||||
|
||||
Another aproach could be to use BOUML just to create the basic structures and from this point on rather utilizing it for technical documentation.</pre>
|
||||
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//</pre>
|
||||
</div>
|
||||
</div>
|
||||
<!--POST-STOREAREA-->
|
||||
|
|
|
|||
|
|
@ -1914,6 +1914,30 @@ DAMAGE.
|
|||
<div title="PrimaryPale" modifier="just me" created="200706220427" changecount="1">
|
||||
<pre>{{red{killme}}}</pre>
|
||||
</div>
|
||||
<div title="ProblemsTodo" modifier="Ichthyostega" modified="200708050630" created="200708050524" tags="design discuss" changecount="8">
|
||||
<pre>Open issues, Things to be worked out, Problems still to be solved...
|
||||
|
||||
!!Parameter Handling
|
||||
The requirements are not quite clear; obviously Parameters are the foundation for getting automation right and for providing effect editing interfaces, so it seems to me we need some sort of introspection, i.e. Parameters need to be discovered,
|
||||
enumerated and described at runtime.
|
||||
|
||||
!!Treatment of Time (points) and Intervals
|
||||
At the moment we have no clear picture what is needed and what problems we may face in that domain.
|
||||
From experience, mainly with other applications, we can draw the following conclusions
|
||||
* drift and rounding errors are dangerous, because time in our context usually is understood as a fixed grid (Frames, samples...)
|
||||
* fine grained time values easily get very large
|
||||
* Cinelerra currently uses the approach of simply counting natural values for each media type separately. In an environment mixing several different media types freely, this seems a bit too simplistic (because it actually brings in the danger of rounding errors, just think at drop frame TC)
|
||||
|
||||
!!Organizing of Output Channels
|
||||
How to handle the simultaneous rendering of several output streams (video, audio channels). Shall we treat the EDL as one entity containing different output channels, or should it rather be seen as a composite of several sub-~EDLs, each for only one output channel? This decision will be reflected in the overall structure of the network of render nodes: We could have a list of channel-output generating pipelines in each processor (for every segment), or we could have independently segmented lists of Processors for every output channel/type. The problem is, //it is not clear what approach to prefer at the moment// because we are just guessing.
|
||||
|
||||
!!Tracks, Channels, Layers
|
||||
Closely related to this is the not-so-obvious problem how to understand the common global structures found in most audio and video editing applications. Mostly, they stem from imitating hardware recording and editing solutions, thus easing the transition for professionals grown up with analog hardware based media. But as digital media are the de-facto standard nowadays, we could have a look at all those accidental complexity introduced by sticking to the hardware tool metaphor.
|
||||
* is it really necessary to have fixed global tracks?
|
||||
* is it really helpful to feed "source tracks" into global processing busses/channels?
|
||||
Users accustomed with modern GUI applications typically expect that //everything is a object// and can be pulled around and manipulated individually. This seems natural at start, but raises the problem of providing a efficient workflow for handling larger projects and editing tasks. So, if we don't have a hard wired multitrack+bus architecture, we need some sort of templating to get the standard editing use case done efficiently.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="ProcNode" modifier="MichaelPloujnikov" modified="200706271500" created="200706220409" tags="def" changecount="3">
|
||||
<pre>A data processing node within the Render Engine. Its key feature is the possibility to pull from it one (freely addressable) [[Frame]] of calculated data. Further, each ~ProcNode has the ability to be wired with other nodes and [[Parameter Providers|ParamProvider]]
|
||||
</pre>
|
||||
|
|
@ -2132,7 +2156,7 @@ config.macros.rssFeedUpdate = {
|
|||
//}}}
|
||||
</pre>
|
||||
</div>
|
||||
<div title="RenderEngine" modifier="MichaelPloujnikov" modified="200706271423" created="200706190056" tags="overview" changecount="38">
|
||||
<div title="RenderEngine" modifier="Ichthyostega" modified="200708050630" created="200706190056" tags="overview" changecount="40">
|
||||
<pre>The Render Engine is the part of the application doing the actual video calculations. Its operations are guided by the Objects and Parameters edited by the user in [[the EDL|EDL]] and it retrieves the raw audio and video data from the [[Data backend|backend.html]]. Because the inner workings of the Render Engine are closely related to the structures used in the EDL, this design covers [[this aspect|MObjects]] as well.
|
||||
|
||||
The key idea of Ichthyo's Design-draft is to use the [[Builder Pattern|http://en.wikipedia.org/wiki/Builder_pattern]] for the Render Engine, thus separating completely the //building// of the Render Pipeline from //running,// i.e. doing the actual Render. The Nodes in this Pipeline should process Video/Audio and do nothing else. No more decisions, tests and conditional operations when running the Pipeline. Move all of this out into the configuration of the pipeline, which is done by the Builder.
|
||||
|
|
@ -2155,7 +2179,8 @@ The design of Cinelerra 2 basically follows this design, but __fails because of
|
|||
&rarr; BuildProcess
|
||||
&rarr; RenderProcess
|
||||
&rarr; [[Two Examples|Examples]] (Object diagrams)
|
||||
&rarr; how [[Automation]] works {{red{to be defined in more detail}}}
|
||||
&rarr; how [[Automation]] works {{red{to be defined in more detail}}}
|
||||
&rarr; [[Problems|ProblemsTodo]] {{red{to be solved}}}
|
||||
</pre>
|
||||
</div>
|
||||
<div title="RenderEntities" modifier="Ichthyostega" modified="200706220406" created="200706190715" changecount="6">
|
||||
|
|
|
|||
|
|
@ -498,127 +498,6 @@ Also see AdvancedOptions</pre>
|
|||
</div>
|
||||
<!--POST-SHADOWAREA-->
|
||||
<div id="storeArea">
|
||||
<div title="1. The basics of the task macro" modifier="CehTeh" modified="200706100740" created="200604082224" tags="TaskMacroTutorial" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200706100740">
|
||||
<pre>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>></pre>
|
||||
</div>
|
||||
<div title="2. More advanced use of the task macro" modifier="LukeBlanshard" modified="200604090319" created="200604082349" tags="TaskMacroTutorial" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200604090319">
|
||||
<pre>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>></pre>
|
||||
</div>
|
||||
<div title="3. The taskadder macro: add tasks easily" modifier="LukeBlanshard" modified="200605020243" created="200604082241" tags="TaskMacroTutorial" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200605020243">
|
||||
<pre>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>></pre>
|
||||
</div>
|
||||
<div title="4. The tasksum macro: summarize tasks" modifier="LukeBlanshard" modified="200605020248" created="200604082241" tags="TaskMacroTutorial" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200605020248">
|
||||
<pre>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>></pre>
|
||||
</div>
|
||||
<div title="5. Task macro installation issues" modifier="LukeBlanshard" modified="200605132015" created="200604082243" tags="TaskMacroTutorial" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200605132015">
|
||||
<pre>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>></pre>
|
||||
</div>
|
||||
<div title="Admin" modifier="CehTeh" modified="200706110324" created="200706080535" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200706110324">
|
||||
<pre>PageTemplate
|
||||
|>|SiteTitle - SiteSubtitle|
|
||||
|
|
@ -747,7 +626,7 @@ config.macros.timeline.handler = function(place,macroName,params,wikifier,paramS
|
|||
}
|
||||
//}}}</pre>
|
||||
</div>
|
||||
<div title="ColorPalette" modifier="CehTeh" modified="200707111058" created="200707102303" changecount="7">
|
||||
<div title="ColorPalette" modifier="CehTeh" modified="200707111058" created="200707102303" tags="excludeMissing" changecount="7">
|
||||
<pre>Background: #fff
|
||||
Foreground: #000
|
||||
PrimaryPale: #ec5
|
||||
|
|
@ -767,7 +646,7 @@ Error: #f88</pre>
|
|||
<div title="DefaultTiddlers" modifier="CehTeh" modified="200707102306" created="200707102301" changecount="2">
|
||||
<pre>[[SupportLibrary]]</pre>
|
||||
</div>
|
||||
<div title="ErrorHandling" modifier="MichaelPloujnikov" modified="200707160333" created="200707152252" changecount="4">
|
||||
<div title="ErrorHandling" modifier="MichaelPloujnikov" modified="200707160333" created="200707152252" tags="excludeMissing" changecount="4">
|
||||
<pre>! Proposal:
|
||||
We need some centralized way to handle errors and doing hard aborts.
|
||||
|
||||
|
|
@ -1216,14 +1095,14 @@ SupportLibrary
|
|||
<<fullscreen>>
|
||||
</pre>
|
||||
</div>
|
||||
<div title="MarkupPreHead" modifier="CehTeh" created="200706191948">
|
||||
<div title="MarkupPreHead" modifier="Ichthyostega" modified="200708051444" created="200706191948" tags="excludeMissing" changecount="1">
|
||||
<pre><!--{{{-->
|
||||
<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>My TiddlyWiki</b> is loading<blink> ...</blink><br><br><span style="font-size: 14px; color:red;">Requires Javascript.</span></div></pre>
|
||||
</div>
|
||||
<div title="PageTemplate" modifier="CehTeh" modified="200706110330" created="200701131624" tags="MPTWTheme" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200706110330">
|
||||
<div title="PageTemplate" modifier="CehTeh" modified="200706110330" created="200701131624" tags="MPTWTheme excludeMissing" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200706110330">
|
||||
<pre><!--{{{-->
|
||||
<div class='header' macro='gradient vert [[ColorPalette::PrimaryLight]] [[ColorPalette::PrimaryMid]]'>
|
||||
<div class='headerShadow'>
|
||||
|
|
@ -1748,7 +1627,7 @@ DAMAGE.
|
|||
<html><sub><a href="javascript:;" onclick="scrollAnchorVisible('Top',null, event)">[Top]</sub></a></html>
|
||||
***/</pre>
|
||||
</div>
|
||||
<div title="PluginInterfaceDefinition" modifier="MichaelPloujnikov" modified="200707160400" created="200707111319" changecount="19">
|
||||
<div title="PluginInterfaceDefinition" modifier="MichaelPloujnikov" modified="200707160400" created="200707111319" tags="excludeMissing" changecount="19">
|
||||
<pre>Interfaces are declared in header files. They use some tool macros to give a convenient definition language.
|
||||
|
||||
! Thoughts
|
||||
|
|
@ -1804,7 +1683,7 @@ struct cinelerra_interface_foo_2
|
|||
};
|
||||
}}}</pre>
|
||||
</div>
|
||||
<div title="PluginInterfaceImplementation" modifier="MichaelPloujnikov" modified="200707160355" created="200707111749" changecount="10">
|
||||
<div title="PluginInterfaceImplementation" modifier="MichaelPloujnikov" modified="200707160355" created="200707111749" tags="excludeMissing" changecount="10">
|
||||
<pre>A Plugin realizes an interface. This means that actual functions are mapped to the correspondending slots in the interface structure.
|
||||
|
||||
{{{
|
||||
|
|
@ -1869,7 +1748,7 @@ Note: the protoname and version args for ~CINELERRA_INTERFACE_FUNC will be used
|
|||
|
||||
</pre>
|
||||
</div>
|
||||
<div title="PluginLibrary" modifier="MichaelPloujnikov" modified="200707160351" created="200707111329" changecount="33">
|
||||
<div title="PluginLibrary" modifier="MichaelPloujnikov" modified="200707160351" created="200707111329" tags="excludeMissing" changecount="33">
|
||||
<pre>! Cinelerra Plugin API
|
||||
|
||||
There are only a few functions to manage Plugins. Actually a user requests interfaces. The libraries which implement Plugins are managed transparently.
|
||||
|
|
@ -2233,72 +2112,6 @@ config.macros.rssFeedUpdate = {
|
|||
};
|
||||
|
||||
//}}}
|
||||
</pre>
|
||||
</div>
|
||||
<div title="RSSReaderPluginDoc" modifier="BidiX" modified="200704220857" created="200704132051" tags="Doc RSSReader" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200704220857">
|
||||
<pre>//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
|
||||
|
||||
|
||||
</pre>
|
||||
</div>
|
||||
<div title="SiteSubtitle" modifier="CehTeh" modified="200707111059" created="200707102305" changecount="2">
|
||||
|
|
@ -2365,7 +2178,7 @@ if (oldText.indexOf("SplashScreen")==-1)
|
|||
}
|
||||
//}}}</pre>
|
||||
</div>
|
||||
<div title="StyleSheet" modifier="CehTeh" modified="200706090017" created="200701131624" tags="MPTWTheme" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200706090017">
|
||||
<div title="StyleSheet" modifier="CehTeh" modified="200706090017" created="200701131624" tags="MPTWTheme excludeMissing" server.type="file" server.host="file:///home/ct/.homepage/home.html" server.page.revision="200706090017">
|
||||
<pre>/*{{{*/
|
||||
/* a contrasting background so I can see where one tiddler ends and the other begins */
|
||||
body {
|
||||
|
|
|
|||
Loading…
Reference in a new issue