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

List:       koffice-devel
Subject:    Re: KOffice 2.0 plan for object embedding.
From:       "Robert Knight" <robertknight () gmail ! com>
Date:       2006-07-14 13:55:33
Message-ID: 13ed09c00607140655s3dc9679ar1650cf82ae8579b0 () mail ! gmail ! com
[Download RAW message or body]

Hi,

I'm sorry to ask a stupid question, but what is the practical benefit
of this for our users?  What would a KSpread flake give them that
isn't already available via the KoParts system?

Regards
Robert.

On 14/07/06, Tomas Mecir <mecirt@gmail.com> wrote:
> On 7/14/06, Thomas Zander <zander@kde.org> wrote:
> > To be clear; its perfectly ok to remove any cell-data outside the given
> > range.
> >
> > And I fully expect the full kspread to be loaded anyway. This is not about
> > stripping down kspread, this is about creating a different way to show
> > the cells-data.
> > For example; I expect the kspread shape to live in a subdir and to create
> > a plugin file (kspread_flake.a) by extending KoShape and having as one of
> > its members the data structure required for holding the data of the
> > visible cells.
> > It would use the kspread core library to access that data and it would use
> > the methods and classes from the core library to do all the calculations.
>
>
> Hmm, that might be doable. Guess I'll need to have a better look at
> the whole Flake thing though. Also, the thing needs to be done in a
> way so that there's as much code reuse as possible - having two
> painting routines, one for main app and one for flake, is a no-go.
>
> / Tomas
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
_______________________________________________
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]