Hi! I figured it out. For example: These conditions must be fulfilled in order for Task8 to be active: <<list filter "[tag[Task8 AND active_Task8 AND NOT (Task1 AND active_Task1) AND NOT (Task2 AND active_Task2) AND NOT (Task3 AND active_Task3) AND NOT (Task4 AND active_Task4) AND NOT (Task5 AND active_Task5) AND NOT (Task6 AND active_Task6) AND NOT (Task7 AND active_Task7) AND NOT finished_Task8 AND NOT Completed AND NOT Archived]]">
These conditions must be fulfilled in order for Task3 to be active: <<list filter "[tag[Task3 AND active_Task3 AND NOT (Task1 AND active_Task1) AND NOT (Task2 AND active_Task2) AND NOT finished_Task3 AND NOT Completed AND NOT Archived]]"> I have a table with a list of tasks for header and in each column is a corresponding list of projects with active corresponding task. By default, all projects are tagged active_TaskX. I use Eric's CheckboxToggleTag (http://www.TiddlyTools.com/#CheckboxToggleTag) to first set the tag TaskX and when that task is complete, I toggled active_TaskX off and replace it with finished_TaskX. I have 8 tasks and they always follow the same order, but they're not always all used. Oh yeah, I switched to fET, but the principle is the same. w On Aug 28, 11:42 pm, Tobias Beer <[email protected]> wrote: > Hi w, > > First question: Why tag a task with itself? > > Furthermore, I NEVER tag a high-level item (e.g. a project) with its > subitems (e.g. tasks). I would strongly recommend that you tag your > tasks with the corresponding project, not the other way around! > > Also, whether a task is finished or open is independent form it's > name. Therefore, you should have two more tags indicating a task- > status: "todo" and "done". In tbGTD [1] I went so far as to prefix > certain tags for easier recognition. Thus, there are #todo, #done, > #waiting, etc... with # indicating that these are task-status-tags. > Likewise I would have $active or $future or $completed as project- > status-tags. > > Finally, other than you knowing about it, I fail to see how exactly > you are modeling task-dependencies. As for that I would simply tag a > task with another task and thus have the latter depend on the > former ...just like high level items ((sub-)projects) depend on > subitems (tasks). > > What do you mean with "the sequence of tasks is always the same"? I > prefer to think in stages and thus have tasks not only tag to a > project but also to a "stage", such that one might only get from one > stage to another if the previous stage had been completed, think > "milestones". So, a stage 1 task for project A might be equivalent to > a stage 1 task of project B, but they're not called the same as that > would violate TiddlyWiki's unique naming conventions. Therefore, have > them tag to a stage of a unique name and you know what point in the > project you're at. > > Eventually you might want a table for project xyz to look like this... > > |open tasks|done tasks|h > |open tasks for stage 1 of project xyz|done tasks for stage 1 of > project xyz| > |open tasks for stage 2 of project xyz|done tasks for stage 2 of > project xyz| > |etc...|p.p...| > > No offense, but unless you're no longer in a design stage of your task > management you might want to consider designing it from scratch. > > Eventually, (especially x-tab of) tbGTD may really be of help to you > (see toolbar or help documentation). > > Cheers and good luck, > > Tobias. > > [1]http://tbgtd.tiddlyspot.com/ -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
