[kplato] projects, subprojects and tasks

[Heiko Evermann]

Hi Thomas, hi everyone,


After some more analysis, this is what I found:

Concerning Milestones:
MrProject does not seem to have them: 
http://www.mrproject.org/user-guide.php does not tell us about them.
MS project has a very simple way of defining milestones: if a task has a 
duration of 0, then it is a milestone. There do not seem to be further 
restrictions. It can be predecessor or successor to other tasks, of 
course. It can even have subtasks. I tried it out. If you have a task A 
with two subtasks B and C and note 0 duration for B and C, then A has a 
duration of 0, too, and all three get displayed as a milestone. That 
means they are displayed as a diamond and the date is displayed.

So my proposal is to drop the class KPMilestone and just to handle tasks 
with zero duration differently in the display. I think this makes things 
easier.

Concerning subtasks:
I am more and more convinced that it would be better  not to use 
KPTProject for Tasks having subtasks, as this makes the object handling 
lot more complicated.

Concerning KPTProject:
At first I thought it might be completely unneccessary. But something 
else is neccessary: I think we ought to have a model for the program, 
following MVC. kdeedu/kstars, for example, hase a model called 
KStarsData, where all application data is collected. Of this we have one 
instance. If we have something like this in kplato, we could even have 
an empty project. Just try this: Run kplato, state that you want to 
start with an empty document. kplato then asks you about project data, 
which is a bit surprising as you stated that you wanted to start with an 
empty document. Cancel that dialog, and you get an almost empty view, in 
pert as in gantt, it just looks a little bit funny. So it would be good 
to have a model for the whole program to work on. This model should be 
able to hold an empty list of tasks to get an empty display in the 
beginning. So far so good. But this model must support adding and 
deleting tasks, so in the end it must be able to do what KPTNode already 
knows to do. Apart from that it should hold other things like author 
information etc. So my conclusion is that the main model best is 
modelled as a subclass of node.

Summary:
* base class KPTNode
* class KPTTask : KPTNode for tasks and subtasks
* class KPTProject : KPTNode for the main model. This does not get 
displayed in the gantt/pert views. For its properties (we might invent 
many) we will have a menu entry: "edit project properties" and a fitting 
dialog.

Some things in the views etc. will have to be changed and some code will 
have to be moved, but not that much. After that, implementing further 
edit capabilities like indent/unindent should be easy.

Comments?

Regards,

Heiko