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