[kplato] Some code ...

[John D Lamb]

Thomas Zander wrote:
> 
> On Tue, Aug 28, 2001 at 07:56:30AM +0100, John D Lamb wrote:
> >
> > PS I am assuming that if A and B are the two KPTNodes of a KPTRelation,
> > then A->m_parent == B->m_parent. Are you making the same assumption?
> 
> Ehh, no, as I said before the trees are totally seperate.
> ...
> Hope that makes sense..

Ah. Suddenly everything has become perfectly clear. This also explains
why my suggested data structure couldn't make sense to you.

It seems to me that

1. There are some nodes (e.g. milestones) that are just grouping other
   nodes.
2. There are some nodes (e.g. subprojects) where we could reasonably
   assume that for one such node N
   (a) Any KPTRelation joining a node S not in N to a subnode of N could
       join S to N instead.
   (b) Any KPTRelation joining a subnode of N to a node T not in N could
       join N to S instead.
   (c) (a consequence of (a) and (b)) any KPTRelation containing one
       subnode of N, must contain two subnodes of N.

Suppose we call a node of type 1 a Group and a node of type 2 a
Subproject and only allow KPTRelations within Subprojects (any
Subproject would automatically qualify as a group). This could have the
following benefits. A milestone would be a group, the tasks { get
filter, add water, add coffee, switch machine on, wait } would be a
Subproject of tasks for making coffee. I would allow any node other than
a task to contain any number of Groups, which might overlap and consider
all subtasks to be groups.

1. Groups could overlap (I can't actually see why that would help, but
   it might).
2. Faster code through recursive algorithms.
3. Easy to copy a Subproject because keeping its KPTRelations intact
   makes sense.
4. More natural to specify KPTRelation between node S and Subproject T
   than between S and a subnode of T.
5. Deleting a node within a Subproject couldn't invalidate any
   relationships outside the Subproject.
6. Duration makes sense for a Subproject, but not necessarily for a
   group, Start time and End Time for a group make sense.
7. Easy to construct/deconstruct Subprojects by Grouping/ungrouping.
   (I'm imagining a user selecting a group of nodes and creating a
group,
   then asking if it can sensibly be made a subproject.)

The disadvantage would be more complex structure.

I don't think this structure is _necessary_. I think it might be
helpful. It may be useful to get comments from people who would want to
use subprojects.

Any thoughts? 
JDL