[kplato] Application Class Structure
John D Lamb
kplato@kde.org
Sun, 15 Jul 2001 21:19:36 +0100
I just saw Thomas Zander's class structure. This is good. I think we
need to be clearer about the difference between time dependency and tree
dependency. Here's an example of activities for a "coffee" project:
A: Make coffee
B: Serve coffee
P: Find cups
Q: Put coffee in cups
R: Put milk in cups
U: Wait for coffee to be ready
V: Read email
W: Put water in machine
X: Put filter in machine
Y: Put coffee in machine
Z: Switch machine on.
Here the basic project is S->A->B->T (tasks on nodes, time dependency,
start node S, end node T both hidden from user). A and B can be split
into subprojects:
/-->W---\ /->U-\ /->Q-\
/ > / > S->P >T
S--->X->Y-->Z--->V-->T \->R-/
The tree structure is:
Coffee project
|
A---------+----------B
| |
+--+--+--+--+--+ +--+--+
| | | | | | | | |
W X Y Z U V Q P R
I think eventually kplato will need both structures, but the time
dependency is more important initially.
Time dependency: I think we should record the dependency as a list in
both nodes. So for example, task Y would have Z as a following node and
Z would have Y as a predecessor. Provided the class structure only
allows dependencies to be added in pairs, I don't think this would be a
problem, even if it's not strict OOP. I don't think we should record
implicit dependencies (e.g. X before U). I think we'd need to allow the
user to put in dependencies like X before Y, Y before Z, Z before X.
Users should be able to put in inconsistencies while developing a
project. We can always check for inconsistencies easily.
Tree dependency: each node has one or zero parents (zero for a projcect)
and each parent has zero or more
children. Initially we don't need to implement this. The tree structure
within the project would not slow the data access much (I think
operations would increase from time f(n) to f(n*log(n))).
JDL