[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-17 13:03:23
Message-ID: 492258b104091706033f1bd95c () mail ! gmail ! com
[Download RAW message or body]

On Thu, 16 Sep 2004 19:25:49 +0200, Ariya Hidayat <ariya@kde.org> wrote:
> 
> > Hm, so in that case, how does it know which formatting is the one to
> > use for C8? Should be (heavens forbid) store timestamps with each
> > formatting command or what?
> No, the depth of the range decides it (that's why I named it as 3-D
> format storage). If you set A1:D10 to green, and later on set C8:F25 to
> yellow, then C8:F25 is the topmost formatting piece which hits cell C8.
> This is because both range attributes are about color. Say, now you
> format A1:Z1000 as "bold" (formatting piece about font), then C8 becomes
> "bold" and "yellow".

Hmmm... What will the *tree* be used for then? If I understand this
correctly, then you're using the same trick that I've used in the
dependency manager - you don't store information about each cell, but
information about a bunch of ranges, each range being of the same size
(say, 100 rows x 10 cols), and each range information containing
formatting commands affecting cells in the particular range, be it one
cell or more. So, if I change formatting of something really huge,
then many ranges shall be affected. Is this correct?

> > Well... Support for operating on a whole row/column, range lists
> > (CTRL-selections), possibility to use a manipulator without #including
> > its class, ability to set formatting, anything I may have forgotten...
> - CellWorkers now also works for row and column, despite its name.
> - Adding support for range lists is a matter of new function which
> iterates over the ranges there.
> - Using manipulator without including class is a matter of inventing a
> sort of trader for those workers.
> - Formatting? CellWorkers also support that, I believe.

Hmmm... Looks like I'll need to have a lok at them then, and maybe
remane CellWorker to BaseManipulator :-P

> > Why? The only thing that we need dependencies for is cell calculation.
> > Dependency manager can to it itself... No need to rely on external
> > class, or worse, to let each class to it separately.
> Well, the name is dependency manager, not recalc manager :-P
> Microsoft Excel even has problem with very complex sheet, although its
> dependency manager is (or must be) excellent. The job of dependency
> manager should be only limited to give information what depends on what
> (and vice versa).
> 
> We may then need a separate Recalculation Manager. It's clear, though,
> that this new manager relies heavily on dependency manager. But note
> also that not only a change in value or formula should trigger
> recalculation, but also for example a change in area name or formula
> such as RAND. http://www.decisionmodels.com/ may give some hints and
> ideas about this.

Hmmm... Well, in any case, that recalc manager can be obtained simply
by splitting the currently planned dep. manager in two parts, right?
Anyhow, I've been thinking about that thing you wrote previously -
that there must have been a reason for setting a CalcDirty flag in
dependency calculation, instead of recalcing immediately. And I have a
very good reason why we cannot do that, why we have to recalc
immediately. Or, more precisely, you have that reason ;-P 
Content-View separation... Currently, cells with CalcDirty are
recalculated in makeLayout(), which however will reside in the View
part... Hence, if you don't use View, but only Content, you'll never
get any recalculation that way -> bad.


> > Indeed. But triggering damage and knowing about damages/repainting are
> > two separate things... Commands will know that there exist methods
> > like valueChanged and formattingChanged, and that there is
> > disable/enableUpdates in Sheet object (or more precisely, the base
> > manipulator, that all commands will be inheriting from, knows that).
> > These methods will trigger repainting, dependency recalc and whatnot.
> I'm confused. To trigger damage you must know which cells, rows,
> columns, or charts are damaged, right?

Yes.

> My proposal was that the
> responsibility of knowing which must be damaged should not be in the
> cell, because cell handles data, not view.

Mine too.

> To make it even more strict
> (of course after another hundreds of clean-up), Document, Sheet, and all
> such classes in the part of "Document" should not know anything about
> repainting and other "View"-related stuff.

I fully agree. And this is what I want to achieve with the things I
propose. Hm, we may end up finding out that we're proposing the same
things, just differently formulated :P
Anyhow, this is what manipulators are about (and yes, I'll be talking
about them over and over, for I consider them a critical part of my
design). There will be a base manipulator, which will know that after
some change, damaging stuff needs to be triggered. Or, more precisely,
it won't even know that what it triggers is cell damaging - it will
just know that it needs to call some valueChanged or formattingChanged
or whateverChanged methods in Sheet. It won't need to do that for
Cells, because cells will do that themselves. Informing others about
the fact that the cell has been changed, that surely is in
responsibility of a Cell object, right? Cells won't know what others
will do with that information, they will just inform...

The Sheet object (or maybe some dedicated object, if need be) will be
receiving that information, and it will be the only one who knows that
damages need to be triggered.

> OTOH I have the feeling that disable/enableUpdates will lead to the same
> trap as begin/endOperation. I hope I'm wrong.

How many classes currently call begin/endOperation? Dozens. And how
many classes will call disable/enableUpdates? One. Only one - the base
manipulator. Actually, we could make it even without these *Updates
methods - their "only" purpose will be to speed up things a bit... Or
a lot... For if we update a A1:Z100 range, then everything using that
range will be updated way too much times, cell damaging will be called
lots of times, for each cell in the range. This is a waste of time.

Hence, disable/enableUpdates will exist. Each manipulator (as it
derives from BaseManipulator) will have access to some
variable(attribute) - let's call it updateAtOnce. If it sets this
variable (in its constructor, to be precise), then when we trigger
this manipulator (via something like BaseManipulator::manipulate
(RangeList rl)), manipulate method will call disableUpdates at the
beginning, enableUpdates at the end, then it will call
Sheet::rangeChanged (rl); There will probably be more such methods
like rangeContentsChanged, rangeFormattingChanged and so on, to allow
more fine-grained control over the whole process (using some other
variables in BaseManipulator).

Of course, the author of each manipulator can freely decide whether he
wants to use the instant update or rather use updating of each cell
immediately after it gets changed; but in most cases, there will be no
reason not to set updateAtOnce to true...

I hope all this makes some sense... ;)

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