Re: Recent progress?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 16 February 2003 19:11, John Lamb wrote:
> Has there been any progress recently on kplato?
>
> I did a CVS build a few days ago and it certainly seems to have
> improved since I last looked. From what I can see, there is not too
> much to do to get kplato to do something useful.

No real progress have happened since I did a little work on it around June 
last year. There was some checkins from a guy during the fall, but he 
quickly stopped working.

> I see two things that are needed to get kplato to the stage where it
> could do a simple project plan.
>
> 1. The GUI needs to allow relations between nodes: i.e. to specify that
> node A (a task, milestone, etc.,) must be done befor node B. I don't
> know what the best way of specifying this within the GUI is, but it
> shouldn't be hard to represent in XML or using KPTRelation.

The problem really is the GUI. In the underlying code and the XML file, 
this is pretty easy to do.

> 2. (Some) nodes must have some time specification: a KPTDuration or
> better a Distribution. Initially, a Fixed distribution could be used,
> but later distributions such as Pert (5th percentile, median, 95th
> percentile), Beta, etc., could be used. The GNU Scientific library
> already has most of the code we'd need.

Probably. I never even got around to start thinking about this part.

> The DTD probably needs some fixing.

Definately! This is a quick mock-up I did to have some basic saving and 
loading of files. I basically figured out what XML was and what should be 
in the file as I did it.

> Although it's probably sensible for
> the GUI to call all nodes tasks this may not be the best representation
> in the DTD because durations are calculated in different ways. I'd
> suggest either
>
> <!ELEMENT node (project|node|task|milestone|relation|resource)*>
>
> and
>
> <!ELEMENT task (distribution|relation|resource)*>
>
> The logic of this is that calculations need to be done recursively
> through the work breakdown structure, starting with the top-level
> project. Nodes (here I'm suggesting tasks) that have no subnodes would
> need to contain a duration (through a distribution). Other nodes just
> calculate values as needed. As an analogy, think of the factorial
> function. Nodes are like positive integers, tasks like zero. The
> function can be defined recursively but there must be different
> treatment for zero so that recursion stops.
>
> An alternative might be to call everything in XML a task:
>
> <!ELEMENT task
> (project|task|milestone|relation|resource)*|distribution)>
>
> This might reflect better the idea that a task could be broken down
> infinitely. When a subtask is added, the distribution is no longer
> needed.
>
> I think the terminal nodes are not needed in the DTD. They are just an
> artefact needed for CPM calculations and both can be created as needed
> from the rest of the project definitions.
>
> I'm happy to help with code (at least concept code ;-)) for anything
> that's needed. Either GUI code or code for the algortithms, though I
> have to admit I've never liked writing GUIs much, even in Qt, which is
> the only thing I've seen in C++ comparable to Java's elegance.

IMHO it's currently a GUI job to work on KPlato. We need to be able to 
manipulate the things there to be able to work on fixing the internals. 

GUI wise it should be interesting to note that in kdepim we (Klarälvdalens 
Datakonsult AB) contributed a full gantt widget. We should be able to use 
this easily.

Bo.

- -- 

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klarälvdalens Datakonsult  |   Denmark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+UInQmT99lwfUS5IRAv+UAKDlcFgLXN/D4qwzXASrg4x2Oy85xgCfQbuS
k22r9v46Q70QCSEFKvC++2w=
=49qU
-----END PGP SIGNATURE-----