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

List:       koffice-devel
Subject:    DESIGN (was Re: koffice/kspread)
From:       Ariya Hidayat <ariya () kde ! org>
Date:       2004-09-15 17:28:44
Message-ID: 41487BCC.6050206 () kde ! org
[Download RAW message or body]


>>I think in many cases this could be more efficient than splitting the
>>area. In addition we could check every now and then if it would be
>>better to split an area if it gets too fragmented...

This is true, no need to make special case for splitting. As for 
fragmentation, at least theoritically this should not happen for most of 
the worksheet where formatting is quite plain and simple.

> Hm, not quite sure if only special cases are open - the whole thing is
> kinda open as of now - I for one cannot imagine how this thing should
> work efficiently. Also, I'm not sure if it's worth the trouble storing
> ranges an'all, as we'll lose that information after save+load anyways.
> This obviously is one of things that still need further discussing. I
> hope Ariya can clarify some issues here, as this was his idea, but
> somehow I have this strange feeling that he's not 100% sure about all
> this either - but I could be wrong ;)

I'm quite convinced that this will work (not because we thought and 
discussed about it since LinuxTag 2003). The range-based format storage 
is only a mean to store formatting efficiently, the big idea is of 
course to split formatting from the cell.

It's true that this range information will be lost somehow, but IMHO it 
gives significant improvement during editing. OTOH small-size range 
(where adjacent cells can be grouped together) is possible to implement 
during document load because the way automatic style is handled in 
OO.o/OASIS file format.

An intermediate step for such format storage will be a simpler storage 
to store format of cells, rows, and columns independent from the cell 
storage (the cluster system, see KSpreadCluster). Again, there will be 
one storage per sheet. KSpread must be modified to get or set cell, row 
and column format from this storage, possibly proxied in KSpreadSheet.

Since now KSpreadCell inherits KSpreadFormat rather than agregates it, 
another intermedia step needs to be carried out. It could be as simple 
as defining new "KSpreadFormat* format" member variable for KSpreadCell, 
duplicate all KSpreadFormat member functions in KSpreadCell and redirect 
the calls to that new member variable. It's ugly, but allow quick 
decoupling of the format without (hopefull) breaking too many things. 
Right after that, we can modifiy accesses to format through the 
KSpreadSheet, i.e. something like KSpreadFormat* 
KSpreadSheet::cellFormat( int row, int column ). If this is implemented, 
then one can start inventing a FormatStorage class and KSpreadCell 
doesn't need to hold an instance of KSpreadFormat anymore.

> Well, an important thing to keep in mind is that restriction, that CVS
> HEAD should be usable at all times - that's why the big parts of
> redesigning shall happen in a separate branch. Are you 100% sure that
> you'll be able to keep CVS HEAD usable? Otherwise, if this is what you
> want to help with, then it might be a good time to repoen that
> should-we-branch-now issue again ;)

Using the above gradual steps I've mentioned, we may not need to branch. 
Only when there's critical point, then we can do the branch. Beside, the 
test framework is now there so anybody who implements something new 
could also right away write a test suite.

Now to other subjects.

About manipulators.
After examining the source code of KSpread, I realized now that this 
concept has been implemented as CellWorker. The difference I could only 
see is that it is also responsible for doing undo and redo. If we decide 
to go on with KCommand-based commands, then we must find a way to expose 
these workers but still let them live nicely with the command. In the 
mean time, I myself couldn't think of one elegant way to do that.

Repaint Triggering.
I believe, it's OK to have KSpreadCell::valueChanged (perhaps 
contentChanged is better because cell can also have formula instead of 
plain value?). However IMHO damages should be part of the "View", not 
the "Document". In our case, damages ideally are triggered from the 
commands. For example, if a command to change formatting of A1:A10 is 
executed, then this command also needs to damage those cells. In case a 
command change a value or a formula, it may need to iterate over all 
cells which are affected (due to dependencies), therefore it's useful if 
we can provide a service like "foreach dependent (other cell, range, or 
chart) of a given cell, do FOO", where FOO is a functor. This is of 
course best placed in the dependency manager.

Dependencies.
I still do not understand the term "recursive dependency calculation". I 
hope it means that the dependents of dependents of a cell are managed 
automatically. IMHO this is very obvious if we can have the "foreach" 
above, only change the functor. Beside, when we change a cell, we need 
to mark it and all its dependents as "calc dirty" anyone, which perhaps 
better implemented as one functor.

Comments? Questions?


Best regards,

Ariya Hidayat








_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]