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

List:       koffice-devel
Subject:    Re: DESIGN (was Re: koffice/kspread)
From:       Tomas Mecir <mecirt () gmail ! com>
Date:       2004-09-16 12:42:30
Message-ID: 492258b104091605425c360948 () mail ! gmail ! com
[Download RAW message or body]

On Wed, 15 Sep 2004 19:28:44 +0200, Ariya Hidayat <ariya@kde.org> wrote:
> > 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.

Yes, sure :) I can well imagine how the whole thing could work, the
only thing that somehow doesn't "fit" into the overall picture is
range formatting and that 4D tree. I cannot imagine how would you
order the formatting commands, if they are wide-spread amongst many
nodes of a tree, which obviously is ordered from bigger chunks down to
small ones... What is you, say, set color of A1:D10 to green, then
color of C8:F25 to yellow? These overlap a bit, hence you need to
first break the green range formatting of the first part, then somehow
set it for the second part, which probably won't fit into the tree
quite nicely, hence the formatting is spread amongst multiple
branches, brb. This opens up such a huge can of problems, that I
really suggest not to worry about ranges and stay just with sheet's,
columns', rows' and individual cells' formatting.

> 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.

Hm, we'll see... But I've already tried to modify a couple of things,
and I ended up throwing most changes away - there are too many things
being set at too many places - or maybe I just have some bad luck,
shrug. But I'll keep trying... :D

> 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.

Hm, CellWorkers are a bit too simple, at least from what I've seen so
far. While they already provide some parts of what I want to achieve,
I still think that they just aren't good enough. But maybe they could
be used as a base for the manipulators stuff...

> 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.

Brb, the command most certainly WON'T iterate over depending cells -
it won't know that depending cells exist - and dependency manager
won't know that commands exist... Commands won't know that repainting
exists, repainting will just repaint and NOTHING more, and so...
Encapsulation, see? ;) Current code often fails to hide implementation
details into dedicated methods/objects, hence it's kinda hard to make
changes. This needs to change, as everyone who reads my mails should
know by now, hehe ;)))
Also, replace "functor" with "virtual method", add some stuff and you
get the manipulators :)
The dependency manager could indeed make use of a manipulator, and I
think that it probably will, but I want to have it working now - and
since we don't have manipulators yet, it has to be done the old way.

> 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

Of course.

> 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.

Calc dirty? No. I'll recalculate'em directly. More efficient.

Comments? Stone throwers? ;)

/ Tomas
_______________________________________________
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]