I'm not sure we are talking about the same things really.
On 10/8/07, Bastien <[EMAIL PROTECTED]> wrote:
> "Eddward DeVilla" <[EMAIL PROTECTED]> writes:
>
> > My only real issue is that I tend to think of task dependencies in
> > terms of the other tasks a given task is waiting on rather than what
> > other tasks are waiting on a given task.
>
> Ok, then:
>
> * Task A
> * Task B
> :PROPERTIES:
> :>TODO: {TODO 'previous "DONE"}
> :END:
>
> => becomes TODO when previous tasks is DONE.
I'm not really trying to deal with linear C depends and B which
depends on A type things. Those are easy. I don't really need org to
change the states for me. It's more like, work can't even begin E
until A, C & D are done. Work can't start F until A & B are done.
The reasons for the dependencies could be anything. (Requires a
certain person's time, requires requisite info/result generated in
other/blocking steps, artistic flare) Given a set of such ordering
constraints, and estimated times to complete a step, what is the
soonest a step can be started or completed? Can I use this info to
generate a table of tasks with project start and end dates?
> > This feels a little backward to me, but I could still use it. I'd
> > still have to think about how to use this to make projections, but all
> > the info is there for that.
>
> Sure!
>
> Two ideas again:
>
> 1) one aspect of Org is that it is very *fast*; we can change the TODO
> state of an item with just one keystroke. Making this change trigger
> actions should require some kind of double-check, otherwise we could
> end up with a lot of changes that we're not fully aware of.
>
> One way to check the triggered changes is to build an actions pool
> gathering all actions to be performed, then ask the user if he wants
> to perform them.
>
> 2) In my proposal, the actions are just triggered by TODO state changes.
> But each action could affect or be affected by any property.
>
> * Task A
> :PROPERTIES:
> :COLOR: red
> :END:
>
> * Task B
> :PROPERTIES:
> :>TODO: {COLOR 'previous "green"}
> :END:
>
> => becomes TODO when previous tasks property COLOR is "green".
Again, interesting, but different from where I was going. I'm not
after editing as a side effect. Just planning and organizing. In a
previous message you said it isn't as complex as package dependencies.
I guess what I was after might be.
Edd
_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
