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

List:       koffice-devel
Subject:    Re: ODF Weekend: the vision
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2007-05-10 17:55:27
Message-ID: 200705101955.27667.mail () dipe ! org
[Download RAW message or body]

On Thursday 10 May 2007 16:45, Thomas Zander wrote:
> On Thursday 10 May 2007 16:05:51 Inge Wallin wrote:
> >  Perhaps we should come up with a cool name for this technology.
>
> Its called Flake ')

or Kross :) nah, just joking even if it's already in use;
http://techbase.kde.org/Development/Tutorials/SuperKaramba#Connect_with_KSpread
For sure it's not the best solution or something that fits all needs, etc. and 
also it's very hacky (scripting, not very type-safe, a pure C++ lib is 
better, etc.). But I guess if we take all those use-cases into account we may 
have an idea how complex such a solution needs to be. So, where I see 
currently use-cases are;
* Okular likes to display and probably allows to search and extract content 
(and I really ask me, if Flake doesn't already provide all this?)
* SuperKaramba likes to be as flexible as possible via scripting what includes 
reading+writing+manipulation of such files (Kross does it, dbus too, do we 
need more here?)
* KPrint(er) may like to optional print content to ODT-files.
* since we will have a few kdepim-devels with us, are there use-cases they 
would like to have like e.g. beeing able to use KSpread formulas within 
KOrganizer (ok, stupid example) or...?

I also see some more general questions like;
* is it really only about opendocument import/export or even about 
functionality like beeing able to read a template, fill it with content and 
save it again or like allowing other apps to reuse the KSpread formula-engine 
or...?
* and most interesting to me: how can that be done without breaking everything 
again? imho the biggest priority should be to get things working again and 
not to start even more bigger refactors right before the first release... I 
guess this means, that we need to keep steps small and try to provide a 
solution with our current codebase and just extend it where needed.

-- 
Sebastian Sauer aka dipesh[sebsauer]
http://www.dipe.org/public_key.asc
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder in http://www.koffice.org && http://www.kmldonkey.org
_______________________________________________
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]