[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kplato
Subject:    Re: [kplato] [Planner Dev] Planner maintainership
From:       Dag Andersen <danders () get2net ! dk>
Date:       2005-10-26 7:21:00
Message-ID: 200510260921.02056.danders () get2net ! dk
[Download RAW message or body]

On Fredag 21 oktober 2005 15:02, Thomas Zander wrote:
> On Friday 21 October 2005 09:47, Dag Andersen wrote:
> > > So, I would be open to discuss merging of any (open source)
> > > project management applications and would be very happy if
> > > human resources could be brought together.
> >
> > Just for the record, I'm not against merging KPlato with
> > TaskJuggler, but as you noted above Raphael, the approach is very
> > different, so imho it won't be a piece of cake to do, especially
> > before release of 1.5.
>
> I'm a bit weary of trying a merge. Initially it looks nice but
> unless we intend to just cannibalize TJ for cool code any result we
> get from a merge will either make us or the TJ people extremely
> unhappy.
>
> The thing is; the reason KPlato is in KOffice is because we wanted
> to make data from kspread/kexi available to KPlato. Think resources
> being updated while you enter some numbers in your spreadsheet.
> On the output side KPlato can use KChart (which can be extended if
> needed) and use those charts in a presenter or KWord doc.
Are there any thoughts on *how* data transfer should be implemented?
It would be nice for instance, to be able to harvest data from kplato 
project(s) and/or kexi database(s) into kspread for further 
processing, or instead of using QListView/QTable with 
fixed/preprocessed data, embed kspread giving the user a possibility 
to tailor dataprocessing/presentation.
>
> Or, in other words, a planner tool in and of itself is kind of
> useless; you have to provide data to it and use the date coming out
> of it. Corporation with other people simply needs that.
> This is where KPlato will shine as KOffice will provide a whole
> workflow instead of an app to get your data out of.
>
> Back to taskjuggler;  their approach is very different from the one
> I described above.  The GUI on top of TJ also does not even try to
> follow the workflow options KOffice can offer.
> This leads me to conclude that merging will result in a very weird
> monstrosity that neither the koffice people nor the TJ people will
> appreciate.
>
> Naturally; if the TJ people can subscribe to the KOffice point of
> view; great!  I'm just not holding my breath :)
>
> > A note on TaskJugglers fileformat: It's designed to easily be
> > read/edited by humans (it's really their user interface) so
> > imvvho I don't think they will ever have a native XML based
> > format. (But maybe a conversion tool?)
>
> Yeah; the creation of a good and common file format would be the
> major thing to do right now.  I'm sure that the TJ people would be
> able to read and write to any xml-based fileformat we come up with
> (as long as its extendible) via some converter or filter plugin to
> TJ.
>
> Cheers!

-- 
Mvh,
Dag Andersen
_______________________________________________
kplato mailing list
kplato@kde.org
https://mail.kde.org/mailman/listinfo/kplato
[prev in list] [next in list] [prev in thread] [next in thread]