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

List:       koffice
Subject:    Re: KSpread cells
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-05-22 10:54:14
[Download RAW message or body]

On Mon, May 22, 2000 at 01:31:25PM +0200, Werner Trobin wrote:
> David Faure wrote:
> > 
> > I wondered about that too, yesterday. Let's see. KSpreadCell has
> > 
> > 16 ints
> > 1 double
> > 9 bool
> > 4 QString
> > 1 pointer to cell
> > one QList (dependencies)
> > one Style
> > one Content
> > pointers to QSimpleRichText, KFormula, KSParseNode
> > cellprivate
> 
> Well... and cellprivate seems to inherit QObject (36 bytes, at least)...

Yes but that's only used for 'ST_Select' cells, apparently comboboxes.
So the design is ok here: an optionnal child object, which can't be shared.

But what I forgot is... the base class ! KSpreadLayout is the one
that holds all the formatting info, and which has many many member vars....

> > What's the flyweight pattern ?
> 
> Ok. I've read a nice book (Design Patterns, by Gamma, Helm, Johnson,
> and Vlissides) and they describe a pattern which is called "flyweight."
I should get this book ;-)

> Maybe this helps here - don't know exactly, because I'm not very
> familiar with KSpread's internals.
[...]
Thanks for the explanation. I think it _partly_ applies here.
The main difference is that a word document is linear (hence
the idea of a count), whereas a spreadsheet is bidimensionnal.

So I think we can do something similar but simpler:
We could share formatting information by having a separate object
holding all the formatting stuff (well, that's what KSpreadLayout is
I think) and creating those objects on demand, in a separate list.
Then, a cell points to an instance of such an object.
This allows to share formatting info, and also it simplfies
a lot all the code like KSpreadCell::leftBorderColor, which currently
checks for column and/or row attributes first. It would simply point
to the column (or row)'s layout if it doesn't have any specific attributes.
However this would mean copying the whole layout as soon as one
little attribute changes, but it's already a lot better than it
is now. Even better, then, would be separate formatting objects
for colors, number precision, etc. Hmm.

Also, we probably need a reference counter on the KSpreadLayout
objects, otherwise how do you know when a layout isn't used anymore ?
(and similarly, we need to know when you change the attribute of a cell,
if that cell is the only one using its layout object, in which case
it can modify without duplicating first).


-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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