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

List:       koffice-devel
Subject:    Re: Good review in November Linux Magazine
From:       Inge Wallin <inge () lysator ! liu ! se>
Date:       2005-10-17 14:28:26
Message-ID: 200510171628.26516.inge () lysator ! liu ! se
[Download RAW message or body]

On Monday 17 October 2005 16.08, Adam Treat wrote:
> On Sunday 16 October 2005 10:52 am, Inge Wallin wrote:
> > On Saturday 15 October 2005 06.06, Adam Treat wrote:
> > > A few points:
> > >
> > > 1. Kugar as a standalone app does not make sense as it relies upon
> > > other parts to generate a datafile for it to feed on.  No other KOffice
> > > application, besides KPlato that I know of, generates such datafiles...
> > > Datakiosk does and perhaps other outside applications do, but you can't
> > > really blame Kugar for not generating data for you...
> >
> > You *can* blame Kugar for not being able to read the data that *does* get
> > generated, though.  For instance, CSV import would be nice, as would
> > KSpread files, as would other data.
>
> Now Inge, how would you like this to work?  Would you like Kugar to pick
> the data out of KSpread, decide what template to place it in, generate a
> data file and decide _for you_ which fields to present?  Surely you must be
> kidding...

First of all, I might have come across as overly critical and negative.  If 
so, I am sorry. That was not my meaning.  But I stand by my statement that 
kugar should try to be helpful to the other koffice components and to the 
users.

And now to your question:  I see many similarities between kugar and kchart.  
In a way, kchart is also a report generator, but of a different kind.  How 
about if you take the same approach as KChart: define an API and let the 
other components use that to make the reports as they like?

The API to kchart is defined in koffice/interfaces/koChart.{h,cc}.  It 
wouldn't be to difficult to do something similar in koReport, would it?

> > > 3. I want to combine kudesigner part and kugar part into one part, but
> > > this will be after KOffice begins the port to Qt4.  I don't see the
> > > need to do this before.
> >
> > Now you think like a developer.  The users wants this now it seems.  And
> > if you don't want to get bad reviews again when 1.5 is released, you
> > better listen to them.
>
> Well, no, I think like a human being with limited time.  I also work on
> other projects, but with that said I'll try and work on Kugar as time
> permits... Just as I have been doing.  See the commits... :)

No problem there.  We all have limited time, and I am sure you do all that you 
can do.  One thing that would help, perhaps, is to define the above mentioned 
API. Another would be to write down what you want to do / want done, and ask 
for help on the devel list.  I like to delegate work to others, but to do so, 
you have to be clear what needs to be done. If you want help, you should do 
the same.

> > > 4.  I know the Kexi developers are set on developing a replacement,
> > > which is fine, we can evaluate that when it is available.
> >
> > I would say that it would be better to work with them rather than wait
> > them out.  That would be far more productive.
>
> It goes both ways, Inge.  Both ways.

It does indeed.  I don't like the fact that Kexi is doing their own stuff when 
we have something already that could be used as a start.

I imagine that the problem is that Kexi is not only part of KOffice, but they 
will also make their own stand-alone releases.  I guess that's due to the 
business model of OpenOffice Polska (did I get that right?). 

I really hope we can make this work.

	-Inge

-- 
Inge Wallin               | Thus spake the master programmer:               |
                          |      "After three days without programming,     |
inge@lysator.liu.se       |       life becomes meaningless."                |
                          | Geoffrey James: The Tao of Programming.         |
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]