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

List:       koffice-devel
Subject:    Re: Good review in November Linux Magazine
From:       Jaroslaw Staniek <js () iidea ! pl>
Date:       2005-10-17 16:25:55
Message-ID: 4353D093.30408 () iidea ! pl
[Download RAW message or body]

Inge Wallin said the following, On 2005-10-17 16:28:

> 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. 

This is not a problem, e.g. it's doable to copy as much code as needed (e.g. 
from kofficelibs) for a given release. See below.

 > I guess that's due to the
> business model of OpenOffice Polska (did I get that right?). 

Not quite. Eg. re. licensing, LGPL is what many of us love in kdelibs. GPL 
apps and libs are now more OK too thanks to qt4-gpl/win32.


Going back to requirements only looks easy when written on paper using general 
statements. I don't think our (at least my) design decisions (especially 
priorities) couldn't be largely "joe-user-complaints-driven". It's too costly, 
unless "Joe" can contribute with reasonable man power. For me, author of the 
article is neither KOffice power user nor KOffice Joe User (besides, maybe we 
have not enough many power users?). But OK, he came from Joe User's 
perspective,  I am not complaining.

Joe User looks at competitor's product (usualy 15+ years in development 
already, within 50+ folks on the board) and compares it to our stuff. Just 
calm down, it's good that ambitious complain.
So answer like "added as TODO with appropriate priority" looks fine to me.

About reusing:
Reusing existing components to save development time may seem fine, if a 
component was designed in similar requirements in mind.... Talking e.g. about 
Kexi, many new modules are designed to be reusable.

OTOH, yeah, more CSV support is what you will probably see in the first place 
in "data exchanging" department.

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska
  Kexi Developer:
      http://www.kexi-project.org | http://koffice.org/kexi
  KDE3, KDE4 libraries for developing MS Windows applications:
      http://wiki.kde.org/tiki-index.php?page=KDElibs+for+win32
_______________________________________________
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]