[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: KSpread Format Storage - the next generation
From: Raphael Langerhorst <raphael-langerhorst () gmx ! at>
Date: 2005-02-28 18:19:39
Message-ID: 200502281919.41127.raphael-langerhorst () gmx ! at
[Download RAW message or body]
Hi all,
Ben Lamb, John Flux and I have started on the KSpread Format Storage
item of the kspread/DESIGN.html document during the FOSDEM event.
We were considering a few possibilities for the formatting stuff and
finally decided to basically separate the style from the cells, so
the cells will be much smaller (memory). Then we have a separate
style storage which is implemented as an quadtree. The styles
themselves are shared (KSpreadStyle::addRef() and release() are quite
useful for this).
So this is basically one fat style object for each different cell
style. All cells having the same style actually relate to the same
style object, so we cut down memory consumption here a lot. It also
makes it possible to have styles without cells(!). The quadtree has
just the necessary depth to represent the granularity of applied
styles. A larger area with the same style will thus take up only very
little memory.
Open Question:
1) KSpreadFormat deprecated?
Well, what about KSpreadFormat and KSpreadStyle... isn't there any
redundancy? Is KSpreadStyle intended to replace KSpreadFormat at some
time? [the last option is what we assumed]. KSpreadFormat can
currently override associated KSpreadStyle attributes, which can
inherit from a parent KSpreadStyle. So we more ways to override style
attributes than we need. So KSpreadFormat is not really needed
anymore, right? It's just old luggage because it has been there for
so long? If anyone knows more about this particular question, would
be good to inform me/us.
2) Manipulators
Currently we do NOT use manipulators... what's the plan with them
anyway? There is no framework for them implemented yet, right?
So How far have we got during FOSDEM?
Well, basically we spent a few hours discussing the possible designs
and finally decided to do it the way we have described above. We
considered the thoughts that were written down in kspread/Design.html
but came to the conclusion that although it might have more benefits
in terms of memory consumption it would probably need more
computation time and logic, probably even some kind of garbage
collector that reduces fragmentation.
Then we moved on to implement on what we decided. So far we probably
have a relativly complete StyleCluster which represents the quadtree
for cell styles. I'll commit it in a minute (everything still
compiles well, it's not yet _used_). From now on we need to move the
dependencies of KSpreadFormat to the new style storage framework
(rendering code, saving/loading, ...??) and then we can throw out the
KSpreadFormat inheritance of KSpreadCell and have much less memory
consumption and thus much better large spreadsheet support /
scalability! I *think* we can get this in completely before 1.4
although I myself won't be able to continue until the next weekend I
guess [I can never tell...]
The added files so far are:
kspread/stylecluster.h
kspread/stylecluster.cc
Best Regards, comments welcome,
Raphael
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic