[kplato] Recent progress?

Bo Thorsen kplato@kde.org
Mon, 17 Feb 2003 08:05:52 +0100


=2D----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=
=20
last year. There was some checkins from a guy during the fall, but he=20
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,=20
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=20
loading of files. I basically figured out what XML was and what should be=20
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=20
manipulate the things there to be able to work on fixing the internals.=20

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

Bo.

=2D --=20

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

iD8DBQE+UInQmT99lwfUS5IRAv+UAKDlcFgLXN/D4qwzXASrg4x2Oy85xgCfQbuS
k22r9v46Q70QCSEFKvC++2w=3D
=3D49qU
=2D----END PGP SIGNATURE-----