[kplato] Data structures etc.

[John D Lamb]

Some thoughts. A lot of this is just saying I think many issues can be
resolved by keeping application and interface separate.

Tree structure
==============
I don't see any real difficulty in containing a tree structure in a
Project by using polymorphism to allow a distinction between tasks and
subtasks (and subprojects) or anything else. We can start with trees of
depth one (i.e. no subtasks).
There's one thing I still haven't grasped about (Jim Sabatke's)
subtasks: are they inevitable from the project structure (I can see one
way of defining subtasks from any project) or are they defined by the
project user?

Map (or digraph or directed graph or dependency structure)
==========================================================
I don't see any difficulty in storing this is the Project class. I think
the dependencies as defined by
the user should be kept separate from any implicit dependencies, which
might be calculated or stored as private class members. I don't think we
want to confuse a user by generating automatically a set of dependencies
different from theirs, even if it is a simpler set.

Data structure
==============
When I've seen a few more comments, I'll try to generate some *.h files
for classes that generate a plausible first stab at a data structure.
I'll try to indicate public member functions that could return
say a tree or map or xml representation of a project.

CVS and build
=============
I think CVS is essential. Is there anyone on the list who really knows
the GNU and KDE build system? i.e. more comfortable than me on automake,
autoconf, tmake, etc. That would help too.

Resources
=========
I think these could wait, but it would be useful to get ideas on how
they might eventually be used. I'd suggest creating a dummy Resource
class and giving each task initially an empty STL vector of Resource
pointers.

Concurrency
===========
Will the GUI handle all concurrency issues? The application functions
will need to be synchronized.

JDL