Thomas Zander wrote:

> On Tuesday 30. June 2009 21.11.04 Adam Pigg wrote:
>> we dont (cant/wont :) seem to have come to a consenesus yet :/
> 
> oh, sorry about that, Jaroslaw gave a great suggestion that nobody will
> disagree with (well, nobody did) just that there needs to be a volunteer.
> That may explain the lack of replies.
> 
>> on irc, slangkamp doesnt think libkoodf if the right place for handling
>> high level functions such as books/sheets/cells (or documents/paragraphs
>> i guess/pages/slides).
> 
> Maybe a misunderstanding, what we talked about in Berlin 1½ years ago when
> we decided on having a libodf was that we provide a set of features that
> allow 3rd party apps to use ODF easier.
> Naturally that means the existing functionality (kostore) but also more.
> One of the things we concluded was that we wanted basic functionality to
> make it
> really easy to write things like a simple spreadsheet.  NOT functions or
> calculations, just data.
> 
> I think that last distinction is where the opinions differed. The simple
> functionality should be lightweight to add to libodf without dragging half
> kspread in.
> 
>> Where does that leave us?
> 
> With libodf.
> Exactly like Jaroslaw described (not quoted in this email)
> 
>> 1. Continue linking to libkspreadcommon (which with correct packaging
>> shouldnt be a problem i think)
> 
> Why do you think its not a problem? There are different people that
> already pointed out it has severe problems. Indeed the first reply on this
> thread said so.
> Lets not re-do that discussion down here in this thread ;)
> 
>> 2. Linking to 'some other library' which can provide a similar function
> 
> Like libodf.
> But using a file in interfaces might help to. I'm sure I wrote that in an
> email here somewhere too.
> 
>> 3. Writing a higher level library above libkoodf to provide high level
>> api's for creating documents
> 
> Which is similar to the Jaroslaw solution. I think that we can just have
> those inside libodf, to be honest. But I'm certainly fine with it living
> above at least initially.
> 
>> Suggestions?
> 
> I think the main reason there was no conclusion is because the one who
> does th work decides. And I won't tell you which option to pick ;)
> The reason for this thread was certainly not to tell you how to do the
> work, the main reason for the length of this thread is because the one
> solution we have now has given us a lot of headaces in the past and we
> don't want to have that again in KOffice.
> 
> So, my suggestion is; any solution that works for you as long as its not
> linking to more than one app.
> 
> Hope that helps :)

Yes, that helps (apart from the fact the job size has increased a hundred 
fold :)

So...basically, libkoodf needs features to read/write to an ods, using an 
api that represents a spreadsheet (book/sheet/cell).

Now, the problem is that it is a bit of a huge task, and if im honest, quite 
daunting, i have no idea what is needed, and no idea what would be 
acceptable as a design, api or featureset.

Perhaps you 'core' devs would be able to write something up on the wiki?

Would it be a start to 'borrow' code from kspread?

I do this as a hobby, i have a day job, wife and 4 (really) kids, so you 
would have to bear with me if it takes a while :)

Cheers



_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel